September 21, 2009

Should we ship a single assembly containing all the other ones - merged?

Today I was able to merge all the assemblies of DataObjects.Net v4.0 into a single one using ILMerge (later I'll share .targets file I created to invoke it): Xtensive.Storage.Merged.dll. Its size is almost 5 MB! So DO4 pretends to be largest ORM on .NET now ;) Actually, there are nearly 1.5 MB of external code - we integrated Npgsql.dll, Mono.Security.dll and Oracle.DataAccess.dll into it.

Anyway, the question is: would you like to have an option to use just this single assembly instead of a set of assemblies?

Pros:
- Single assembly instead of many ones. Btw, this is much less important now - recently I integrated automatic copying of all indirect dependencies to output folder into our .targets files.

Cons:
- It will be difficult to switch back to multiple assemblies later, if you'll start use this option in production. That's because serialized assembly name of any type inside merged assembly will be different from the original one. So if this path is chosen for a particular project, it will be hard to migrate back to multiple assemblies option.

Please tell me what do you think about this. Is this really necessary?