DLL de proyecto de nieto C#no incluidos en el paquete msbuild
dependencies azure-web-sites (2)
No hay una forma sencilla de hacerlo, aunque este problema se haya planteado varias veces con msbuild. En términos de soluciones, las más populares son hacer uso del ensamblaje del proyecto ''Z'' (crear una instancia ficticia de alguna clase del proyecto ''Z'' en el proyecto ''X'') o agregar una referencia directa en el Proyecto ''X'' al proyecto ''Z''.
La solución más limpia en mi opinión se explica en este blog . Básicamente, implica la creación de un archivo .targets separado, que no es más que instrucciones para msbuild para garantizar que, al compilar y empaquetar las DLL, también incluya todas las dependencias transitivas. Este archivo .targets debe agregarse a su archivo X.csproj para que al construirlo utilizando msbuild, se invoque este archivo de destino.
Tengo un proyecto de C # X que hace referencia a un proyecto de C # Y que hace referencia a un proyecto de C # Z. Así que la cadena de dependencias se ve así: X => Y => Z. No hay una dependencia directa / explícita X => Z. Cuando compilo un paquete para publicación usando el comando msbuild
msbuild DesignService.csproj /m /p:Configuration="Debug" /p:Platform="AnyCPU" /verbosity:quiet /t:Package /p:PackageLocation=X.zip /p:PackageAsSingleFile=True
Obtengo un archivo zip que tiene DLL para X e Y, pero no Z. Luego, cuando se publica el paquete (para un Servicio de aplicaciones de Azure), obtengo errores de tiempo de ejecución cuando se realiza una llamada al código en Z, diciendo que la DLL no puede ser encontró. Si agrego Z como referencia directa / explícita en X, funciona bien. Pero no creo que deba hacer esto.
¿Cómo puedo obtener DLLs para Z en mi paquete de publicación desde msbuild sin agregar una referencia explícita en X?
Por qué pasó esto
Se invocó X.csproj y, debido a que tiene una referencia de proyecto a Y.csproj, invoca a Y.csproj: "va por la parte de atrás". Z.csproj no necesariamente ha construido todavía, así que la compilación se rompe.
Como arreglar
Siga este principio : no utilice las dependencias expresadas en el archivo de la solución en absoluto.
Podría poner una referencia de proyecto en el proyecto en su lugar. Se vería así: tenga en cuenta el elemento de metadatos, y todo esto está dentro de una etiqueta <ItemGroup> por supuesto:
<ProjectReference Include=”… foo.csproj”>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
Aunque es tedioso tener que editar sus proyectos de esta manera para que desaparezca el error, es una buena práctica usar referencias de proyectos y considerar el archivo de la solución simplemente como una "vista".
Terminará con proyectos que, si lo desea, se pueden construir sin un archivo de solución.
Para obtener más detalles sobre cómo solucionar el problema, puede consultar este blog .