¿Por qué la MSBuild de 64 bits carga extensiones de 32 bits?

Question

Estoy intentando construir un proyecto usando MSBuild (v4.0) en una máquina de 64 bits. Por alguna razón, MSBuild está intentando cargar una extensión de 32 bits, y no puedo entender por qué. Reduje el problema al conjunto más pequeño para demostrar el problema.

Usando el siguiente archivo de proyecto de MSBuild:

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

puedo obtener este resultado:

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 obviamente sabe acerca de la ruta de 32 bits y 64 bits extensiones, y de la ruta binaria parece claro que Estoy ejecutando el MSBuild.exe de 64 bits, pero por alguna razón cree que las extensiones se deben cargar desde Program Files (x86) en lugar de Program Files. Esto me está causando problemas, ya que tengo una extensión que necesito cargar, que DEBE cargarse correctamente en un proceso de 32 bits/64 bits, y no se cargará (MSBuild está intentando cargar la versión de 32 bits en un proceso de 64 bits).

¿Por qué?

Answer 1

I filed a bug en Microsoft Connect, y estaba cerrado como "por diseño", con esta explicación:

Usted es exactamente correcto - esto ha cambiado, y estrictamente hablando, es mal ahora. Sin embargo, esta fue una decisión consciente. La razón por la que se modificó fue que muchas extensiones (como archivos .targets) instaladas por otros productos solo se instalan en la ubicación de los archivos de programa de 32 bits. No anticiparon escenarios de 64 bits, pero generalmente funcionarían bien en MSBuild de 64 bits. Cuando un usuario ejecuta MSBuild de 64 bits, que es bastante común ahora porque es el predeterminado para Team Build 2010, MSBuildExtensionsPath se habría resuelto en el pasado a los archivos de programa de 64 bits como usted esperaba. Sin embargo, esto significaba que todos esos archivos .targets ya no se encontraban y la compilación fallaba. No fue práctico obtener todos esos productos para corregir su creación de configuración, especialmente porque ya se envió a los clientes. Así que hicimos el cambio para hacer que MSBuildExetnsionsPath siempre apunte a la ubicación de 32 bits. Casi nadie parece querer realmente la ubicación de 64 bits, y esas personas pueden cambiar a MSBuildExtensionsPath64. Realmente fue una cuestión de la opción menos mala aquí.

Acepto la evidencia, pero no estoy de acuerdo con la conclusión. Creo que los autores de instaladores rotos merecen que sus extensiones no funcionen en máquinas de 64 bits.