Come si fa ha sviluppatori su bersaglio VS2008 NET 2.0 (ma non il Service Pack) per evitare collisioni di esecuzione?

Question

Quindi, voglio aggiornare il mio team di sviluppo per VS2008. Come impresa, non abbiamo ancora implementato il runtime 3.5.

Da qualche lettura, sembra che l'installazione di VS2008 verrà automaticamente darà NET 2.0 SP1, che ha alcune nuove API, e quando si target 2.0 runtime assumerà 2.0 SP1.

Ma se SP1 non è implementato per i nostri utenti, questo porterà a pause di esecuzione.

1. Esiste un modo per avere VS bersaglio dotnet 2.0 (NON SP1)?
2. C'è qualche altre soluzioni a questo problema così gli sviluppatori non utilizzano API che compilare ed eseguire bene a livello locale, ma saltare in aria in produzione?

vedo che FxCop ha un controllo per questo, ma ci deve essere una soluzione più infallibile a questo problema.

Answer 1

Questo può essere difficile o facile. Siamo andati entrambe le vie:

1. Il modo più semplice: Stabilire un build server che ha solo .Net 2.0 installato. Automatizzare la build per eseguire al momento del check-in (usiamo CruiseControl.Net). Si dovrà utilizzare MSBuild dal prompt dei comandi per la costruzione dei progetti.

2. Per le macchine con 3.5 installato molti degli strumenti MSBuild sono sostituiti anche quando si esegue il MSBuild dalla directory NET Framework 2.0. Per evitare questo è necessario creare un'applicazione che impone l'utilizzo continuato di solo il runtime .NET 2.0. Questo non è facile. Carichiamo direttamente i progetti e invochiamo la build utilizzando il Microsoft.Build. * Quadro. Questo da solo non è ancora sufficiente. È necessario appuntare le assemblee che si desidera utilizzare nel file .config:

                                                                                 ... ect ...        

A proposito, si può anche avere problema con i progetti di nuova creazione in VS2008 che prevedono una proprietà chiamata "MSBuildToolsPath" che deve essere definita. È possibile definire questo sulla riga di comando se si utilizza MSBuild, o specificarla programatically se si utilizza la seconda opzione:

engine.GlobalProperties.SetProperty( "MSBuildToolsPath", msbuildPath );

Answer 2

Forse il supportedRuntime elemento di configurazione vale la pena di dare un'occhiata a. Ma io non sono sicuro se questo può aiutare.