Sempre per il fatto di lavorare con Oracle mi sono scontrato con il fatto che il file .cs che viene generato automaticamente da Visual Studio non gestisce correttamente il caso in cui il dato sottostante sia un Guid su SQL Server (in cui il Guid è invece un tipo nativo) mentre su Oracle i campi Guid sono stati definiti come Char(36). Poi possiamo anche discutere di questa conversione (vi dico subito che sono ovviamente tutti campi chiave e quindi sotto ci sono delle motivazioni collegate alle performance), ma il problema è che il Dataset tipizzato mi espone dei Guid, dato che da Oracle mi arrivano delle stringhe vengono generate delle cast exception se non intervengo nel file .cs generato da Visual Studio (o da xsd.exe, che è la stessa cosa).
La modifica per far andare il .cs del dataset è roba da poco (mettere una if nelle property che tornano un Guid), però implica che si cambia del codice generato in automatico, cosa che non è mai bella.
E per la prima parte della ricetta viene comodo lo snippet di codice che vi passo (e che non è che si trovi in giro tanto documentato):
DataSet ds = new DataSet();
ds.ReadXmlSchema(...qui ci dovete mettere il nome del file .xsd relativo allo schema del Dataset...);
CodeNamespace cn = new CodeNamespace(...qui ci dovete mettere il namespace della classe che volete generare...);
CSharpCodeProvider cs = new CSharpCodeProvider();
ICodeGenerator cg = cs.CreateGenerator();
TypedDataSetGenerator.Generate(ds, cn, cg);
A questo punto nel vostro CodeDom avete esattamente la stessa classe che vi verrebbe generata dal tool xsd.exe (cosa che potete verificare chiamando la cg.GenerateCodeFromNamespace) e potete navigare tutto il vostro albero per cambiare/rimpiazzare/sistemare il codice del vostro Dataset tipizzato con quello che serve a voi. Qui poi vi scontrerete con il CodeDom, ma è un altro film...
Il secondo pezzo della ricetta consiste poi nell'automatizzare questo processo quando premete Control-Shift-Build in modo che se modifico il mio schema del dataset non debba ricordarmi tutte le volte di rigenerarlo (altrimenti diventa uguale al cambiare il .cs generato). Navigando in giro si trova un bell'articolo di Cazzulino che vi dice come usare l'extensibility di Visual Studio per fare in modo di fare il tutto in automatico, ma finisce che dovete scrivere tantissimo codice.
Io ho usato un modo molto ma molto più semplice:
1) Prendete tutti gli xsd dei Dataset, li mettete in una cartella comune (che fa sempre bene) e nelle proprietà ci togliete l'associazione MSDataSetGenerator come Custom Tool: 10 minuti di tempo con mastercard
2) Prendere il vostro codice e lo trasformate in un NewXsd.Exe che prende come parametri il nome del file xsd, il nome della classe da generare ed il nome del namespace: 1 ora di tempo con mastercard
3) Andate nelle proprietà del progetto ci aggiungete uno script di PreBuild che fa una cosa del genere
for %%a in (percorso dove stanno gli xsd\*.xsd) do percorso\NewXsd.exe %%a %%a.cs NomeDelNamespace
Altri 10 minuti con mastercard, di cui la metà spesi per capire come gestire i percorsi dato che prebuild e postbuild hanno convenzioni leggermente diverse
4) Avere tanti bei file con estensione .xsd.cs che inclusi nel progetto si compileranno belli come il sole e sapere che tutte le vostre build avranno dei dataset corretti e non vedrete più cast exception: non ha prezzo
Se nel vostro piccolo Exe mettere una semplice compare sulle date dei file il processo è praticamente inavvertibile come tempi.
Mai sottovalutare la potenza della vecchia command line!!!
posted @ lunedì 19 settembre 2005 22:29