R – Are there size limitations to the .NET Assembly format

asp.netaspnet-mergeassembliesbadimageformatexceptionilmerge

We ran into an interesting issue that I've not experienced before. We have a large scale production ASP.NET 3.5 SP1 Web App Project in Visual Studio 2008 SP1 which gets compiled and deployed using a Website Deployment Project. Everything has worked fine for the last year, until after a check-in yesterday the app started critically failing with BadImageFormatException.

The check-in in question doesn't change anything particularly special and the errors are coming from areas of the app not even changed. Using Reflector we inspected the offending methods to find that there were garbage strings in the code (which .NET Reflector humorously interpreted as Chinese characters). We have consistently reproduced this on several machines so it does not appear to be hardware related.

Further inspection showed that those garbage strings did not exist in the Assemblies used as inputs to aspnet_merge.exe during deployment.

aspnet_merge.exe / Web Deployment Project Output
Assemblies Properties:

  • Merge all outputs to a single assembly
  • Merge each individual folder output to its own assembly
  • Merge all pages and control outputs to a single assembly
  • Create a separate assembly for each page and control output

In the web deployment project properties if we set the merge options to the first option ("Merge all outputs to a single assembly") we experience the issue, yet all of the other options work perfectly!

My question: does anyone know why this is happening? Is there a size-limit to aspnet_merge.exe's capabilities (the resulting merged DLL is around 19.3 MB)? Are there any other known issues with merging the output of WAPs?

I would love it if any Assembly format / aspnet_merge.exe gurus know about any such limitations like this. Seems to me like a 25MB Assembly, while big, isn't outrageous.

Best Answer

You might try running PEVerify on it and see what you get.

To me it sounds like an encoding issue ... but I'm not sure why that would happen. There technically is a limit to the amount of metadata that can fit into the metadata tables in an assembly, but I doubt if that is the problem.

You could see the size of the metadata tables if you open the exe in Ildasm, you could try looking at the statistics (View->Statistics) or the counts of the metadata tables which is a 2 step process: 1. View->Metainfo->Raw:Count,Sizes 2. Press Ctrl+M