[.Net] Cade il mito della soluzione al problema Dll Hell

[tomminno]

Sicuramente chi usa Visual Studio 2010 si sarà accorto che il framework 4 introduce una nuova Gac.
Insomma negli scorsi anni sono stati sprecati tanti paroloni per dire che il problema Dll Hell è stato brillantemente risolto dalla Gac e poi introducendo un nuovo runtime, si ritrovano esattamente con lo stesso problema...

Insomma d'ora in avanti ad ogni nuovo runtime Gac differenti?

[Kralizek]

Originariamente inviato da tomminno

Sicuramente chi usa Visual Studio 2010 si sarà accorto che il framework 4 introduce una nuova Gac.
Insomma negli scorsi anni sono stati sprecati tanti paroloni per dire che il problema Dll Hell è stato brillantemente risolto dalla Gac e poi introducendo un nuovo runtime, si ritrovano esattamente con lo stesso problema...

Insomma d'ora in avanti ad ogni nuovo runtime Gac differenti?

nuova gac é un parolone, diciamo che hanno aggiornato tutti gli assembly ed aggiunti alcuni di nuovi.

ma un assembly é sempre stato caratterizzato dal nome e dalla versione (ed eventualmente dalla firma dell'autore).

Il fatto che ci sia un {System.Web.dll, 2.0.xxxx} ed un {System.Web.dll, 4.0.xxx} non é mica un ritorno al dll hell.

[tomminno]

Originariamente inviato da Kralizek

nuova gac é un parolone, diciamo che hanno aggiornato tutti gli assembly ed aggiunti alcuni di nuovi.

ma un assembly é sempre stato caratterizzato dal nome e dalla versione (ed eventualmente dalla firma dell'autore).

Il fatto che ci sia un {System.Web.dll, 2.0.xxxx} ed un {System.Web.dll, 4.0.xxx} non é mica un ritorno al dll hell.

Non so se ti sei accorto che il .NET 4 ha la GAC separata da quella del 2 e posizionata in C:\Windows\Microsoft.NET\assembly
C'è Dll Hell tra gli assembly con runtime 2 e runtime 4!
C'è da supporre che il problema si ripresenterà con le prossime versioni.

[Kralizek]

ah scusa, my fault. cmq non sono sicuro sia un problema di ogni versione del runtime, perché il nuovo percorso non indica una dipendenza dalla versione.

magari hanno solo deciso di mettere il tutto sotto Microsoft.NET/ per questione di pulizia.

in ogni caso credo che gacutil dovrebbe vedersela da solo =)

[nico159]

http://msdn.microsoft.com/en-us/magazine/ee819091.aspx
Spero di aver capito bene la domanda, sono nuovo di .Net
Personalmente sono molto contento di averlo scelto come "ambiente di sviluppo"

[tomminno]

Originariamente inviato da nico159

http://msdn.microsoft.com/en-us/magazine/ee819091.aspx
Spero di aver capito bene la domanda, sono nuovo di .Net
Personalmente sono molto contento di averlo scelto come "ambiente di sviluppo"

Più che una domanda era una constatazione.
La Gac in sè non dovrebbe (o meglio non doveva) essere un ostacolo al variare del runtime, dopotutto c'è stato il passaggio 1.0->1.1->2.0 senza alcun problema. Anche perchè la struttura delle sotto cartelle della Gac è la medesima.

Il problema come spiegato nel link che hai riportato è appunto il solito vecchio problema di inferno delle Dll, esattamente quello che la Gac (e .Net) doveva risolvere una volta per tutte.
E' evidente che non esiste il classico proiettile d'argento per risolvere il problema.

[gugoXX]

Originariamente inviato da tomminno

Non so se ti sei accorto che il .NET 4 ha la GAC separata da quella del 2 e posizionata in C:\Windows\Microsoft.NET\assembly
C'è Dll Hell tra gli assembly con runtime 2 e runtime 4!
C'è da supporre che il problema si ripresenterà con le prossime versioni.

Sono solo percorsi diversi, ma la GAC resta una.

[tomminno]

Originariamente inviato da gugoXX

Sono solo percorsi diversi, ma la GAC resta una.

No no sono proprio 2 Gac differenti.