Esistono buoni motivi per modificare il percorso di output di generazione del progetto dal suo default, "bin \ debug"? C'è qualche vantaggio nel puntare tutti i tuoi progetti all'interno di una soluzione in un comune luogo di produzione?Modifica visiva percorso di uscita generazione predefinito di Studio
Sì, di solito lo faccio per tutto il tempo. Come ha detto Harry, riduce l'utilizzo dello spazio su disco. Questo non è un grosso problema per me, dal momento che lo spazio su disco è incredibilmente economico, ma potrebbe essere una preoccupazione per te. La vera ragione per cui lo faccio per rispecchiare al meglio come sarà la distribuzione. Il modo migliore per farlo è avere un property sheet che modifichi la directory di output su $(SolutionDir)/build/bin. Dopo questo, ho impostato la directory di lavoro su $(SolutionDir)/build, che è l'intera struttura che è identica a quella che sarebbe stata distribuita, piuttosto che averla diffusa tra le varie directory di progetto.
build
|-- bin
| |-- foo.exe
| |-- libfoo.dll
| `-- libbar.dll
|-- plugins
| |-- extender.py
| `-- something.lua
`-- skins
|-- default.skin
`-- white-and-gold.skin
Nel complesso, avere una directory isolata per le cose che sono costruite (piuttosto che le fonti) è una buona cosa. Semplifica la scrittura di passi personalizzati, dal momento che sai dove sarà l'output finale e facilita l'integrazione con il tuo sistema di controllo della versione, poiché puoi semplicemente impostarlo per ignorare l'intera directory, piuttosto che andare in giro impostando ignore per tutti .exe, .lib, .so , .dll e quant'altro per ogni piccola directory.
La ragione principale per cambiare la mia directory di output è quello di ridurre il numero di gruppi di duplicati e il numero di copie dei file Visual Studio deve fare. Se il progetto A fa riferimento al progetto B, e il progetto C fa riferimento ai progetti A e B, Studio deve creare A, copiare A a B e creare B, quindi copiare A e B in C e creare C. Ora hai 3 copie dell'assieme A, due copie dell'assieme B e una di C. Indicando l'output in una singola directory, Visual Studio crea semplicemente A, poi B, quindi C. Una copia di ciascuna. È possibile immaginare quanto più spazio e tempo del disco vengono consumati per una build man mano che aumenta il numero di progetti e la complessità delle dipendenze.
A titolo di esempio ho un updater.exe che dovrebbe essere distribuito con un programma di "altro". Così ho impostato il percorso di costruzione per il percorso di creazione di altri programmi. In questo modo so che ho sempre l'ultimo "updater.exe" dove dovrebbe essere.
Questo è solo un motivo.
Proprio come una nota, il mio vero punto era più il tempo di Visual Studio sta prendendo per copiare gli stessi file in giro con dipendenze complesse - la quantità di spazio su disco era una sorta di accessorio. Ma immagino che il modo in cui ho formulato la mia risposta abbia dato a ciascuno un uguale peso. –