Question

I have a problem with the compilation of a C#/WPF application using MSBuild.

The problem is the following. I have created a Visual Studio 2010 project with a default WPF application. I created an “old fashioned” Windows Forms usercontrol which I display using the control. The only thing this usercontrol does is displaying a PDF document using the ActiveX control from Adobe Reader (with AcroPDFLib).

This compiles perfectly on my local machine that has Windows 7 (64 bit) and VS2010 installed using the following command.

>C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe AcroPDFTest.sln /p:Configuration=Debug /t:Rebuild /verbosity:d

However, it fails if I compile it the same way on our build machine, which is a Windows Server 2008 R2 machine with Windows SDK 7.1. It then comes up with the following error (including verbose output):

Using "ResolveComReference" task from assembly "Microsoft.Build.Tasks.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
Task "ResolveComReference"
  Creating new cache file at "obj\x86\Debug\AcroPDFTest.csproj.ResolveComReference.cache".
  Resolving COM reference for item "AcroPDFLib" with a wrapper "tlbimp".
  Determining dependencies of the COM reference "AcroPDFLib".
  Resolving COM reference dependency "00020430-0000-0000-c000-000000000046" version 2.0.
  Resolved COM reference dependency "00020430-0000-0000-c000-000000000046" version 2.0: "obj\x86\Debug\Interop.stdole.dll"
  Type '_IAcroAXDocShimEvents' imported.
  Type 'AcroPDF' imported.
  Type 'IAcroAXDocShim' imported.
  Type 'AdobeSPOpenDocuments' imported.
  Type 'ISPOpenDocuments' imported.
  Resolved COM reference for item "AcroPDFLib": "obj\x86\Debug\Interop.AcroPDFLib.dll".
  Resolving COM reference for item "AxAcroPDFLib" with a wrapper "aximp".
  Determining dependencies of the COM reference "AxAcroPDFLib".
  C:\Program Files\Microsoft SDKs\Windows\v7.1\bin\AxImp.exe "C:\Program Files (x86)\Common Files\Adobe\Acrobat\ActiveX\AcroPDF.dll" /out:obj\x86\Debug\AxInterop.AcroPDFLib.dll /rcw:obj\x86\Debug\Interop.AcroPDFLib.dll 
AXIMP : AxImp error : The assembly '[snip]\obj\x86\Debug\Interop.AcroPDFLib.dll' failed to load with this error: Could not load file or assembly 'file:///[snip]\obj\x86\Debug\Interop.AcroPDFLib.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.. [[snip]\AcroPDFTest.csproj]
  The command exited with code -1163019603.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1558,9): warning MSB3283: Cannot find wrapper assembly for type library "AxAcroPDFLib". [[snip]\AcroPDFTest.csproj]
Done executing task "ResolveComReference" -- FAILED.

As you can see, the AxImp.exe tool does not accept the compile-time generated Interop.AcroPDFLib.dll, because of a runtime mismatch. I investigated this further and the version of AxImp.exe that is being used here uses the .NET 2.0 runtime, while the Interop.AcroPDFLib.dll file is using .NET 4.0:

>"C:\Program Files\Microsoft SDKs\Windows\v7.1\bin\AxImp.exe" /?
Microsoft (R) .NET ActiveX Control to Windows Forms Assembly Generator
[Microsoft .Net Framework, Version 2.0.50727.5456]
Copyright (c) Microsoft Corporation.  All rights reserved.

For completeness, if I run this on my machine I get the following (verbose) output:

Using "ResolveComReference" task from assembly "Microsoft.Build.Tasks.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
Task "ResolveComReference"
  Creating new cache file at "obj\x86\Debug\AcroPDFTest.csproj.ResolveComReference.cache".
  Resolving COM reference for item "AcroPDFLib" with a wrapper "tlbimp".
  Determining dependencies of the COM reference "AcroPDFLib".
  Resolving COM reference dependency "00020430-0000-0000-c000-000000000046" version 2.0.
  Resolved COM reference dependency "00020430-0000-0000-c000-000000000046" version 2.0: "C:\Windows\assembly\GAC\stdole\7.0.3300.0__b03f5f7f11d50a3a\stdole.dll"
  Type '_IAcroAXDocShimEvents' imported.
  Type 'AcroPDF' imported.
  Type 'IAcroAXDocShim' imported.
  Type 'AdobeSPOpenDocuments' imported.
  Type 'ISPOpenDocuments' imported.
  Resolved COM reference for item "AcroPDFLib": "obj\x86\Debug\Interop.AcroPDFLib.dll".
  Resolving COM reference for item "AxAcroPDFLib" with a wrapper "aximp".
  Determining dependencies of the COM reference "AxAcroPDFLib".
  C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\AxImp.exe "C:\Program Files (x86)\Common Files\Adobe\Acrobat\ActiveX\AcroPDF.dll" /out:obj\x86\Debug\AxInterop.AcroPDFLib.dll /rcw:obj\x86\Debug\Interop.AcroPDFLib.dll 
  Generated Assembly: [snip]\obj\x86\Debug\AxInterop.AcroPDFLib.dll
  Resolved COM reference for item "AxAcroPDFLib": "obj\x86\Debug\AxInterop.AcroPDFLib.dll".
Done executing task "ResolveComReference".

Here the path of the AxImp.exe is different, and this version does use the .NET 4.0 runtime:

>"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\AxImp.exe" /?
Microsoft (R) .NET ActiveX Control to Windows Forms Assembly Generator
[Microsoft .Net Framework, Version 4.0.30319.269]
Copyright (c) Microsoft Corporation.  All rights reserved.

So my question is: How can I force MSBuild to use the 4.0 version of AxImp instead of the 2.0 version?

Answer 1

I found one solution to this problem.

You have to specify which SDK version MSBuild should use. If you add the following extra commandline parameter it will work (at least in my situation).

/p:WindowsSDKVersionOverride=v7.1

Apparently MSBuild tries to use v7.0A version by default, which is not installed on my buildserver. It somehow then decides to just ignore everything and fall back to .NET 2.0 paths. I found this out by removing the 2.0 version of AxImp. It then complains about the folllowing:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1558,9): error MSB3091: Task failed because "AxImp.exe" was not found, or the correct Microsoft Windows SDK is not installed. The task is looking for "AxImp.exe" in the "bin" subdirectory beneath the location specified in the InstallationFolder value of the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A. You may be able to solve the problem by doing one of the following: 1) Install the Microsoft Windows SDK. 2) Install Visual Studio 2010. 3) Manually set the above registry key to the correct location. 4) Pass the correct location into the "ToolPath" parameter of the task.

That registry key is not present on my buildserver. So if you add the v7.1 version override it will look at the right registry keys and use the correct tool versions.