Si parla tanto, tantissimo di dotNET e di come sia una
gran bella tecnologia. Bene, penso sia arrivato il momento di guardarla
anche da altri punti di vista. Il mio è quello di uno che, di
base, è abbastanza informato anche se non si è ancora addentrato in tutti i
meandri di dotNET. Spero non ci siano informazioni sbagliate, quindi dico quello
che so sperando che sia giusto 
.
Cominciamo dal fatto che dotNET esiste anche per altre piattaforme, più
precisamente Mono, che è standard e tutte 'ste robe qui.
Non so se qualcuno ci ha fatto caso, ma MS cerca a tutti i costi di uscire
con dotNET2 mentre i ragazzi di Mono stanno ancora cercando di arrivare a finire
la corrispondenza alla 1.1 di dotNET. Questo la dice lunga su quanto sia
"completo" il port e quanto MS sia disponibile a che dotNET sia
multipiattaforma. Qualcuno potrebbe quindi chiedersi il perché della decisione
di Microsoft di standardizzare C# ed il CLR.
La mia opinione è che sia stata
una mossa geniale, oltre che un grandioso specchietto per le allodole: una
standardizzazione non significa necessariamente dover seguire lo standard e
Microsoft ha dimostrato più volte di essere allergica agli standard, perfino i
suoi medesimi(vedi pasticcio con le typelibraries di Office, tanto per citare
l'esempio più conosciuto, oppure perfino le incompatibilità di dotNET 1.1 SP1).
Inoltre, Visual Studio ha la fetta più grossa di mercato su dotNET, questo è
indubbio, quindi la stragrande maggioranza di coloro che vorranno usare dotNET
lo faranno con VS.
Perché il designer WinForms è stato incluso nel framework?
Semplice, perché non è su quello che si basano i proventi di Visual Studio, ma
sulla vendita del prodotto in se e sui servizi accessori. Ancora una volta, un
modo per Microsoft di attrarre persone e dare una parvenza di non
monopolio(rendendo ad esempio possibile la realizzazione di SharpDevelop). Dunque,
qui mi pare adesso sia chiaro, no?
Passiamo ad un altro punto fondamentale: Microsoft dice che dotNET risolverà
il problema dell'inferno delle DLL(altrimenti noto come DLL Hell). In cosa
consiste questo ecc. Il risultato era un malfunzionamento generalizzato delle
applicazioni coinvolte.problema? Nel fatto che un certo(alto, molto alto) numero
di sviluppatori non ha fatto "le cose perbene"(cit) e quindi alcune DLL andavano
a sovrascriverne altre, senza alcuna accortezza per i numeri di versione,
generando malfunzionamenti di ogni sorta e specie.
Dunque, lo strumento
"principe" per la risoluzione di questo problema in dotNET è l'uso dello strong
naming. Come funziona? Semplicemente, si "firma" un assembly con un certificato
che attesta che l'assembly ha la versione X.Y e che quindi tutte le applicazioni
che fanno riferimento a quella versione di quell'assembly sanno
che è lui. Parte fondamentale di questo processo è la Global Assembly Cache, GAC
per gli amici, che appunto conserva gli assembly più utilizzati. Cosa succede,
però? Nonostante sia possibile registrare degli assembly nella
GAC, Microsoft sconsiglia questa pratica a quanto ho capito.
Ergo,
strong naming ti saluto. Inoltre, so che non ce n'è bisogno ma lo dico lo
stesso, è normale che se non vengono rispettate le regole di base di "civile
convivenza" tra gli assembly e compagnia, qualcosa di molto, molto, molto brutto
dovrà succedere prima o poi, vi pare?
Adesso invece, occupiamoci della "portabilità": qui il discorso deve prendere
una ramificazione dicotomica. Il problema è che bisogna distinugere tra
lato server e lato client. Non solo, ma anche tra diverse versioni del
Framework, perché ormai ci avviamo alla 2.0 ed il numero sta crescendo in modo
preoccupante. Il perché di questa mia preoccupazione lo vediamo dopo.
Occupiamoci intanto del fattore portabilità sul lato client. Voi mettereste il
motore di una macchina moderna dentro ad una vecchia 500? Non penso proprio.
Però è, in poche parole, quello che vorrebbero fare con dotNET ed i varii
Windows(9x,ME, ecc). Capite bene che non solo mi sembra un'idea abbastanza
peregrina di concetto(ed infatti nessuno osa ammetterlo pubblicamente), ma
anche, a mio parere, praticamente irrealizzabile, vista la frequenza dei
crash di Windows 98, tanto per dirne uno. Non mi si venga per favore a dire
che non ce ne sono più, perché non è semplicemente vero. Una mia cara amica ha
Windows ME. Un altro amico ha 98. Ce ne sono molti di più di quanti molti di noi
spererebbero, mi sa, e non soltanto in ambito aziendale.
Ho voluto affrontare il tema della portabilità in maniera dicotomica perché
la questione della "compatibilità" delle varie versioni del framework tra loro è
un fattore importante. Molto importante. Stando a questo articolo, le cose non sono rosee per dotNET2, per i motivi
riportati. "Certo, comunque in caso di problemi si può sempre usare il framework
1.1 side-by-side", viene detto. Sicuro, aggiungo io, tanto non abbiamo mica
altri programmi da far girare sul sistema no - oltre alle applicazioni dotNET.
Facendo un rapido conto e mantenendosi su una media di 20MB a framework e
considerando il caso peggiore(1.0, 1.1 SP1 e 2.0), soltanto
di base ci portiamo dietro la bellezza di 60 MB.
Naturalmente, non è finita qui, perché oltre al CLR dobbiamo anche portarci i
vari assembly che, vale la pena ricordarlo, sono DLL. Già, sono DLL, però non
condividono lo spazio di memoria. Quindi per ogni applicazione avremo un
caricamento di tutte le DLL. Tanti auguri.
Altro da aggiungere? Direi di si... spesso si dice che esiste NGEN, un tool
capace di preconvertire il codice IL in codice nativo... già... ne vogliamo
parlare? Questo articolo, fà chiaramente intendere come stanno
veramente le cose, al di là della propaganda e non sono cose da
poco. Il perché è presto detto: nell'articolo si dice(testualmente):" The downside, of course,
is that whenever the runtime (for example via a Service Pack) or one of the
dependencies of your ngen images changes (version upgrade or patch), your ngen
image becomes invalid". Capito? Quindi, non solo valgono soltanto per il
computer per il quale vengono generate, ma anche soltanto fino al prossimo
update di una qualsiasi cosa che in qualche modo modifichi lo stato del sistema
inerentemente all'immagine considerata. Credo che sia abbastanza ovvio che sia
così, perché è chiaro che se cambia qualcosa magari cambiano gli indirizzi e
così via, però fà anche capire che il trade-off nella maggior parte dei casi,
almeno dal mio punto di vista, non è accettabile.
Bene, per ora mi fermo qui, anche se avrei molte altre cose da dire... però
prima preferisco aspettare i commenti .
Buona Domenica,
Andrea