.NET 程序集格式有大小限制吗？
我们遇到了一个我以前从未遇到过的有趣问题。我们在 Visual Studio 2008 SP1 中有一个大规模生产 ASP.NET 3.5 SP1 Web 应用程序项目，它使用网站部署项目进行编译和部署。去年一切都工作正常，直到昨天签入后，应用程序开始严重失败，并出现 BadImageFormatException。
有问题的签入不会改变任何特别的东西，并且错误来自应用程序中甚至没有改变的区域。我们使用 Reflector 检查了有问题的方法，发现代码中存在垃圾字符串（which .NET反射器幽默地解释为汉字）。我们一直在几台机器上重现这一点，因此它似乎与硬件无关。
进一步检查表明，这些垃圾字符串不存在于用作 aspnet_merge.exe。
aspnet_merge.exe / Web 部署项目输出 组件属性：
- 将所有输出合并到一个程序集中
- 将每个单独的文件夹输出合并到其自己的程序集中
- 将所有页面和控制输出合并到一个程序集中
- 为每个页面创建单独的程序集并控制输出
在 Web 部署项目属性中，如果我们设置合并第一个选项（“将所有输出合并到一个程序集”）的选项我们遇到了这个问题，但所有其他选项都工作得很好！
我的问题：有谁知道为什么会发生这种情况？ aspnet_merge.exe 的功能是否有大小限制（生成的合并 DLL 约为 19.3 MB）？合并 WAP 输出是否存在其他已知问题？
如果任何程序集格式/aspnet_merge.exe 专家了解此类限制，我会很高兴。在我看来，就像一个 25MB 的程序集，虽然很大，但并不离谱。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以尝试在其上运行 PEVerify 并查看你得到什么。
对我来说，这听起来像是一个编码问题......但我不确定为什么会发生这种情况。从技术上讲，可以放入程序集中元数据表的元数据量是有限制的，但我怀疑这是否是问题所在。
如果您打开 Ildasm，您可以尝试查看统计信息（查看 -> 统计）或元数据表的计数，这是一个 2 个步骤的过程： 1. 查看 -> 元信息 -> 原始：计数，尺寸 2. 按 Ctrl+M
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
当您尝试在 x86 上运行 x64 代码时，不会抛出 BadImageFormatException 吗？
Doesn't the BadImageFormatException get thrown when you attempt to run x64 code on x86?