I have a VS2010 SL4 project which uses an external Silverlight DLL. The project is localized with multiple RESX files, and the DLL is, too. I usually include external DLLs in my solutions as follows:
1) create a set of virtual folders in my solution like (say the imported DLL is named Sample.dll):
/Lib/Sample/Debug
/Lib/Sample/Release
2) create the same folders structure in the file system and copy under Debug and Release the respective versions of the DLL, so that now I find the following files:
/Lib/Sample/Debug/Sample.dll
/Lib/Sample/Release/Sample.dll
3) add to all the client projects in the solution a reference to /Lib/Sample/Debug/Sample.dll.
4) open the .csproj file of each project with the added reference, and change the Debug part of the path with $(Configuration), so that the right Debug/Release version is picked during build.
Now the question is: in my SL4 solution I can follow the same procedure for importing the language-neutral DLL. But what about its satellite resources? For instance, the French version of the imported DLL is built under subfolder fr-FR and named Sample.resources.dll. How should I include it correctly? Even If I try to manually add it in the compiled XAP under folder fr, it is ignored and the application falls back to its neutral culture...
I think I found it, here's a recap for whom may be interested:
open the .csproj file and ensure you add all your desired languages (separated by semicolons) in . For instance, if you support fr-Fr add <SupportedCultures>fr-Fr</SupportedCultures>.
(had to do this manually, I supposed 1. should be enough): once compiled, open your xap (rename it to .zip and open) and add if not present an element like <AssemblyPart Source="fr-FR/Sample.resources.dll" /> for each imported satellite with resources.
Thanks anyway!
Related
After using TeamCity, my build process is Visual Studio (sln) -> NuGet Pack. Everything builds fine and the artifact is created. But the artifact has every single file, include the .vbproj, .vb files, the classes folder which only holds .vb files.
Is there a way to turn a setting on to create the artifact which doesn't have all the .vb files etc due to them being compiled in the .dll?
For anyone wondering, I just excluded the .vb files in the nuspec
Have you considered using Octopack to package the nuget. It is smart enough to include all the required files into the package and will not require a custom nuspec file that you would need to source control and manage for any future changes.
IMO custom nuspec file should be used only if you have a very specific requirement such as if the target directory is different.
(mark as content and copy always for the files that you want to include)
Is it possible in MSBuild 4.0 and/or 4.5 to specify additional files to be treated as a manifest output of a project by its dependencies, and copied with the binary project output, whenever that is copied? Ideally, I want to create some files beside a .dll during build, and would like these files to stay in the same folder as the .dll whenever it is copied to a directory of a project depending on it.
If this is not clear, I am thinking of .pdb and documentation .xml files created by the C# compiler. These files treated specially: Whenever another project requests the .dll be copied locally into its binary directory, these files go with the .dll. Can I augment this set with my own special files?
This is not possible, and here is why. Actually, there is no concept of project output accessible externally between MSBuild projects. Rather, when a reference to a project is added, the SDK-provided build framework (based on MSBuild scripts) looks for a few specific files matching the name of the referenced DLL, and copies these files with the DLL itself into the current project output directory (assuming CopyLocal is set, which is probably true for a referenced project).
In framework v4.0, this is done by the task ResolveAssemblyReference which is called from an identically named target from the file %windir%\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets. The task looks for specially named files placed beside the target DLL, including its matchin PDB files and an XML documentation file. Other files are also discovered, as I infer from the decompiled source.
So nothing in a given project specifically marks these files as somehow "exported" from the project. The magic happens on the pulling side.
I have been searching around for an answer to this question, but I cannot find the documentation on it. I found a few similar questions asked here, but none that completely cover it?
Similar Question
What do all of the different files in the project directory do? I am trying to make my project open source and I don't want to have a ton of unnecessary files in my repository. What files are vital and what files will be generated when the user initially loads the project? Its important to note that this is a VB Form Application
Base Directory:
*.vb
*.Designer.vb
*.resx
*.vbproj
*.sln
*.vbproj.user
*.config
Any of the other folders in the base directory?
*/bin
*/Collection
*/My Project
*/obj
*/Resources
*.suo and *.user files can be ignored. They store user specific settings such as window arrangements, open files etc. Those files are generated by Visual Studio whenever a solution is opened.
*.vb files are somewhat important since they contain your source code...
*.sln and *.vbproj files tell Visual Studio which projects are in a solution and which files are in a project, respectively. They also contain project specific settings such as build plattforms, custom build events, target .NET Framework etc.
*.resx and app.config can be important, depending on your project. They should not be left out when you publish your project, however since they're part of the Visual Studio project. If they're truly not needed you can remove them from the project.
Edit
Folders bin and obj are where Visual Studio generates the compiled output so you should not include those when you publish the source code of your project. Any other folders are project specific so it depends on your project if they're needed or not.
As a rule of thumb, anything that is automatically generated should be excluded when you publish your source code.
Also, if you don't already, you should use a version control system such as Subversion or GIT to manage your sources. Any essential files / folders as explained above should go in there.
I am trying to read a .wav file and hence need to include the libsndfile binary in my project. I am using NetBeans 7.0 and the Tools->Library->Add new library option doesnt work since the Add library button is disabled.
I tried adding the path of the header file to the Project->Build properties and the code compiled. But when I try to add the .dll in a similar way via Project->Linker properties NetBeans is unable to find the .dll. If i navigate to the folder from MyComputer->..i can see the .dll/ However NetBeans doesn't display it.
I am using a Win 7 64 bit machine & I have setup the appropriate libsndfile binary. Been at it for a day now. Would appreciate any help.
Thanks,
Neeraj
DLL doesnotrequires setting of class path. So you can load a DLL from local file system. Copy the DLL and go to the file explorer tab strip and paste the file.
First you have to check that your compiler version (32 or 64 bit) matches libsndfile version. I suppose you did it correctly.
I also suppose you correctly added the sndfile.h to the include path.
You will need two library files actually. I think you forgot the one to compile properly.
Compiling and Linking (.lib file)
Note that Netbeans 7.0 doesn't accept .lib files and you need to link the .lib file for your project to compile. So, in C:\Program Files\Mega-Nerd\libsndfile\lib you need to copy libsndfile-1.lib and rename the .lib extension to .a.
Then, in Poject Properties > Build > Linker > Additional Libraries Directories add the path to the \lib directory. For me it's Program Files/Mega-Nerd/libsndfile/lib.
A few lines below, you'll have Poject Properties > Build > Linker > Libraries. Specify the location of the library file named libsndfile-1.a, for me it's C:\Program Files\Mega-Nerd\libsndfile\lib\libsndfile-1.a.
Now it should at least compile.
Executing (.dll)
Now, it likely will not execute even if it compiled. That's because the .dll file is needed to execute the final .exe. Simply copy the libsndfile-1.dll file (for me it's in C:\Program Files\Mega-Nerd\libsndfile\bin) to your project, next to the .exe file. For me, it's in C:\proj\dist\Debug\Cygwin-Windows\proj.exe.
Edit: I checked with the today's 8.2 version of NetBeans, and the procedure is exactly the same.
i did a build in vb.net and got one exe file
however, when a user runs the file, it says it is missing one of the libraries (itextsharp).
so the question is, if there is actually a build option in vb.net, why does it not include the library in the same exe file?
You can distribute the iTextSharp DLL with your application. The easiest way to do this is to simply include it in the same folder as your EXE. The DLL should be output to your Project's Debug/Release folder each time you build assuming you've added it as a Reference in your project and the Reference's 'Copy Local' property is set to True.
If you want to distribute one EXE and include the iTextSharp in that, you can use the ILMerge tool (or alternately Gilma from SourceForge) after you build your EXE.
in the properties for the reference set the Copy To Output to Always
ITextSharp is not a library linked in your project output; it's an assembly referenced by your project output. And while VB.Net builds one executable from your source code, the CLR still needs all the referenced assemblies in the same folder as your executable.
To make everything work, you can distribute ITextSharp assemblies along with your app. Alternatively, if you indeed need only one file, you can use ILMerge on your project output and the assemblies you want included. However, you might need to determine all the correct assemblies you need merged. I wouldn't revommend using this tool, unless you understand how it works.
Note: If you want to use ILMerge with .Net v4.0, read this page.