Visual Studio 2008 Edificio di progetto non necessario

Question

Ho un progetto C# che include un file exe e 11 file di libreria. L'exe fa riferimento a tutte le librerie e lib1 può fare riferimento a lib2, lib3, lib4, ecc.

Se applico una classe in lib1 e ho costruito la soluzione, ho presupposto che solo la lib1 e l'exe avrebbero dovuto essere cambiato. Tuttavia, tutte le DLL e gli exe vengono creati se voglio eseguire la soluzione.

C'è un modo per impedire che le dipendenze vengano costruite se non sono state modificate?

Answer 1

La chiave è questa frase? "Tuttavia, tutte le DLL e EXE sono in costruzione se voglio eseguire la soluzione"

Visual Studio cercherà sempre di costruire tutto quando si esegue un singolo progetto, anche se questo progetto non dipende su tutto. Questa scelta può essere modificata, tuttavia. Vai a Strumenti | Opzioni | Progetti e soluzioni | Crea ed esegui e seleziona la casella "Crea solo progetti di avvio e dipendenze su Esegui". Quindi quando si preme F5, VS costruirà solo il progetto di avvio e le DLL da cui dipende.

Answer 2

È possibile deselezionare l'opzione di compilazione per progetti specifici nel vostro Solution configuration:

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

È possibile possibile creare il proprio configurazioni della soluzione per costruire configurazioni specifiche di progetto ...

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

Answer 3

Non sono sicuro se c'è un modo per evitare che le dipendenze vengano costruite. Puoi trovare alcune informazioni qui come impostare copylocal su false e mettere le DLL in una directory comune.

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

Answer 4

Non credo che ci sia via per voi di farlo fuori dalla scatola in VS. È necessario questo componente aggiuntivo http://workspacewhiz.com/

Non è gratuito ma è possibile valutare prima dell'acquisto.

Answer 5

Sì, esclude i bit non modificabili dalla soluzione. Dico questo con un avvertimento, in quanto è possibile compilare in un modo in cui un cambiamento nel numero di build per la lib modificata può causare la rottura dei pezzi non costruiti. Questo non dovrebbe essere il caso, purché non si interrompa l'interfaccia, ma è abbastanza comune perché la maggior parte degli sviluppatori non comprende l'interfaccia nel mondo .NET. Viene dal non dover scrivere IDL. :-)

Per quanto riguarda i progetti X in una soluzione, NO, non è possibile impedirli di costruire, poiché il sistema vede una dipendenza è cambiata.

BTW, dovresti esaminare il tuo progetto e capire perché il tuo progetto di interfaccia utente (supponendo che sia UI) faccia riferimento alla stessa libreria di tutto il resto. Un buon modello di dipendenza mostrerà le classi che dovrebbero essere scomposte come oggetti dati o oggetti di dominio (ho presunto che la dipendenza comune sia una sorta di oggetto dati o oggetto dominio, ovviamente, ma è abbastanza comune). Se la dipendenza comune non è un dominio/oggetto di dati, quindi vorrei ripensare la mia architettura nella maggior parte dei casi. In generale, dovresti essere in grado di creare un percorso dall'interfaccia utente per i dati senza dipendenze comuni diversi dagli oggetti non comportamentali.

Answer 6

Ora, dopo aver detto questo, una testata dell'elica verrà a contraddistinguermi, ma non c'è modo di fare ciò che si vuole fare da Visual Studio. C'è un modo di farlo al di fuori di VS, ma prima, ho una domanda:

Perché mai vuoi farlo? Forse stai cercando di salvare i cicli della CPU, o di risparmiare tempo, ma se fai ciò che stai suggerendo ti troverai all'improvviso in una posizione meravigliosa per spararti ai piedi. Se si dispone di una libreria 1 che dipende dalla libreria 2 e solo le modifiche della libreria 2, si potrebbe pensare di essere in grado di costruire solo la libreria modificata, ma uno di questi giorni si apporterà una modifica alla libreria 2 che si interromperà libreria 1, e senza una build di libreria 2 non la troverai nella compilation. Quindi, a mio modesto parere, NON FARLO.

Il motivo per cui questo non funziona in VS2005 e 2008 è perché VS utilizza MSBuild. MSBuild viene eseguito contro i file di progetto e esaminerà i riferimenti del progetto e creerà prima tutti i progetti di riferimento, se la loro origine è stata modificata, prima di creare il progetto di destinazione. Puoi testarlo da solo eseguendo MSBuild dalla riga di comando con un progetto che non è stato modificato ma con un progetto di riferimento che è stato modificato. Esempio:

msbuild ClassLibrary4.csproj

dove ClassLibrary4 non è cambiato, ma fa riferimento ClassLibrary5, che ha cambiato. MSBuild costruirà prima lib 5, prima che ne crei 4, anche se non hai menzionato 5.

L'unico modo per aggirare tutte queste failfe è utilizzare direttamente il compilatore invece di passare attraverso MSBuild. Brutto, brutto, ma questo è tutto. Fondamentalmente sarai ridotto a reimplementare MSBuild in qualche modo per fare ciò che vuoi fare.

Non ne vale la pena.

Answer 7

Abbiamo effettivamente riscontrato questo problema sul mio progetto corrente, nel nostro scenario anche l'esecuzione di test di unità (senza modifiche al codice) stava causando una ricompilazione. Controlla la "Piattaforma" della tua configurazione di build.

Se si utilizza "Qualsiasi CPU", quindi per qualche motivo ricostruisce tutti i progetti indipendentemente dalle modifiche. Prova a utilizzare build specifici del processore, ad esempio x86 o x64 (utilizza la piattaforma specifica per l'architettura della macchina della tua macchina). Ha lavorato per noi per le versioni x86.

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

Answer 8

abbiamo avuto un problema simile al lavoro. Negli eventi post-build stiamo incorporando manualmente i manifesti nelle uscite nella directory bin. Visual Studio stava copiando i riferimenti del progetto dalla directory obj (che non erano stati modificati). La differenza di timestamp ha innescato ricostruzioni non necessarie.

Se gli eventi di post-produzione modificano gli output di progetto, modificare gli output nel bin e obj dir OPPURE copiare gli output modificati nella directory bin in cima a quelli nella directory obj.

Answer 9

Non sono sicuro di un modo fantastico per gestirlo, ma in passato se avessi avuto un progetto o due che continuavano a essere ricostruiti, e supponendo che non avrei lavorato su di essi, avrei disattivato il processo di compilazione per loro .

Fare clic con il tasto destro del mouse su sln, selezionare Configuration Manager e deselezionare le caselle di controllo. Non perfetto, ma funziona quando Visual Studio non si comporta.

Answer 10

Controlla lo following site per informazioni più dettagliate su quando un progetto è stato creato e le differenze tra la compilazione e la ricostruzione.

Answer 11

ho avuto anche questo problema, e ho notato questi messaggi di avviso quando si costruisce su Windows 7 x64, VS2008 SP1:

cl: Comando avvertimento linea D9038:/ZI non è supportato su questa piattaforma; abilitando/Zi invece

cl: avviso riga di comando D9007: '/ Gm' richiede '/ Zi'; Opzione ignorata

ho cambiato le mie proprietà del progetto a:

C/C++ -> Generale -> Formato informazioni di debug =/Zi

C/C++ -> Code Generation -> Enable al minimo lo spessore = No

Dopo la ricostruzione ho commutato entrambi indietro e dipendenze funzionano ancora bene. Ma prima di ciò nessuna quantità di pulizia, ricostruzione o cancellazione completa della directory di output lo avrebbe risolto.

Answer 12

Ho solo "risolto" lo stesso problema con il mio progetto VS. Visual Studio ha sempre fatto una ricostruzione, anche se non ha cambiato nulla. La mia soluzione: One cs-File aveva un timestamp futuro (Anno 2015, questa è stata colpa mia). Ho aperto il file, l'ho salvato e il mio problema è stato risolto !!!

Answer 13

Se continui a riscontrare questo problema, potrebbe essere dovuto a una dipendenza calcolata mancante o non aggiornata (come un'intestazione) elencata nel progetto, ma non esiste.

Questo mi sembra particolarmente comune dopo la migrazione a una nuova versione (ad esempio: dal 2012 al 2013) perché VS può aver ricalcolato le dipendenze nella conversione oppure si sta eseguendo la migrazione in una nuova posizione.

Un controllo rapido consiste nel fare doppio clic su ogni file nel progetto in errore da Solution Explorer. Se scopri che un file non esiste, questo è il tuo problema.

In mancanza di un file mancante semplice: è possibile avere una relazione di data di compilazione più complessa tra origine e destinazione. È possibile utilizzare un'utilità per scoprire quale test front-end sta attivando la generazione. Per ottenere tali informazioni è possibile abilitare la registrazione dettagliata di CPS. Vedi: Andrew Arnott - Abilita tracciamento del sistema di progetto C++ e Javascript (http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx). Io uso l'opzione DebugView. Strumento inestimabile quando ne hai bisogno.

(questa è una domanda specifica C#, ma un altro posto è stata incorporata come identico)