Se hizo una pregunta similar y se respondió hace aproximadamente un año, pero era un problema diferente (todo estaba en beta) o se diagnosticó erróneamente. Se encuentra aquí:La tarea MSbuild falla porque la solución "Cualquier CPU" está construida fuera de servicio.

Mi problema es que tengo un proyecto de instalación de wix, y después de actualizar a Tfs2010 el lunes, la compilación falla al vincularse porque no puede encontrar el producto de compilación de la aplicación Wpf en el proyecto. Después de excavar un poco, es porque aún no se ha construido. La construcción en Vs2010 funciona de manera normal. El proyecto wix está configurado para depender del proyecto Wpf, y cuando se visualiza Project Build Order en el IDE, todo parece normal.

El problema se encontró originalmente con solo dos definiciones de plataforma en la solución; x86 y x64. También hay dos tipos, Debug y Release, y TFSBuild.proj está configurado para construir las cuatro combinaciones. No hubo aparición de AnyCPU en ninguna parte. Según la pregunta mencionada anteriormente, intenté cambiar el proyecto Wpf para usar AnyCPU para que se construyera primero. En este punto, el proyecto wix usó la configuración exacta y el proyecto Wpf usó el sabor con AnyCPU. Sin embargo, hacerlo no pareció cambiar nada.

Estoy usando Tfs2010 RTM, Vs2010 RTM y la versión más reciente de Wix, que en el momento de escribir este artículo es 3.5.1602.0, del 2010-04-02. ¿Alguien más se encuentra con esto?

2010-04-27: Después de una buena cantidad de excavación y reproducción en una máquina de construcción de VM clonada, creo que sé lo que está sucediendo y también lo que está fallando, pero no sé cómo solucionarlo.

La situación es que este error parece exhibir síntomas basados en la ordenación del proyecto pura suerte en el archivo de la solución. Parece que el archivo de solución solo construirá ciegamente los proyectos en el orden en que aparecen, confiando en su capacidad para detectar referencias no compiladas y construirlas a pedido cuando sea necesario.

En mi archivo de solución particular, mi proyecto Wix se ordenó antes que mi proyecto de aplicación Wpf. Esto dio como resultado que el proyecto Wix se construyera primero, y si bien la dependencia del proyecto Wpf se detectó correctamente, la tarea real de MSBuild se omitió debido a la variable indefinida $ (BuildProjectReferences). Menciono un par de comentarios desde la publicación principal en este hilo. Con la verbosidad de MSBuild aún en diagnóstico, BuildProjectReferences puede verse como indefinido construyendo el proyecto Wix, y puede verse definido como verdadero al construir el proyecto Wpf dentro de la tarea de construir el proyecto Wix. Sin embargo, cuando se prueba, se evalúa indefinido nuevamente, la tarea se omite y la compilación Wix falla porque no puede encontrar la salida de compilación del proyecto Wpf no construido.

En resumen: la dependencia del proyecto se omite debido a la variable $ (BuildProjectReferences) incorrecta. Curiosamente, esta variable está presente solo en el archivo Wix2010.targets, y no en wix.targets; Supongo que es por eso que esto solo aparece después de instalar Tfs2010 y Vs2010.

La solución: ¿Cómo me aseguro de que BuildProjectReferences se pase correctamente a las tareas subsiguientes de MSBuild? ¿Hay algo especial con alcance variable pasando?

2010-09-14: Se abrió un error para este problema en el conjunto de herramientas WiX:http://sourceforge.net/tracker/?func=detail&atid=642714&aid=2990231&group_id=105970 y arreglado hace un tiempo. Con suerte, esto ya no es un problema. Si es así, abra un nuevo error.

Para abordar su comentario directamente, nada en mi solución tiene una configuración AnyCPU en sus archivos de compilación. Creé las configuraciones de AnyCPU solo para probar la solución sugerida por el hilo al que me vinculé en mi publicación original. Después de que no funcionó, eliminé las configuraciones de AnyCPU nuevamente.

Además, los proyectos están en el mismo archivo de solución, sin embargo, en carpetas de solución separadas (carpeta de interfaz, carpeta de instalador) si eso es importante.

Curiosamente, iba a hacer un pequeño ejemplo de sandbox para poder ilustrar el problema que tenía, sin embargo, después de crear mi pequeña solución de muestra, no pude reproducir el error. Esto me hace pensar que quizás esto es el resultado de usar un proyecto de equipo que se actualizó desde un proyecto de equipo Tfs2008 en lugar de uno que se creó recientemente en Tfs2010. Puedo intentar ramificar mi proyecto en uno nuevo para probar esta teoría si no puedo entender por qué funciona la solución de prueba.

PD. Además, soy nuevo en stackoverflow: ¿por qué los comentarios tienen una longitud limitada si el flujo de trabajo de "responda su propia pregunta" está destinado únicamente a proporcionar respuestas concretas?

Así que lancé la verbosidad de construcción al diagnóstico y la leí hoy, y una línea en particular me llamó la atención:

Task "MSBuild" skipped, due to false condition; ('@(_ProjectReferenceWithConfiguration)'!='' and '$(BuildingInsideVisualStudio)' != 'true' and '$(BuildProjectReferences)' == 'true' and '@(_MSBuildProjectReferenceExistent)' != '') was evaluated as ('..\WpfApp\WpfApp.csproj'!='' and '' != 'true' and '' == 'true' and '..\WpfApp\WpfApp.csproj' != '').

Esto se vio cuando mi proyecto instalador intentaba construir mi proyecto wpf ya que se hace referencia al proyecto wpf. En particular, por alguna razón $ (BuildProjectReferences) está evaluando a '' cuando estoy bastante seguro de que debería ser 'verdadero'.

Sin embargo, anteriormente en el registro, al comienzo de la tarea MSBuild para el proyecto WpfApp, vi esto:

Task "MSBuild" (TaskId:15)
...
Initial Properties:
...
BuildProjectReferences = true

Entonces, ¿la propiedad era correcta hasta el comienzo de la tarea, pero luego aparentemente se sobrescribió? No estoy seguro de cómo se establecen estas propiedades.