2012-02-17 14 views
7

Sto cercando di capire se è possibile, quando si utilizza uno strumento personalizzato in Visual Studio, per modificare il contenuto di un file, attivare lo strumento personalizzato di un altro.In Visual Studio, posso fare in modo che un file esegua lo strumento personalizzato di un altro? (in questo caso utilizzando Xsd2Code)

mio scenario è questo:

In un # progetto di Visual Studio C, ho uno schema XML "master.xsd", che comprende molti altri altri file XSD. Sto usando lo strumento personalizzato Visual Studio Xsd2Code per generare un file .cs dallo schema. Funziona bene quando lo stesso master.xsd cambia, ma vorrei che lo strumento personalizzato si avvii sul file master.xsd quando cambia uno degli altri xsds.

C'è un modo per un file che attiva lo strumento personalizzato di un altro?

[EDIT - maggiori dettagli sul motivo per cui sto cercando in utilizzando uno strumento personalizzato per questo]

Attualmente abbiamo un file GenerateFiles.bat che chiama Xsd2Code dalla riga di comando per generare i codici fiels dagli schemi (come suggerito da MattDavey in basso). Funziona, è troppo lento.

Il problema è che su ogni build Xsd2Code verrà eseguito, ma poiché molti altri progetti dipendono da questo progetto con gli schemi, verranno ricompilati anche se probabilmente nulla è cambiato. Il risultato pratico è che anche una piccola modifica al test di un'unità implica la metà della ricompilazione dei progetti. Questo è il motivo per cui abbiamo esaminato l'approccio dello strumento personalizzato per generare solo i file di codice se lo schema cambia.

risposta

4

Io uso Xsd2Code molto in questo modo, ma il mio approccio è quello di aggiungere un evento di pre-compilazione che richiama la linea di comando Xsd2Code e rigenera il xml in ogni generazione ..

mio evento pre-generazione si presenta come questo:

$(ProjectDir)BuildTools\Xsd2Code.exe $(ProjectDir)Api\Schemas\MySchema.xsd MyProject.Api.Schemas $(ProjectDir)Api\Schemas\MySchema.cs /platform Net40 /collection Array /sc+ /ap+ /if- /xa+ 

Nel tuo caso è possibile eseguire questa fase di pre-build solo sul master XSD (che sto cercando di indovinare xsd: importa le altri schemi), oppure è possibile eseguire il comando su ciascuno di schema file individualmente.

Il vantaggio di questo è che, se cambio lo schema XSD, ricevo errori di compilazione molto utile :)

speranza che ti dà qualche idea!

EDIT

ho trascorso qualche tempo a pensare al problema che hai evidenziato quanto riguarda tempi di costruzione e modificato lo script di pre-build in questo modo:

$(ProjectDir)BuildTools\Xsd2Code.exe $(ProjectDir)Api\Schemas\MySchema.xsd MyProject.Api.Schemas $(ProjectDir)Api\Schemas\MySchema.cs.temp /platform Net40 /collection Array /sc+ /ap+ /if- /xa+ 

fc $(ProjectDir)Api\Schemas\MySchema.cs $(ProjectDir)Api\Schemas\MySchema.cs.temp 

if errorlevel 1 copy $(ProjectDir)Api\Schemas\MySchema.cs.temp $(ProjectDir)Api\Schemas\MySchema.cs /Y 

del $(ProjectDir)Api\Schemas\MySchema.cs.temp 

Così Xsd2Code è ora la generazione del codice sorgente in un file temporaneo, che sovrascrive solo il file .cs esistente se è diverso. Questo dovrebbe significare che se il .xsd non è cambiato per niente, neppure le cs generati :)

Stai ancora prendendo il colpo di correre xsd2code, ma non stai prendendo il colpo di msbuild ricostruire un'intera catena di progetti se la sorgente generata era la stessa ..

+0

Grazie per il suggerimento. Sfortunatamente, questo è il modo in cui lo facciamo al momento, ed è troppo lento.Il problema è che su ogni build Xsd2Code verrà eseguito, ma poiché molti altri progetti dipendono da questo progetto con gli schemi, verranno ricompilati tutti anche se probabilmente nulla è cambiato. Questo è il motivo per cui ho cercato l'approccio dello strumento personalizzato per generare solo i file di codice se lo schema cambia. In altri scenari però, penso che l'approccio che descrivi sia buono. –

+0

ooh difficile. La prima cosa che viene in mente è saltare il passo xsd2code quando il file xsd è invariato. Ciò potrebbe comportare uno script batch pre-build leggermente più complesso, che probabilmente genera un hash del file xsd e lo confronta con un hash precedentemente memorizzato. Ma sto solo speculando ora :) – MattDavey

+0

@RobLevine vedi edit – MattDavey