Use ILMerge /internalize to avoid version conflicts & simplify deployment
If you have a library that will be consumed in other project and uses a third party assembly to do some taks you can merge both assemblies hidding the reference.
Scenario
You use the Ionic.Zip.dll assembly, if you deploy your library as-is, you can generate version conflicts if the users are using another (incompatible) version of Ionic.Zip.dll
Solution
Add a msbuild step or a Post-Build event with code like:
ILMerge.exe /internalize /out:"MyLibrary.Merged.dll" "MyLibrary.dll" "Ionic.Zip.dll"Now you have a MyLibrary.Merged.dll that contains all the code in Ionic.Zip.dll but with all members with internal visibility
Hints:
remove /t:dll if the destination is executable
use /ndebug if you don't need the pdb's
use /targetplatform:v4 if the destination must use .Net 4.0 runtime (by default is .net 2.0)Links:
Home: http://research.microsoft.com/en-us/people/mbarnett/ilmerge.aspx
ILMergeGUI: http://ilmergegui.codeplex.com/
Written by Marcos Meli
Related protips
2 Responses
This is generally not a good idea. It means that if Ionic.Zip.dll releases a new version with a bug fix in it, users of your library cannot take advantage of it. It also means that if your users are also using three other libraries, all of which use Ionic.Zip.dll, they are now effectively dependent on four different copies of Ionic.Zip.dll, bloating both the size of their deployment artifact, and the amount of memory used by their program at runtime.
Your users should test their projects when upgrading the version of Ionic.Zip.dll they are using to ensure that it is compatible. In the event that they have another dependency that requires a version of Ionic.Zip.dll that is incompatible with your library, they can always run ILMerge on their side and take a dependency on the resulting assembly to resolve the conflict.
@eatdrinksleepcode I partially agree with u, mostly about the size of the deployment, but nowadays that is not a big deal, stability is a ton more important, the Ionic.Zip.dll dependence is hidden so the user don't know about it. If a library depends on a version of Ionic.Zip.dll, is tested upon it, maybe any update of that library will broke that library. So is always better to avoid headaches for final users with the unique downside of bigger dlls and a bit more of ram at runtime
As a note, you are right if you are internalizing a DevExpress dependence or any other big deploy library, like Krypton Toolkit, have a duplicate of that libraries in memory and size are prohibitive, but if your dependencies are small enough, so is always better to hide the dependence and internalize
Thanks for the comment :)
Have a fresh tip? Share with Coderwall community!
