我在VS2010（C＃，.NET 4.0）中开发了两个应用程序 - 每个都是一个单独的解决方案，包含2个项目，一个用于特定于应用程序的元素，另外还有用于构建DLL的共享库的项目。
我的问题是当构建这个DLL时，在其中一个构建下，DLL比它应该大16384字节（0x4000）。调试版本和发布版本的大小差异相同。如果正确的版本在ClearCase中，我在C：驱动器上获得完全相同的结果，因此它似乎不是配置规范或与视图相关的问题。
我已经浏览了VS设置，完全删除了bin / obj文件夹以强制完成重建，使用WinMerge来区分所有文件/文件夹，但都没有成功。
使用dumpbin，我可以在clr头中看到资源目录的0x3F20大小差异。我怀疑剩余的0xE0可归因于DLL内的部分对齐。
此时我很难过。关于什么可能导致这个或什么步骤进一步调查的任何建议???
修改
也许我没有很好地描述VS解决方案 - 该解决方案有2个项目。只需通过Add-＆gt; Existing Project将共享库添加到解决方案中。然后在选择Build-＆gt; Rebuild Solution时构建这两个项目。
重新。汉斯评论说，从配置管理/信心的角度来看，这是一个问题。如果没有更改源代码/项目文件，我唯一希望在DLL中更改的是任何构建时间/版本细节 - 而不是像我一样的15K delta。
答案 0 :(得分：2)
问题出在.suo（解决方案用户选项）文件中，该文件必须已损坏（并且不幸地被以前用户在版本控制下放置和维护）。值得庆幸的是，删除此文件似乎没有任何重大损失。
有关.suo文件的更多信息可以在SO问题Why are there sln, suo and csproj files?
中找到来自Debugger Settings Visual Studio Add In– Easily Copy Breakpoints between Machines 的引用总结得很好：
.SUO文件是你存在的祸根。您在Visual Studio中遇到的几乎所有问题都是损坏的.SUO文件的结果。可悲的是，似乎只需要破坏.SUO文件就是你的心脏跳动。换句话说，只要你有Visual Studio崩溃，拒绝调试，或者行为奇怪，就是.SUO文件的错误。每当有人问我有关Visual Studio的奇怪行为时，我的瞬间响应就是“删除.SUO！”谈到Visual Studio卫生，删除.SUO文件就在那里进行癌症筛查。