Warum lädt das 64-Bit-MSBuild 32-Bit-Erweiterungen?

Question

Ich versuche, ein Projekt mit MSBuild (v4.0) auf einer 64-Bit-Maschine zu erstellen. Aus irgendeinem Grund versucht MSBuild, eine 32-Bit-Erweiterung zu laden, und ich kann nicht herausfinden, warum. Ich habe das Problem auf den kleinsten Satz reduziert, um das Problem zu demonstrieren.

die folgende MSBuild-Projektdatei:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0"> 
    <Target Name="test"> 
     <Message Text="bin path: $(MSBuildBinPath)" /> 
     <Message Text="extensions path: $(MSBuildExtensionsPath)" /> 
     <Message Text="extensions path (x86): $(MSBuildExtensionsPath32)" /> 
     <Message Text="extensions path (x64): $(MSBuildExtensionsPath64)" /> 
    </Target> 
</Project> 

ich diese Ausgabe:

Microsoft (R) Build Engine Version 4.0.30319.1 
[Microsoft .NET Framework, Version 4.0.30319.1] 
Copyright (C) Microsoft Corporation 2007. All rights reserved. 

Build started 8/27/2010 9:56:35 AM. 
Project "D:\5\test.proj" on node 1 (default targets). 
test: 
    bin path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319 
    extensions path: C:\Program Files (x86)\MSBuild 
    extensions path (x86): C:\Program Files (x86)\MSBuild 
    extensions path (x64): C:\Program Files\MSBuild 
Done Building Project "D:\5\test.proj" (default targets). 


Build succeeded. 
    0 Warning(s) 
    0 Error(s) 

Time Elapsed 00:00:00.03 

MSBuild offensichtlich weiß um die 32-Bit- und 64-Bit-Erweiterungen Pfad, und aus dem binären Pfad scheint es klar, dass Ich führe die 64-Bit MSBuild.exe, aber aus irgendeinem Grund glaubt, dass Erweiterungen von Program Files (x86) anstelle von Program Files geladen werden sollten. Das verursacht mir Probleme, da ich eine Erweiterung habe, die ich laden muss, die korrekt in einem 32bit/64bit-Prozess geladen werden muss, und es wird nicht geladen (MSBuild versucht, die 32-Bitversion in einem 64-Bitprozess zu laden).

Warum?

Answer 1

I filed a bug auf Microsoft Connect, und es wurde als „By Design“, mit dieser Erklärung geschlossen:

Sie sind genau richtig - das hat sich geändert, und streng genommen, jetzt ist es falsch. Dies war jedoch eine bewusste Entscheidung. Der Grund, warum es geändert wurde, war, dass sehr viele Erweiterungen (wie z. B. .targets-Dateien), die von anderen Produkten installiert wurden, nur im Speicherort der 32-Bit-Programmdateien installiert wurden. Sie erwarteten keine 64-Bit-Szenarien, aber im Allgemeinen würden sie in 64-Bit-MSBuild gut funktionieren. Wenn ein Benutzer 64-Bit-MSBuild ausführt, was heutzutage ziemlich üblich ist, weil es der Standard für Team Build 2010 ist, hätte MSBuildExtensionsPath in der Vergangenheit in den 64-Bit-Programmdateien wie erwartet aufgelöst. Dies bedeutete jedoch, dass all diese .targets-Dateien nicht mehr gefunden wurden und der Build fehlschlug. Es war nicht praktikabel, alle diese Produkte zu bekommen, um ihre Setup-Authoring zu reparieren, besonders da sie bereits an Kunden ausgeliefert wurde. Daher haben wir die Änderung vorgenommen, damit MSBuildExetensionsPath immer auf den 32-Bit-Speicherort verweist. Fast niemand scheint den 64-Bit-Standort wirklich zu wollen, und diese Leute können zu MSBuildExtensionsPath64 wechseln. Es war wirklich eine Frage der schlechtesten Option hier.

Ich akzeptiere die Beweise, aber ich stimme nicht mit der Schlussfolgerung überein. Ich glaube, dass Autoren von kaputten Installern es verdienen, dass ihre Erweiterungen nicht auf 64-Bit-Rechnern funktionieren.