We wrote an unmanaged DLL with a simple C-style API last month. It works and all is fine with it.
Today, we're writing a demo app using this DLL. This is part of a whole new Solution in Visual Studio 2013. It compiles and runs fine, until it tries to use the DLL's API, where we get DllNotFoundException.
Same thing happened last week with a test console app. The cheap-quick workaround was to copy the DLL from the workspace it was made in, and plop a copy into bin/x64/Debug/ in the project's folder in the new workspace. The problem went away.
Sure, we could do the same today for the new demo app, and get on with life, but this seems goofy. We have several test and demo apps, and apps to be given to customers, numbering fifteen or so. Surely we are not supposed to manually copy the DLL, after every change to it, into fifteen different bin/x64/Debug/ for fifteen different projects. And more, since we'll have Release versions too.
Despite reading many blogs, articles, MSDN pages about unmanaged DLLs and Solutions and Projects and right-click to "Add References..." and all that, I've not seen any clear explanation how one should deal with multiple projects using one DLL. Seems like there should be some way we could copy the DLL to one place, and tell all the projects just once to go look there.
Relevant Side Question: We've tried the "Add References..." things, but it didn't like our DLL. Is this not applicable to unmanaged DLLs written in C? We don't see a clear statement whether or not we should be using Add Reference.
For your program to run it needs all its dependencies to be available, so the dll has to be included in the set of files you ship. For managed assemblies the build process copies these files automatically, but for unmanaged dlls you need to tell the build system what to do.
The usual way is to either
edit the post-build step (in your app's project properties) and add a copy/xcopy/robocppy command that copies the file to the output folder. You can embed macros in the filenames to locate the folders so that the project remains relocatable.
add the file to the project and get its properties in the solution explorer. Then set it to be "copied if newer".
By doing this the latest version of the dll is copied every time you do a build, and you can forget about it.
If I have a Project which uses my own made .dll and this .dll is not registered with the GAC but simply in the same folder as my projects App. eg C:\Program Files (x86)\MyApp Folder.
Can I, and more importantly how do I properly reference this .dll if I want to for example build a second project which also uses this .dll. It is possible that I build a few small apps that will use this .dll.
In this case must I have it in the GAC or if it is not there what must I do?
If I have a Project...
You should never put yourself in a situation where you have just a project. You first and foremost have a solution. A collection of projects that, together, build an app. Projects of course have a dependency on each other, you use a project dependency to tell the compiler about. Which automatically takes care of reference assemblies, the output of one project becomes the reference of another. And any changes you make to the source code of such a project automatically propagate to the others.
This is usually as far as teams take it.
This however tends to not work so well on very large solutions with dozens of projects, Visual Studio tends to get sluggish and building can take a long time. An important step to take in such a case is to freeze a root project. A programmer needs to get an explicit permission to make changes to such a core project. Because such a change tends to be very destabilizing, requiring many changes in dependent projects. And effectively destroys many hours of testing and validation time.
You do this by explicitly removing a project from a solution. Which now automatically makes it difficult to make changes to it. The dependent projects need to be updated to use an explicit reference assembly instead of the project dependency. Picking a well-known location for the assembly is important. Either source control or (preferrably) a build server is instrumental to be the source of the assembly. A tool like Nuget can be very useful.
I have some c# projects. I added post build event to those projects that copy the resulted assembly (dll) from the bin into common folder.
It appears that each compile generates assembly which is binary different from the previous even when I don't modify the project files.
It is quite a problem for me since I'm using Kiln that monitor those file and think they were modified.
I read somewhere that the dll stores time stamp of compilation which if true then I cannot fix this. If so how do you manage your shared DLL in such a way that your repository (Git/HG) doesn't commit all your compiled projects that weren't modified?
Thanks,
Eran.
To address the specific question of "How do you manage your shared DLL in such a way that your repository (Git/HG) doesn't commit all your compiled projects that weren't modified?", I have a very simple answer: ignore.
We exclude /bin and /obj from the directories which our source control will even attempt to commit. This does mean that you will need to recompile the code on each machine after each change, but Visual Studio would do that anyway for any project where the code has changed.
Don't commit the output folders of your projects.
If you want to have a Setup folder or something similar that always contains the latest versions of the assemblies created by your projects, the solution is to make sure that your post-build event is configured to run only when the build updates the project output. There is an option that is named like this:
I'm using Visual Studio 2010 Pro to build a solution that contains two projects. Project A contains most of my source code, while Project B is intended to run independently, but must use some of the source code contained in Project A.
Under the current configuration, Project A is contained as a reference within Project B. I'd like to be able to build and maintain versions of each project independently, but it appears that when I build the entire solution, ProjectB.exe cannot run without ProjectA.exe in the same local directory. I would think and hope that when the .exe binaries are compiled that all of their dependencies are packaged within each, but that appears not to be the case. In fact, any attempt to run ProjectB.exe while ProjectA.exe is not present results in a System.IO.FileNotFoundException.
Is there a way to build a version ProjectB.exe that runs independently and avoids code duplication?
In cases where you want common code, the best solution is to break out the common classes into a third assembly to serve as a library. (As per Adriano's suggestion.) The other option he hints at is to use the "as link" option when using the "add existing file" to the second project.
If you don't know where it is, use the "Add existing file" option, then in the dialog box to select the file, the "Add" button has a drop-down selection where you can select "As Linked File" (or something to that effect.)
This allows you to compile the same classes into multiple projects. But keep in mind that the namespacing for the linked file cannot be changed for the second project. If the namespace was "ProjectA.Domain", this is how you need to access it in Project B. This was a useful trick for Silverlight projects back before the multi-platform assemblies were introduced.
If you want to get rid or the dependency on A, you will have to extract the common logic into another project (let's call it C), as Adriano suggested in a comment.
If you need even looser bond between the projects, you can reference A (or C) not as a project, but as a built assembly (.dll file) and check Specific Version reference property to True. Additionally, if your project/codebase structure is more complex, check more assembly sharing options here.
Some options:
The common option: Separate the common code into a third class library (DLL) project. And have both ProjectA and ProjectB dependent on it. The downside is that now in order to run the projects you need two files (the main exe and the dll.) This method is how most software is developed: a single executable and a bunch of DLLs.
The correct option: Separate the common code into a third project and modify the project files to create executables that contain both assemblies (similar to statically linked libraries in unmanaged code.) The downside is that Visual Studio does not support this out of the box and you need to modify the project files which are actually MS-Build definition files to do this.
The ugly option: Create shortcuts for the common files in ProjectA in ProjectB. This is the same as copying the common code to the other project, but you're still left with one source file. The downside is that you have to do this for every file and maintain the same structure in both projects. This is an ugly, if viable, option. Choose one of the others.
Do you use ILMerge? Do you use ILMerge to merge multiple assemblies to ease deployment of dll's? Have you found problems with deployment/versioning in production after ILMerging assemblies together?
I'm looking for some advice in regards to using ILMerge to reduce deployment friction, if that is even possible.
I use ILMerge for almost all of my different applications. I have it integrated right into the release build process so what I end up with is one exe per application with no extra dll's.
You can't ILMerge any C++ assemblies that have native code.
You also can't ILMerge any assemblies that contain XAML for WPF (at least I haven't had any success with that). It complains at runtime that the resources cannot be located.
I did write a wrapper executable for ILMerge where I pass in the startup exe name for the project I want to merge, and an output exe name, and then it reflects the dependent assemblies and calls ILMerge with the appropriate command line parameters. It is much easier now when I add new assemblies to the project, I don't have to remember to update the build script.
Introduction
This post shows how to replace all .exe + .dll files with a single combined .exe. It also keeps the debugging .pdb file intact.
For Console Apps
Here is the basic Post Build String for Visual Studio 2010 SP1, using .NET 4.0. I am building a console .exe with all of the sub-.dll files included in it.
"$(SolutionDir)ILMerge\ILMerge.exe" /out:"$(TargetDir)$(TargetName).all.exe" "$(TargetDir)$(TargetName).exe" "$(TargetDir)*.dll" /target:exe /targetplatform:v4,C:\Windows\Microsoft.NET\Framework64\v4.0.30319 /wildcards
Basic hints
The output is a file "AssemblyName.all.exe" which combines all sub-dlls into one .exe.
Notice the ILMerge\ directory. You need to either copy the ILMerge utility into your solution directory (so you can distribute the source without having to worry about documenting the install of ILMerge), or change the this path to point to where ILMerge.exe resides.
Advanced hints
If you have problems with it not working, turn on Output, and select Show output from: Build. Check the exact command that Visual Studio actually generated, and check for errors.
Sample Build Script
This script replaces all .exe + .dll files with a single combined .exe. It also keeps the debugging .pdb file intact.
To use, paste this into your Post Build step, under the Build Events tab in a C# project, and make sure you adjust the path in the first line to point to ILMerge.exe:
rem Create a single .exe that combines the root .exe and all subassemblies.
"$(SolutionDir)ILMerge\ILMerge.exe" /out:"$(TargetDir)$(TargetName).all.exe" "$(TargetDir)$(TargetName).exe" "$(TargetDir)*.dll" /target:exe /targetplatform:v4,C:\Windows\Microsoft.NET\Framework64\v4.0.30319 /wildcards
rem Remove all subassemblies.
del *.dll
rem Remove all .pdb files (except the new, combined pdb we just created).
ren "$(TargetDir)$(TargetName).all.pdb" "$(TargetName).all.pdb.temp"
del *.pdb
ren "$(TargetDir)$(TargetName).all.pdb.temp" "$(TargetName).all.pdb"
rem Delete the original, non-combined .exe.
del "$(TargetDir)$(TargetName).exe"
rem Rename the combined .exe and .pdb to the original project name we started with.
ren "$(TargetDir)$(TargetName).all.pdb" "$(TargetName).pdb"
ren "$(TargetDir)$(TargetName).all.exe" "$(TargetName).exe"
exit 0
We use ILMerge on the Microsoft application blocks - instead of 12 seperate DLL files, we have a single file that we can upload to our client areas, plus the file system structure is alot neater.
After merging the files, I had to edit the visual studio project list, remove the 12 seperate assmeblies and add the single file as a reference, otherwise it would complain that it couldnt find the specific assembly. Im not too sure how this would work on post deployment though, could be worth giving it a try.
I know this is an old question, but we not only use ILMerge to reduce the number of dependencies but also to internalise the "internal" dependencies (eg automapper, restsharp, etc) that are used by the utility. This means they are completely abstracted away, and the project using the merged utility doesn't need to know about them. This again reduces the required references in the project, and allows it to use / update its own version of the same external library if required.
We use ILMerge on quite a few projects. The Web Service Software Factory, for example produces something like 8 assemblies as its output. We merge all of those DLLs into a single DLL so that the service host will only have to reference one DLL.
It makes life somewhat easier, but it's not a big deal either.
We had the same problem with combining WPF dependencies .... ILMerge doesn't appear to deal with these. Costura.Fody worked perfectly for us however and took about 5 minutes to get going... a very good experience.
Just install with Nuget (selecting the correct default project in the Package Manager Console). It introduces itself into the target project and the default settings worked immediately for us.
It merges the all DLLs marked "Copy Local" = true and produces a merged .EXE (alongside the standard output), which is nicely compressed in size (much less than the total output size).
The license is MIT as so you can modify/distribute as required.
https://github.com/Fody/Costura/
Note that for windows GUI programs (eg WinForms) you'll want to use the /target:winexe switch. The /target:exe switch creates a merged console application.
I'm just starting out using ILMerge as part of my CI build to combine a lot of finely grained WCF contracts into a single library. It works very well, however the new merged lib can't easily co-exist with its component libraries, or other libs that depend on those component libraries.
If, in a new project, you reference both your ILMerged lib and also a legacy library that depends on one of the inputs you gave to ILMerge, you'll find that you can't pass any type from the ILMerged lib to any method in the legacy library without doing some sort of type mapping (e.g. automapper or manual mapping). This is because once everything's compiled, the types are effectively qualified with an assembly name.
The names will also collide but you can fix that using extern alias.
My advice would be to avoid including in your merged assembly any publicly available lib that your merged assembly exposes (e.g. via a return type, method/constructor parameter, field, property, generic...) unless you know for sure that the user of your merged assembly does not and will never depend on the free-standing version of the same library.
We ran into problems when merging DLLs that have resources in the same namespace. In the merging process one of the resource namespaces was renamed and thus the resources couldn't be located. Maybe we're just doing something wrong there, still investigating the issue.
We just started using ILMerge in our solutions that are redistributed and used in our other projects and so far so good. Everything seems to work okay. We even obfuscated the packaged assembly directly.
We are considering doing the same with the MS Enterprise Library assemblies.
The only real issue I see with it is versioning of individual assemblies from the package.
I recently had issue where I had ilmerged assembly in the assembly i had some classes these were being called via reflection in Umbraco opensource CMS.
The information to make the call via reflection was taken from db table that had assembly name and namespace of class that implemented and interface. The issue was that the reflection call would fail when dll was il merged however if dll was separate it all worked fine. I think issue may be similar to the one longeasy is having?
It seems to me like the #1 ILMerge Best Practice is Don't Use ILMerge. Instead, use SmartAssembly. One reason for this is that the #2 ILMerge Best Practice is to always run PEVerify after you do an ILMerge, because ILMerge does not guarantee it will correctly merge assemblies into a valid executable.
Other ILMerge disadvantages:
when merging, it strips XML Comments (if I cared about this, I would use an obfuscation tool)
it doesn't correctly handle creating a corresponding .pdb file
Another tool worth paying attention to is Mono.Cecil and the Mono.Linker [2] tool.
[2]: http:// www.mono-project.com/Linker