2008-09-26 26 views
13

Me encontré en una situación extraña con MSBuild justo ahora. Hay una solución que tiene tres proyectos: LibX, LibY y Exe. Exe hace referencia a LibX. LibX, a su vez, hace referencia a LibY, tiene algunos archivos de contenido y también referencias a una biblioteca de terceros (varios ensamblados preconstruidos instalados tanto en la carpeta GAC ​​como en la lib local). La biblioteca de terceros está marcada como "Copiar local" ("privada") y aparece en la salida del proyecto LibX, como lo hacen la salida de LibY y los archivos de contenido de LibX. Ahora, la salida del proyecto Exe tiene salida de proyecto LibX, archivos de contenido del proyecto LibX, salida del proyecto LibY (proveniente de LibX), pero NO ensambles de bibliotecas de terceros.MSBuild no recoge las referencias del proyecto al que se hace referencia

Ahora trabajé esto al hacer referencia a la biblioteca de terceros directamente en el proyecto Exe, pero no creo que esta sea una solución "correcta".

¿Alguien ha tenido este problema antes?

+0

¿Alguna solución final con el código fuente completo de la muestra trabajando al respecto? – Kiquenet

Respuesta

2

Sí, he tenido ese problema también. Aunque me gustaría decir lo contrario, creo que debes incluir todas las dependencias transitivas como referencias en tu archivo de compilación.

4

En realidad se puede entrar en el archivo Microsoft.CSharp.targets o Microsoft.VisualBasic.targets (que se encuentra en el directorio de marco, normalmente C: \ Windows \ Microsoft.NET \ Framework \ v3.5) y modificar el CSC o los parámetros de la tarea vbc para incluir dependencias de referencia adicionales. En el archivo (objetivos VB, línea 166; C# Objetivos, línea 164) el cambio: \

References="@(ReferencePath)" 

a

References="@(ReferencePath);@(ReferenceDependencyPaths)" 

Esto podría causar otros problemas dependiendo de cómo las cosas complicadas son y puede jugar una mala pasada con el compilador inproc de Visual Studio, pero es la única forma de hacerlo en MSBuild que he encontrado.

+0

Esto no tuvo ningún efecto para mí al principio, pero luego descubrí que (al menos en 'Framework \ v4.0.30319') esa línea aparece dos veces en cada uno de los archivos' .targets'. – CoderDennis

12

Existe una diferencia de comportamiento al compilar con MSBuild (es decir, línea de comandos, compilación TFS y otras herramientas) en comparación con compilar con Visual Studio. Las referencias secundarias no están incluidas en la variable de referencias enviada a las tareas de compilación de MSBuild.

Hay varios puntos de extensión proporcionados por MSBuild para cambiar cómo se van a resolver las referencias. He utilizado satisfactoriamente AfterResolveReference para solucionar este problema en algunos de mis proyectos: I have posted more info about the background on my blog.

La solución consiste en añadir el siguiente código en que vbproj o archivos csproj

<Target Name="AfterResolveReferences"> 
    <!-- Redefine referencepath to add dependencyies--> 
    <ItemGroup> 
    <ReferencePath Include="@(ReferenceDependencyPaths)"> 
    </ReferencePath> 
    </ItemGroup> 
    </Target> 

Microsoft ha declarado que este es un no va a fijar en Connect

+0

Excelente. Esta es realmente una mejor solución para el problema. –

3

La respuesta de josant casi funcionó para mí; Obtuve un error en Visual Studio cuando lo intenté:

Ocurrió un problema al intentar establecer el parámetro "Referencias" para el compilador en proceso del IDE.De error HRESULT E_FAIL ha sido devuelto de una llamada a un componente COM

La solución a mi problema era poner una condición en la ItemGroup, así:

<Target Name="AfterResolveReferences"> 
    <!-- Redefine referencepath to add dependencies--> 
    <ItemGroup Condition=" '$(BuildingInsideVisualStudio)' != 'true' "> 
    <ReferencePath Include="@(ReferenceDependencyPaths)"></ReferencePath> 
    </ItemGroup> 
</Target> 

que causó Visual Studio para ignorar la referencia cambiar completamente, y la compilación funciona bien localmente y en el servidor de compilación.

Cuestiones relacionadas