views:

307

answers:

2

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.

+2  A: 

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

Jason Haley
Thanks for the tools. I'll have to try those and report back as to what it finds. When I use Reflector to look at the offending method (see the screenshot above), it is quite clear where the assembly is not correct. Would PEVerify just tell me *where* it isn't correct or would they be able to say *why* as well?
McKAMEY
If I recall correctly (its been awhile since I used it), yes it will indicate what errors it finds in the metadata. However you may need to open it up in ildasm to translate some of the things like tokens that will be mentioned in the error messages.PEVerify is also a pretty raw tool - meaning its not designed for the every day developer, you may have to google some of the error messages to see what it is talking about.
Jason Haley
A: 

Doesn't the BadImageFormatException get thrown when you attempt to run x64 code on x86?

Peter LaComb Jr.
That is one of the situations where this occurs (http://msdn.microsoft.com/en-us/library/system.badimageformatexception.aspx) but in this case it isn't that. The individual assemblies work fine by themselves but fail once merged.
McKAMEY