我们正在使用Visual Studio 2010开发应用程序。我们所有的项目都设置为带有x86平台的.NET framework 3.5。
我们正在使用外部库PDFViewerNET，我们从http://code.google.com/p/pdfviewer-win32/downloads/list加载了.NET 3.5 32位版本
我们将PDFLibNet.DLL包含在我们自己的.NET 3.5程序集中，该程序集构建得很好。然后我们将生成的程序集DLL包含到我们的应用程序项目（.NET 3.5 x86）中。该应用程序正在编译和构建VS.它可以在VS内运行和调试，并从驱动器启动（发布配置用于所有构建）。一旦我们从程序集中访问方法，它就可以正常工作。
该应用程序最初是为.NET Framework 4.0开发的，其中包含＆＃34; AnyCPU＆＃34;平台。我们迁移回.NET 3.5，因为我们计划使用需要.NET 3.5的EMC Documentum 6.7程序集。但这还没有实现......
现在......我们使用TeamCity Enterprise 7.1.5（build 24400）进行部署和检查构建。使用我们之前使用的MSBuild .NET 4.0（Toolset 4.0）x64设置，构建配置很好。现在我们不得不切换到MSBuild .NET 3.5（Toolset 3.5）x86。
构建运行正常。但是当我们启动生成的应用程序并尝试从程序集中访问方法时（这与我们在VS中使用的版本相同），它会失败并显示错误
Could not load file or assembly "blahblahblah, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null" or one of its dependencies. An attempt was made to load a
program with an incorrect format
blahblahblah.DLL是我们自己的程序集，其中包括PDFLibNet.DLL。所有DLL文件都与生成的EXE位于同一文件夹中。 EXE为575KB，而使用VS构建时为593KB
有什么想法吗？
答案 0 :(得分：1)
确保在VS和TeamCity（Build / Configiration Manager）中构建相同的解决方案配置。检测任何未使用的解决方案配置即使配置命名为“任何CPU”，某些项目也可能将x86指定为目标平台。 如果您正在引用32位PDFViewerNET，那么blahblahblah和生成的exe项目都应该构建为x86，而不是任何CPU。 您还可以使用corflags实用程序（在Visual Studio命令提示符中提供）检查blahblahblah和result.exe的32位标志。 dll和exe都应该设置32BITREQ。如果exe缺少32位标志，那么您可以尝试使用
进行设置corflags /32BITREQ+ result.exe
如果这将修复exe，那么你应该再次检查解决方案配置，并确保将x86（不是任何CPU）指定为exe的目标平台。