2013-03-18 8 views
7

Ho una fase di creazione personalizzata in una soluzione di Visual Studio 2013. La fase di compilazione personalizzata chiama uno script python su un file di testo che fa riferimento a diversi altri file nella mia soluzione. Voglio che il passaggio personalizzato venga chiamato ogni volta che uno di questi file cambia o quando manca l'output del mio script. Tuttavia, non desidero mantenere manualmente i campi "dipendenze aggiuntive" e "output" dello strumento personalizzato.C'è un modo per generare automaticamente "Dipendenze aggiuntive" per "Custom Build" in Visual Studio?

Posso facilmente fare in modo che lo script generi un elenco di dipendenze nello stesso modo in cui gcc può generare un file .d quando viene passato in -MM. C'è un modo per utilizzare l'output .d del mio script per popolare automaticamente le "Dipendenze aggiuntive" nel mio passaggio Custom Build? C'è qualche altro modo per evitare il mantenimento delle "dipendenze aggiuntive" e "uscite" campi "?

L'help page mostra solo come aggiungere singoli file.

risposta

10

Supponendo che lo script per la generazione di .d file in grado di generare file in qualsiasi formato che si desidera, si dovrebbe essere in grado di raggiungere i risultati che avete bisogno con l'uso di Import elemento:.

  1. scrivere uno script che produce un file piccolo progetto invece di un file .d l'output dello script sarebbe un piccolo file di progetto contiene i campi "dipendenze aggiuntive" e "uscite".
  2. Utilizzare il tag Import per rendere il file generato una dipendenza del progetto principale
  3. Eseguire lo script quando necessario quando cambia la composizione delle dipendenze.

Questo approccio consente di mantenere il file di progetto principale separatamente dal file di dipendenza generato automaticamente, che potrebbe essere rigenerato secondo necessità. L'unico inconveniente è che il file di dipendenza generato è un file di progetto MSBuild, non un file di dipendenza puro. Tuttavia, questo non dovrebbe essere un problema enorme, perché sei il proprietario dello script che genera il file delle dipendenze.

+0

pensi davvero che uno script che crea un file di progetto secondario, per poi "importarlo" dal progetto principale, sia un approccio più semplice rispetto all'aggiunta programmatica delle dipendenze richieste al file xml del progetto principale ?? – Pat

+5

@Pat Perché, non penso *, * so * per un fatto che questo approccio è molto più pulito e molto più stabile nel lungo periodo. – dasblinkenlight

+0

con tutto il rispetto la tua risposta non è buona; si invita a creare a livello di programmazione un nuovo progetto per importare il progetto, per importare con esso le dipendenze; la mia risposta aggiunge direttamente le dipendenze al file di progetto principale; Penso che la tua risposta non sia in concorrenza con la mia; hai appena preso una parte della mia e l'hai resa più complicata e complicata. – Pat

Problemi correlati