2009-07-30 8 views
10

Sto costruendo una libreria di classi DLL - Voglio renderla utilizzabile da quante più persone possibile. Quale versione di .NET Framework e quale versione di C# dovrei usare? È possibile produrre una DLL compatibile con le versioni precedenti o DLL diverse per versioni diverse? Oppure Windows aggiorna automaticamente il framework .NET, quindi dovrei semplicemente usare l'ultima versione? Qualsiasi consiglio apprezzato!Quali versioni di .NET Framework e C# devo indirizzare con la mia libreria di classi?

risposta

10

Ci rivolgiamo a più versioni di runtime contemporaneamente (.NET 1.1, .NET 2.0 e .NET 3.5) per alcuni prodotti.

gestiamo in diversi modi:

  • file di soluzione e progetto separato e per ciascuno di .NET 1.1, 2.0 e 3.5 SP1, ma fa riferimento gli stessi file di origine.

esempio:

 
\ProductFoo_1_1.sln (.NET 1.1 solution, VS 2003) 
\ProductFoo_2_0.sln (.NET 2.0 solution, VS 2008) 
\ProductFoo_3_5.sln (.NET 3.5 solution, VS 2008) 

\FooLibrary\FooLibrary_1_1.csproj (.NET 1.1 Project, VS 2003) 
\FooLibrary\FooLibrary_2_0.csproj (.NET 2.0 Project, VS 2008) 
\FooLibrary\FooLibrary_3_5.csproj (.NET 3.5 Project, VS 2008) 

\FooLibrary\FooClass.cs (shared amongst all Projects) 
\FooLibrary\FooHelpers_1_1.cs (only referenced by the .NET 1.1 project) 

\FooService\FooService_3.5.csproj (.NET 3.5 Project, VS 2008) 
\FooService\FooService.cs 
  • Definizione NET_X_X simboli in ciascuna delle soluzioni

  • Per codice specifico .NET Framework, usiamo le istruzioni del preprocessore come questa:

 
public void SomeMethod(int param) 
{ 
#ifdef NET_1_1 
// Need to use Helper to Get Foo under .NET 1.1 
    Foo foo = Helper.GetFooByParam(param); 
#elseif NET_2_0 || NET_3_5 
// .NET 2.0 and above can use preferred method. 
    var foo = new Foo { Prop = param }; 
    foo.LoadByParam(); 
#endif 
    foo.Bar(); 
} 

#ifdef NET_3_5 
// A method that is only available under .NET 3.5 
public int[] GetWithFilter(Func Filter) 
{ 
    // some code here 
} 
#endif 

Per chiarimenti, le righe precedenti che iniziano con # sono comandi del preprocessore. Quando si compila una soluzione, C# Compiler (csc) pre-elabora i file sorgente. Se si dispone di un'istruzione #ifdef, quindi csc valuterà per determinare se tale simbolo è definito e, in tal caso, includere le righe all'interno di tale segmento durante la compilazione del progetto.

E 'un modo per marcare il codice per compilare in certe condizioni - usiamo anche per includere ulteriori informazioni di debug intensiva specifica debug dettagliato costruisce, in questo modo:

 
#if DEBUG_VERBOSE 
    Logging.Log("Web service Called with parameters: param = " + param); 
    Logging.Log("Web service Response: " + response); 
    Logging.Log("Current Cache Size (bytes): " + cache.TotalBytes); 
    // etc. 
#endif 
  • Abbiamo poi script NAnt che automatizza la produzione di una versione per ogni versione .NET. Ci capita di controllare tutto questo attraverso TeamCity, ma possiamo anche attivare manualmente gli script NAnt.

Fa rendere le cose più complicate, quindi abbiamo solo tendono a farlo in cui abbiamo bisogno di mantenere un lascito .NET 1.1 o 2.0 esempio (ad esempio quando un cliente non può/non sarà l'aggiornamento).

Immagino che quando .NET 4.0 andrà in giro, faremo la stessa cosa e aggiungeremo solo un simbolo NET_4_0.

9

Lo terrei a 2.0 a meno che non sia necessario utilizzare le funzioni 3.0 o 3.5.

+2

Mentre capisco da dove vieni, questo approccio sembra lento/stop l'adozione di versioni più recenti di .net. – Tony

+5

@ Tony - Non penso. Le persone dovrebbero adottare cose nuove perché sono utili, non perché sono nuove. –

11

Personalmente, sceglierei .NET 2.0. Questo significa, tra le altre cose:

  • No Metodi di estensione (c'è una soluzione però)
  • No LINQ

  • è possibile utilizzare Espressioni lambda

  • è possibile utilizzare il 'var' parola chiave

Il fatto è che è possibile utilizzare le caratteristiche del linguaggio C# 3.x (il cosiddetto zucchero sintattico), ma non è possibile utilizzare librerie che arget C# 3.x (System.Core per nominarne uno, include i metodi di estensione e linq).

Non vorrei provare a supportare C# 1.x, in quanto è molto diverso da C# 2.xe successive. Inoltre, mi aspetto che la maggior parte delle persone che usano la tua biblioteca siano persone che costruiscono cose nuove, chi non dovrebbe usare C# 1.x ;-)

2

Se dovessi iniziare un nuovo progetto, userei sempre il più nuovo runtime! Se 3.5 è disponibile, perché dovrei iniziare un progetto in 2.0 o 1.0 a meno che non sapessi che c'è qualcosa di veramente sbagliato nella nuova versione? Le nuove versioni significano correggere bug vecchi e aggiungere nuove funzionalità, quindi questo è buono.

Quando si tratta di aggiornare il vecchio progetto a una nuova versione, è necessario considerare i propri guadagni e perdite. Se ne vale la pena, aggiornalo, se non si attacca alla vecchia versione.

Stai attento perché i nuovi strumenti potrebbero non supportare versioni precedenti. Anche se questo non è il caso con il 2010 in quanto supporterà tutte le versioni fino a 2.0.

4

provare questo: modalità

interruttore rivolte al framework 2.0 (rimozione di riferimento System.Core).

se si compila, di provare ad aggiungere un riferimento a linqbridge.dll:

Se no, allora si dovrebbe indirizzare 3.5;)

+0

ma se aggiunge un riferimento a una dll di terze parti, allora avrebbe bisogno anche del rilascio. A quel punto dovrebbe usare solo .net3.0 o superiore. – Tony

+0

linqbridge è molto piccolo, è adeguato. Ho iniziato con .net 2.0 e ho continuato a mirare che su VS 2008 mentre godevo di C# 3 caratteristiche –

+0

@Tony: suppongo che dipenda da ciò che ti serve;) – kentaromiura

0

Io voto per la risposta di Erik van Brakel. Inoltre vorrei suggerire che se si desidera supportare 3,5 caratteristiche come metodi di LINQ ed estensione, è possibile creare una libreria aggiuntiva, dire

MyLibrary.DLL

MyLibrary.LINQ.dll

così utilizzando lo stesso approccio di MS (quando hanno lasciato la versione 2.0 di System.dll ma aggiunto tutte le nuove funzionalità in System.Core.dll)

0

Preferirei la versione 2.0 con la libreria contenente le funzioni principali e aggiungere una libreria aggiuntiva con il targeting 3.5 per aggiungere alcuni metodi di estensione basati sulla libreria principale.

+0

c'è sempre la possibilità che 2 persone scrivano la stessa risposta :) –

0

Dal mio punto di vista, se si desidera una vasta gamma di utenti, si dovrebbe fare con le prime versioni, 1.1 sarà bello, perché funziona su qualsiasi macchina ha .Net che cosa mai la sua versione.

+0

Personalmente questa non è una buona idea. Soprattutto perché ci sono molte interruzioni tra .net1.X e .net2.0 – Tony

0

Dipende da cosa è la dll. Se ha solo una logica C# generica che vorresti rendere disponibile agli altri, allora .net 2.0 è probabilmente la soluzione migliore. Tuttavia, se ha qualcosa a che fare con le nuove funzionalità di .net come WPF, EF, WCF, silverlight, ecc, allora dovrà essere nella versione di .net che supporta quella particolare caratteristica.

Personalmente, direi di scriverlo in .net 3.5 solo perché fare il salto da .net2.0 a .net3.5 è piuttosto semplice perché non ci sono molte interruzioni, a differenza del salto da .net1.x a. net2.0. :)

0

Non credo che nessuno usi .Net 1.1 più. Quindi, a meno che non si voglia veramente utilizzare 3.5 funzionalità 2.0, dovrebbe andare bene. Inoltre, se hai il controllo su chi utilizzerà effettivamente la tua libreria, dipende anche da loro. Se hanno il quadro più recente, puoi usarlo.

+0

Purtroppo ti sbagli. Ci sono ancora persone bloccate a 1.1, a volte perché hanno ancora bisogno di supportare i vecchi sistemi operativi. –

+0

Oh bene. 1.1 è anche divertente. –

0

Combinato con l'utilizzo di un approccio come quello menzionato da Will Hughes, se si desidera l'accesso/opzione per utilizzare le nuove funzionalità quando disponibili, durante lo sviluppo attivo, utilizzare il quadro più recente. Quando sei pronto per iniziare a rilasciare i candidati al rilascio, imposta il framework più basso e poi quando arrivano i problemi, aumenta costantemente la versione del framework e/o usa l'approccio #ifdef per risolvere il problema.

0

Questa soluzione funziona abbastanza bene. Ho appena creato due progetti diversi ciascuno con un unico "Proprietà progetto-> Costruisci-> Simboli di compilazione condizionale" e utilizzato nel codice come questo:

#if NET_4 
      xmlReaderSettings.DtdProcessing = DtdProcessing.Ignore; 
#endif 
#if NET_3_5 
      xmlReaderSettings.ProhibitDtd = false;     
#endif 
Problemi correlati