AxImp .NET4.0 runtime incompatibilité

J'ai un problème avec la compilation en C#/WPF application à l'aide de MSBuild.

Le problème est le suivant. J'ai créé un projet Visual Studio 2010 avec, par défaut, une application WPF. J'ai créé une "ancienne" Windows Forms usercontrol qui je l'affichage à l'aide du contrôle. La seule chose que cette usercontrol n'est l'affichage d'un document PDF en utilisant le contrôle ActiveX à partir d'Adobe Reader (avec AcroPDFLib).

Cette compile parfaitement sur ma machine locale Windows 7 (64 bits) et VS2010 installé à l'aide de la commande suivante.

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

Cependant, il échoue si je compile il de la même façon sur notre machine de compilation, qui est une machine Windows Server 2008 R2 avec Windows SDK 7.1. Il vient ensuite avec l'erreur suivante (y compris les commentaires):

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.

Comme vous pouvez le voir, le AxImp.exe l'outil n'accepte pas le moment de la compilation généré Interop.AcroPDFLib.dll, en raison d'une incompatibilité d'exécution. J'ai étudié de ce point et la version de AxImp.exe qui est utilisé ici, utilise le .NET runtime 2.0, tandis que le Interop.AcroPDFLib.dll le fichier est à l'aide .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.

Pour être complet, si je l'exécute sur ma machine j'ai le (verbose) sortie:

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.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".

Ici le chemin d'accès de l'AxImp.exe est différent, et cette version ne fait pas usage des .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.

Donc ma question est: Comment puis-je la force de MSBuild pour utiliser la version 4.0 de AxImp au lieu de la version 2.0?

OriginalL'auteur Ralph Schiedon | 2012-05-22

.net-4.0 activex c#msbuild wpf

7

J'ai trouvé une solution à ce problème.

Vous devez spécifier la version du SDK MSBuild à utiliser. Si vous ajoutez ce qui suit supplémentaires en ligne de commande paramètre, il s'travail (au moins dans mon cas).
```
/p:WindowsSDKVersionOverride=v7.1
```
Apparemment MSBuild essaie d'utiliser v7.0A version par défaut, ce qui n'est pas installé sur mon buildserver. De toute façon il décide alors de simplement ignorer tout ce et de retomber .NET 2.0 chemins. J'ai trouvé ceci en retrait de la version 2.0 de AxImp. Puis, il se plaint sur le lien suivant:

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.

Cette clé de registre n'est pas présente sur mon buildserver. Donc, si vous ajoutez la v7.1 version ignorer qu'il va chercher à le droit de clés de registre et utiliser le bon outil versions.

Démarrer + Programmes + kit de développement Microsoft Windows v7.1 + Intégration de Visual Studio + kit de développement logiciel Windows de l'Outil de Configuration.
Cela ne fonctionne pas si vous n'avez pas Visual Studio est installé. Il donne même le message d'erreur Your system does not have Visual Studio 2005 or Visual Studio 2008 installed..
Ce n'est pas une question de licence. Je veux juste un maigre buildserver. Windows SDK devrait être suffisant pour compiler les applications Windows. Je n'ai pas besoin d'un IDE sur mon serveur.

OriginalL'auteur Ralph Schiedon
2

J'ai résolu mon problème d'installation de Windows 8.1 SDK

Dans mon cas, j'ai essayé de compiler un .csproj à l'aide de MSBuild sur un CI Windows 2012 R2 server (CI représente Intégration Continue), bien que les plus pertinents du web questions sur ce sujet suggéré d'installer Windows SDK, ils n'ont pas de pointage EXACTEMENT lequel.

Donc, au début, j'ai deviné qu'ils signifient Windows 10 SDK, qui est aussi la bonne version pour Windows 2012 serveur. Malheureusement, Windows 10 SDK ne comprend pas le manque AxImp.exe SDK fichier.
Donc, comme vous pouvez l'imaginer, il m'a fallu un moment pour comprendre que Windows 8.1 SDK a été la clé de cette énigme.

Encore une fois, espérons que cela aide quelqu'un d'autre 😉

OriginalL'auteur Julio Nobre

Vous devez vous connecter pour publier un commentaire.