2010-08-27 10 views
8

dado una solución donde:¿Cómo construir un proyecto de C# sin verificar las dependencias?

  • Proyecto P1 tiene una referencia a P2
  • P2 tiene una referencia a P3
  • P3 tiene referencia a P4

Cuando se llama a msbuild de esta manera:

msbuild.exe /v:m "c:\mysolution\p1\p1.csproj" 

msbuild comprueba todas las dependencias de proyectos es compilaciones dependen cies si es necesario. La salida típica es:

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. 

    P4 -> c:\mysolution\P4\bin\Debug\P4.dll 
    p3 -> c:\mysolution\p3\bin\Debug\p3.dll 
    p2 -> c:\mysolution\p2\bin\Debug\p2.dll 
    p1 -> c:\mysolution\p1\bin\Debug\p1.dll 

En mi caso, sé que las dependencias existen y están bien.

¿Hay alguna forma de compilar solo el proyecto p1.csproj sin verificar las dependencias? La solución puede ser con msbuild o con algo más.

+0

Me pregunto ... ¿podría llamar al compilador C# en lugar de msbuild y pasar todos los parámetros? ¿Sería difícil descubrir los parámetros que se deben aprobar incluso para un proyecto grande que tiene muchas referencias y dependencias? – Sylvain

+0

Una pregunta relacionada: http://stackoverflow.com/questions/819031/how-to-decrease-msbuild-times – wmeyer

+0

Gracias. Ya usamos compilaciones de múltiples procesadores con msbuild (opción/m) y para nosotros, hace una gran diferencia: cerca de 2 veces más rápido. – Sylvain

Respuesta

4

puede pasar /p:BuildProjectReferences=false a MSBUILD, que se saltará refence proyecto de construcción .. pero esto parece tener una limitación, si su configuración de la solución y se hace referencia configuración del proyecto es desajuste, msbuild será logrado resolver el objetivo del proyecto de referencia archivo de salida...

aquí es un país libre vs paquete de extensión, se puede descargar y probar http://visualstudiogallery.msdn.microsoft.com/98de4058-8dc7-435b-9e01-c0f71dace808

vs paquete: Utilidad Construir agudo

yo soy el autor de esta extensión, tengo el mismo requisito en el trabajo actual , disfrute de esta herramienta ...

esencialmente, esta extensión puede manejar el caso anterior, que hará una copia sombra de su archivo de proyecto de construcción, cambiará toda referencia de proyecto a referencia de archivo dll, y ejecutará msbuild con el archivo de proyecto de sombra.

2

¿Cuál es el objetivo (por qué te importa)?

Puede usar referencias de ensamblado en lugar de referencias de proyecto (pero cuidado con las diferencias de ruta de depuración v release).

+0

Me importa porque en una solución con 100 proyectos, este paso lleva mucho tiempo; 10 veces más tiempo que compilar el proyecto que me interesa. Cambiar la estructura de la solución o usar referencias de ensamblaje no son buenas opciones para mí. – Sylvain

+0

Eso no es lo que veo aquí en mi máquina. Si una ejecución de msbuild en mi proyecto tarda unos 30 segundos, descubro que no hay nada que hacer. Si lo hago de nuevo inmediatamente, tomará otros 30 segundos. Es el proceso de verificar las dependencias que lleva tiempo. Es por eso que quiero omitir esa parte. – Sylvain

+1

Me sorprende que la perforación sea tan mala. Es posible que desee activar los diagnósticos de MSBuild para descubrir lo que tarda tanto. La verificación actualizada debe ser rápida, especialmente si las cosas están actualizadas. Herramientas \ Opciones \ Proyectos y soluciones \ Build & Run cambia la verbosidad de salida de MSBuild a 'diagnóstico', realiza tu acción de 30 segundos y mira la ventana de salida durante (y recorre después) para encontrar la operación 'lenta'. – Brian

1

Quizás podría utilizar Configuration Manager en Visual Studio y desmarcar todos los proyectos, excepto el que desea construir.

+0

Necesito una solución que funcione sin cambiar la solución o los proyectos. Necesito que esto funcione desde la línea de comando. – Sylvain

+0

@Sly: agregue configuraciones separadas a su solución. Puede seleccionar qué configuración construir desde la línea de comando. Esto es similar a los objetivos en el clásico * make *. P.ej. tener una configuración * Release All *, * Debug All *, * Release Subbranch *, * Debug Subbranch *, ... –

0

Echa un vistazo a las mejores prácticas de Microsoft para las soluciones y proyectos estructurantes:

Microsoft Patterns & Practices: Structuring Solutions and Projects

Lo que tenemos actualmente es una es una solución única. Este es el caso ideal que debe usarse siempre que sea posible. Sin embargo, una solución única puede resultar poco práctica para soluciones muy grandes como la suya.

Es posible que desee considerar particionar la solución, es decir, utilizar soluciones separadas para las particiones del árbol de dependencias. O incluso podría considerar usar una llamada solución múltiple. Consulte el artículo vinculado para ver las consecuencias y los inconvenientes de dicho cambio. Tal vez usar hardware más rápido sea la opción preferible.

+0

Como escribí en mi comentario a grefly, necesito una solución que funcione sin cambiar la solución o los proyectos. – Sylvain

+0

Por cierto, solíamos tener varias soluciones (durante varios años) pero cuando haces eso, tienes que decir "bueno" a todas las herramientas de refactorización y "encontrar referencias" y "ir a definición" y eso es peor, luego tiempos de compilación largos . – Sylvain

+0

@Sly: 1.) Una solución particionada funciona sin modificar la solución existente y los proyectos, solo agrega soluciones para las subdivisiones del árbol de particiones. 2.) Lo siento, pero no puedes tener ambos. Para refactorizar y * encontrar referencias * para trabajar, se debe cargar todo el código fuente, es decir, debe usar las referencias del proyecto. Esta es una de las razones para usar una sola solución siempre que sea posible (la razón principal es tener sus dependencias siempre actualizadas y en la versión actual y listas para depurar). –

0

Debe consultar un producto llamado OpenMake. Mi ingeniero jefe de construcción me dice que han hecho mucho con el examen de dependencia y la paralelización de compilación.

OpenMake

Cuestiones relacionadas