Combining PostSharp with ILMerge seems a recurring demand. Indeed, many developers don’t welcome the multiplication of dependent assemblies as PostSharp.Public.dll and PostSharp.Laos.dll, and ILMerge seems the dreamed solution to that. Unfortunately, it will work only in rare cases.
The Simple Case
Say you have an assembly named MyProgram.exe with aspects defined in this assembly. The application is formed of the following assemblies:
PostSharp.Public.dll
PostSharp.Laos.dll
MyProgram.exe
In this particular case, it is valid to merge all three assemblies into a new assembly equally named MyProgram.exe.
However, if you modify the name of the merged assembly, it will cease to work.
What’s Wrong?
Remember that the aspects are serialized into the assembly. It uses the BinaryFormatter to do the job. Unfortunately for our purpose, this formatter stores the full type name of aspects, including the assembly name. So when you rename the assembly, you break the link between the aspect serialization and the underlying types, and you get an exception during deserialization.
The same occurs when you have aspects in one of the dependencies you merge. Say your program references MyLibrary.dll, whose some classes have been enhanced by PostSharp Laos. If you merge it into MyProgram.exe, the serialization of aspects previously defined in MyLibrary.dll will be broken.
Possible Solution
The problem clearly lays in the use of the BinaryFormatter to do the job. We could eventually use another serializer that does not store the full type name.
This feature (pluggable serializers) was actually present in former builds of what is now PostSharp 1.5, but I have removed the feature because it became useless. If there is some interest, I could restore it. It very much depends on the feedback I will get.
How is this a critical feature for you?
Happy PostSharping,
~Gael
We are using PostSharp only in Web Applications, so we do not have to take care about the number or names of the assemblies…
We currently use it to build WinForms applications. Additionally we use PostBuild to bundle the application into a single exe. Ideally we would like to be able to rename the exe. While I wouldn’t say this feature is critical, it would eliminate a worry.
Of course, all I said here about limitations due to assembly renaming are also valid with type renamings, as is often the result of obsfuscation.
Thanks a lot for bringing this on the table, since I have been requesting it on the forums, I will give the reasons here as well
First of all, it’s really cool to be able to deploy a single .exe file instead of mony files on the drive (à la .app of Mac OS X).
But more importantly for me: I build libraries for my clients and it’s a lot easier to deliver a single and consistent file to my clients, rather than them start asking me what these dependencies are, why they need them, why I used them, and also avoid them to have to add many dependencies to their own projects.
Gael,
For debugging purposes we can work the way we use to and to release the product simply, disable PostSharp do the merge then do the PostSharp tasks on the merged assemblies that way the BinarySerializer will reference the correct assemblies. That could do the work and there’s no need to change the serializer to a probably less efficient one.
Miguel,
You could not merge before, because then PostSharp would not recognize its dependencies (PostSharp.Public and PostSharp.Laos).