TeamCity build differs from Visual Studio 2010 build

Question

We are developing an application using Visual Studio 2010. All of our projects are set to .NET framework 3.5 with platform x86.

We are using an external library PDFViewerNET, for which we loaded the .NET 3.5 32bit version from http://code.google.com/p/pdfviewer-win32/downloads/list

We included its PDFLibNet.DLL into our own .NET 3.5 assembly, which built just fine. Then we include the resulting assembly DLL into our application project (.NET 3.5 x86). The application is compiling and building fine in VS. It can be run and debugged inside VS and started from a drive (Release configuration was used for all builds). As soon as we access methods from the assembly, it's working just fine.

The appilication was originally developed for .NET framework 4.0 with "AnyCPU" platform. We migrated back to .NET 3.5 because we plan to use EMC Documentum 6.7 assemblies which require .NET 3.5. But this is not yet implemented ...

Now ... we use TeamCity Enterprise 7.1.5 (build 24400) for deployment and check builds. The build configuration was just fine with the MSBuild .NET 4.0 (Toolset 4.0) x64 settings we used before. Now we had to switch to MSBuild .NET 3.5 (Toolset 3.5) x86.

The build is running fine. But when we start the resulting application and try to access methods from the assembly (which is the same version that we use inside VS), it fails with error

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 is our own assembly, which includes PDFLibNet.DLL. All of the DLL files are in the same folder as the resulting EXE. The EXE is 575KB compared to 593KB when built with VS...

Any ideas?

Answer 1

Make sure that you are building the same solution configuration in VS and TeamCity (Build / Configiration Manager). Detele any unused solution configurations. Even if configuration is named "Any CPU", some projects could have x86 specified as target platform. If you are referencing 32-bit PDFViewerNET, than both blahblahblah and resulting exe project should be built as x86, not as Any CPU. You can also check 32-bit flag for blahblahblah and result.exe using corflags utility (available in Visual Studio Command prompt). Both dll and exe should have 32BITREQ set. If 32-bit flag is missing for exe, thatn you could try to set it using

corflags /32BITREQ+ result.exe

if that will fix the exe, then you should check solution configuration again, and make sure that x86 (not Any CPU) is specified as a target platform for exe.