0

我们正在使用 Visual Studio 2010 开发一个应用程序。我们所有的项目都设置为具有 x86 平台的 .NET 框架 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 中运行和调试，并从驱动器启动（发布配置用于所有构建）。一旦我们从程序集中访问方法，它就可以正常工作。

该应用程序最初是为具有“AnyCPU”平台的 .NET 框架 4.0 开发的。我们迁移回 .NET 3.5 是因为我们计划使用需要 .NET 3.5 的 EMC Documentum 6.7 程序集。但这尚未实施...

现在......我们使用 TeamCity Enterprise 7.1.5（内部版本 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...

有任何想法吗？

4

1 回答 1

1

确保您在 VS 和 TeamCity（构建/配置管理器）中构建相同的解决方案配置。删除任何未使用的解决方案配置。即使配置被命名为“任何 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 的目标平台。

于 2013-11-06T07:44:00.050 回答