E' un po' che voglio scrivere questo post, perché il dubbio mi era venuto e avevo approfondito il discorso, perciò volevo rendervi partecipi.

Ai Community Days 2 qualcuno aveva chiesto se si poteva sfruttare il CLR di Silverlight anche fuori dal browser. In teoria la risposta è sì, perché il CLR è una versione 2.1, basata sulla 2.0 appunto, ma limitata togliendo classi considerate superflue per browser client o eliminando overloads a metodi che occupano istruzioni IL solo per favorire il programmatore. Alcune classi invece sono rimaste. Per esempio mscorlib ha System.Console, la reflection, la parte di serializzazione, collezioni ecc.

A confermare la mia ipotesi è questo tizio che prendendo in esempio un'applicazione di Rotor ha creato una Console application runner di nome agx.exe.

Per quanto riguarda invece avere un exe a se stante, come si può avere in Flash, Silverlight è un ActiveX di nome AgControl Type Library in npctrl.dll che può essere usato in applicazioni standalone. A parte che non vedo il motivo di usare Silverlight (a questo punto meglio usare il .NET Framework normale), nasce comunque un problema serio.

Per ogni processo è possibile avere funzionante un'unica versione del Framework, perciò in scenari di addin e plugin succede che se una dll sviluppata per la versione 1.x viene caricata in un processo con attivo il CLR 2.0, questa viene forzatamente eseguita con la 2.0. In questo caso non dovrebbero esserci problemi; ce ne sono nel caso avvenga il contrario, con un "downgrade" di un componente dalla versione 2.0 alla 1.x. Questo è un problema non di poco conto e che fino adesso forse ha frenato lo sviluppo di estensioni per applicativi come la shell o Internet Explorer.
Con Silverlight inoltre, questa complicazione si fa ancora più probabile: poniamo di aprire in IE una pagina con Silverlight 1.0, poi un'altra con Silverlight 1.1, poi in un futuro un'altra con un ipotetico Silverlight 2.0. Quale versione del CLR parte? La risposta sarebbe la versione del primo "applicativo" che è stato carico.

Fortunamente questo problema è stato risolto e a partire da Silverlight, quindi anche con i futuri CLR, due runtime possono convivere nel medesimo processo. Silverlight in particolare può coesistere con gli attuali CLR 1.0, 1.1 e 2.0. Ogni CLR lavora per conto suo, ha un suo GC e non condivide la memoria. In questo post viene spiegata la soluzione tramite un video.