Edificio de proyectos innecesarios de Visual Studio 2008

Question

Tengo un proyecto de C# que incluye un exe y 11 archivos de biblioteca. El exe hace referencia a todas las bibliotecas, y lib1 puede hacer referencia a lib2, lib3, lib4, etc.

Si realizo un cambio en una clase en lib1 y creo la solución, asumí que solo lib1 y el exe tendrían que ser cambiado Sin embargo, todos los dll y el exe se están construyendo si quiero ejecutar la solución.

¿Hay una manera que puedo detener las dependencias de ser construida, si no han sido cambiados?

Answer 1

¿Está la clave esta frase? "Sin embargo, todos los DLL y el exe se están construyendo si quiero ejecutar la solución"

Visual Studio siempre tratará de construir todo cuando se ejecuta un solo proyecto, incluso si ese proyecto no depende en todo. Esta elección puede ser cambiada, sin embargo. Vaya a Herramientas | Opciones | Proyectos y soluciones | Crear y ejecutar y marque la casilla "Solo crear proyectos de inicio y dependencias en Ejecutar". Luego, cuando presione F5, VS solo construirá su proyecto de inicio y los archivos DLL de los que depende.

Answer 2

Puede desactivar la opción de construcción para proyectos específicos en su Solution configuration:

SolutionProperties http://i.msdn.microsoft.com/Bb166577.vsSolutionCfg(en-us,VS.90).gif

Puede puede crear sus propias configuraciones de soluciones para construir configuraciones de proyectos específicos ...

build config http://i.msdn.microsoft.com/Bb166577.vsConfigManager(en-us,VS.90).gif

Answer 3

No estoy seguro de si hay alguna manera de evitar que se creen dependencias. Puede encontrar información aquí, como configurar copylocal en false y poner los dlls en un directorio común.

Optimizing Visual Studio solution build - where to put DLL files?

Answer 4

No creo que haya distancia para que lo haga fuera de la caja en VS. Necesita este complemento http://workspacewhiz.com/

No es gratis, pero puede evaluarlo antes de comprarlo.

Answer 5

Sí, excluyen a los bits no cambian de la solución. Digo esto con una advertencia, ya que puedes compilar de una manera en la que un cambio en el número de compilación para el lib modificado puede hacer que las piezas no construidas se rompan. Este no debería ser el caso, siempre y cuando no rompa la interfaz, pero es bastante común porque la mayoría de los desarrolladores no entienden la interfaz en el mundo .NET. Viene de no tener que escribir IDL. :-)

En cuanto a projcts X en una solución, NO, no se puede detener su construcción, ya que el sistema ve una dependencia ha cambiado.

Por cierto, usted debe buscar en su proyecto y averiguar por qué su proyecto de interfaz de usuario (UI asuma que se) hace referencia a la misma biblioteca que todo lo demás. Un buen modelo de dependencia mostrará las clases que deberían desglosarse como objetos de datos u objetos de dominio (he supuesto que la dependencia común es algún tipo de objeto de datos u objeto de dominio, por supuesto, pero eso es bastante común) Si la dependencia común no es un objeto de dominio/datos, en la mayoría de los casos volvería a pensar en mi arquitectura. En general, debería poder crear una ruta desde UI a datos sin dependencias comunes que no sean objetos no conductuales.

Answer 6

Ahora, después de decir esto, algunos hélice de cabeza va a venir y contradecirme, pero no hay manera de hacer lo que quiere hacer desde Visual Studio. Hay una manera de hacerlo fuera de VS, pero primero, tengo una pregunta:

qué en la tierra que quiere hacer esto? Tal vez intentes ahorrar ciclos de CPU o ahorrar tiempo de compilación, pero si haces lo que estás sugiriendo, de repente te encontrarás en una posición maravillosa para dispararte en el pie. Si tiene una biblioteca 1 que depende de la biblioteca 2 y solo cambia la biblioteca 2, puede pensar que está bien para construir solo la biblioteca modificada, pero uno de estos días hará un cambio en la biblioteca 2 que se romperá biblioteca 1, y sin una compilación de biblioteca 2 no lo captará en la compilación. Entonces, en mi humilde opinión, NO LO HAGAS.

La razón por la que esto no funcionará en VS2005 y 2008 es porque VS usa MSBuild. MSBuild se ejecuta contra los archivos del proyecto, y examinará las referencias del proyecto y creará todos los proyectos referenciados primero, si su fuente ha cambiado, antes de construir el proyecto objetivo. Puede probarlo usted mismo ejecutando MSBuild desde la línea de comando contra un proyecto que no ha cambiado pero con un proyecto referenciado que ha cambiado. Ejemplo:

msbuild ClassLibrary4.csproj

donde ClassLibrary4 no ha cambiado, pero hace referencia a ClassLibrary5, que ha cambiado. MSBuild compilará lib 5 primero, antes de compilar 4, aunque no mencionó 5.

La única forma de evitar estas fallas es utilizar el compilador directamente en lugar de pasar por MSBuild. Feo, feo, pero eso es todo. Básicamente, se verá reducido a volver a implementar MSBuild de alguna forma para hacer lo que desea hacer.

No vale la pena.

Answer 7

De hecho, tuvimos este problema en mi proyecto actual, en nuestro escenario, incluso la ejecución de pruebas unitarias (sin ningún cambio de código) causaba una recompilación. Comprueba la "Plataforma" de tu configuración de compilación.

Si está utilizando "Cualquier CPU", por alguna razón, reconstruye todos los proyectos independientemente de los cambios. Intente utilizar compilaciones específicas del procesador, es decir, x86 o x64 (utilice la plataforma que es específica para la arquitectura de la máquina de su máquina). Funcionó para nosotros para las compilaciones x86.

alt text http://labs.episerver.com/Global/xmlrpc/111856/2008/06/24/image_26.png

Answer 8

Hemos tenido un problema similar en el trabajo. En los eventos posteriores a la construcción estábamos incorporando manualmente manifiestos en las salidas en el directorio bin. Visual Studio copiaba referencias de proyectos del directorio obj (que no se modificaron). La diferencia de marca de tiempo provocó reconstrucciones innecesarias.

Si los eventos posteriores a la construcción modifican las salidas del proyecto, modifique las salidas en el directorio bin y obj o copie las salidas modificadas en el directorio bin encima de las del directorio obj.

Answer 9

No estoy seguro de una manera increíble de manejar esto, pero en el pasado si tenía un proyecto o dos que seguían siendo reconstruidos, y suponiendo que no estaría trabajando en ellos, les quitaba el proceso de compilación .

Haga clic derecho en el sln, seleccione el administrador de configuración y desmarque las casillas de verificación. No es perfecto, pero funciona cuando Visual Studio no se comporta.

Answer 10

Consulte el following site para obtener información más detallada sobre cuándo se construye un proyecto y las diferencias entre compilación y reconstrucción.

Answer 11

tuve este problema también, y se dio cuenta estos mensajes de advertencia cuando se construye en Windows 7 x64, VS2008 SP1:

CL: Comando D9038 advertencia línea:/ZI no es compatible con esta plataforma; Habilitar/Zi en su lugar

cl: Advertencia de la línea de comando D9007: '/ Gm' requiere '/ Zi'; opción ignorada

he cambiado mis propiedades del proyecto a:

C/C++ -> General -> Información del formato de depuración =/Zi

C/C++ -> Generación de código -> Habilitar Construir Mínimo = No se

Después de la reconstrucción, los cambié a ambos y las dependencias vuelven a funcionar bien. Pero antes de eso, ninguna cantidad de limpieza, reconstrucción o eliminación completa del directorio de salida lo solucionaría.

Answer 12

Acabo de "arreglar" el mismo problema con mi proyecto VS. Visual Studio siempre hizo una reconstrucción, incluso si no cambió nada. Mi solución: One cs-File tenía una marca de tiempo futura (año 2015, esto fue mi culpa). ¡Abrí el archivo, lo guardé y mi problema fue resuelto!

Answer 13

Si continúa teniendo este problema, puede deberse a una dependencia calculada faltante o desactualizada (como un encabezado) que figura en su proyecto, pero que no existe.

Esto me ocurre especialmente después de migrar a una nueva versión (por ejemplo: de 2012 a 2013) porque VS puede haber recalculado dependencias en la conversión, o está migrando a una nueva ubicación.

Una comprobación rápida consiste en hacer doble clic en todos los archivos del proyecto infractor desde el explorador de soluciones. Si descubres que un archivo no existe, ese es tu problema.

Error de un simple archivo que falta: Es posible que tenga una relación de fecha de compilación más complicada entre el origen y el destino. Puede usar una utilidad para averiguar qué prueba de front-end está activando la compilación. Para obtener esa información, puede habilitar el registro detallado de CPS. Ver: Andrew Arnott - Habilitar el rastreo del sistema de proyectos C++ y Javascript (http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx). Yo uso la opción DebugView. Herramienta invaluable cuando la necesita.

(esta es una pregunta específica C#, pero otro puesto se fusionó como idénticos)