Se si dispone di un assembly CLR 2.0 (puro codice gestito, nessun problema in modalità mista) a cui devo collegarsi da un'applicazione CLR 4.0, il codice 2.0 viene eseguito su CLR 2.0 o 4.0.Quando si collega un assembly gestito .NET 2.0 da un'applicazione .NET 4.0, quale framework viene utilizzato?
Fondamentalmente, c'è il rischio di 4.0 modifiche di rottura che interessano il codice 2.0?
La risposta di cui sopra non è corretto. Si ottiene fianco a fianco con i quadri completi. A. NET 2 APPLICATION (nota che significa EXE, non libreria) non promuoverà automaticamente su .Net 4.
Ma se un'applicazione .Net 4 carica un assembly .Net 2 viene caricato nello stesso runtime (altrimenti come potrebbero condividere informazioni). L'assembly .Net 2 viene caricato nel runtime .net 4 utilizzando una modalità di compatibilità che dovrebbe minimizzare la rottura delle modifiche (principalmente per i cambiamenti di sicurezza in .Net 4).
Un assieme .Net 2 non può fare riferimento a un assieme .Net 4 perché non avrebbe caratteristiche.
L'unica eccezione a ciò che so è se si carica un assembly .Net da un'app C++. L'applicazione C++ può caricare e ospitare due runtime. Potrebbe avere un assembly .Net 2 e un assembly .Net 4 caricato, ma non sarebbero in grado di parlare tra loro direttamente. Questo è il modo in cui i Proc sulle CLR funzionano in SQL Server. È possibile avere un .Net 2 CLR Proc e un .Net 4 CLR Proc che non comunicano, ma sono entrambi caricati sul server.
C'è stato un grande articolo su MSDN Magazine sull'hosting del framework .Net recentemente, ma non riesco a trovarlo ora. Forse qualcun altro può pubblicare il link.
Quindi dovresti essere in grado di caricare praticamente qualsiasi .Net 2 in un .Net 4 eseguibile senza molti problemi. Gli unici problemi che ho visto sono con i permessi di sicurezza.
Fondamentalmente, c'è il rischio di 4.0 modifiche di rottura che interessano il codice 2.0?
No. A partire da .NET 4, non ti devi preoccupare dei problemi di compatibilità ! La versione 4 ha introdotto una nuova funzionalità denominata "In-Process Side-by-Side Execution", che essenzialmente consente di caricare più versioni del CLR nello stesso processo.
In altre parole, poiché l'applicazione principale è in esecuzione sul runtime 4.0, è possibile indicare che carica il runtime 2.0 quando si carica l'assieme CLR 2.0. L'assembly CLR 2.0 utilizzerà il runtime 2.0, mentre l'applicazione continuerà a utilizzare il runtime 4.0.
Come si specifica? Credo che tu possa semplicemente aggiungere un file di configurazione per il tuo assembly CLR 2.0 (ad esempio "My.dll.config" nella stessa directory di "My.dll"), ma non l'ho provato con le DLL io stesso. Tuttavia, ecco ciò che si mette nel file di configurazione del vostro montaggio:
<?xml version="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v2.0.50727" />
</startup>
</configuration>
Questo è corretto, secondo i documenti. Tuttavia, sembra che a volte il compilatore C# aggiunga e alias gli assembly v2.0 che quindi causano problemi di caricamento. Puoi spiegare questo? Ecco un esempio: http: // StackOverflow.it/questions/3841911/linking-to-a-net-v2-0-assembly-from-a-net-v4-0-assembly-also-appear-to-link-a – codekaizen
Grazie per la risposta, ma ho dato questo va creando un progetto di test rapido. Ho un'applicazione per console in esecuzione 4.0 e una libreria di classi che esegue 3.5. Ho creato un file di configurazione come specificato e Environment.Version è 4.0 per entrambi. – AlexWilson
Il file di configurazione non funzionerà per una DLL. Deve essere aggiunto al file di configurazione .EXE, poiché è ciò che viene caricato dal runtime. – codekaizen
se la risposta da htw non ha risposto per voi, o si blocca su di voi. Date un'occhiata a questo
Man, l'ho già fatto e ho completamente dimenticato questa app.config
Non so se stai parlando dell'articolo "API CLR Hosting": msdn.microsoft.com/en-us/magazine/cc163567.aspx – user276648