Passaggio a Visual studio 2010 e a .NET framework 3.5

[teopost]

In piu' di una occasione, mi sono dovuto scontrare con problemi del framework .NET che poi ho scoperto, grazie a San Google, che erano gia' stati risolti nell'ultima versione del framework.
Io credo che sarebbe il caso di pensare ad un porting verso l'ultima versione del framework nonchè, visto che siamo, ad un aggiornamento del progetto generato all'ultima versione.
Parlo di Visual Studio 2010.

[poidomani]

concordo

[g.lanzi]

Per quanto riguarda i problemi di framework a noi non risultano malfunzionamenti delle applicazioni fatte con In.de. Se ci sono comportamenti che hanno a che fare con classi o librerie esterne c'è una semplice soluzione perché fortunatamente i framework .Net sono retrocompatibili, e un'applicazione o una dll scritte in 2.0 girano tranquillamente sul 3.5 o sul 4.0.
Da questo punto di vista non dovrebbero esserci problemi, basta tenere aggiornato il framework. Inoltre il framework 2.0 è presente su tutte le macchine mentre invece la versione 3.5 no, un altro motivo per restare fedeli alla 2.0.

Per VS2010 invece il caso è diverso. La versione 2010 dell'ambiente di microsoft dovrebbe essere in grado di aprire le solution di versioni precedenti, per quanto ne so dovrebbe semplicemente effettuarne la conversione. Invece VS2005 non mi risulta in grado di fare correttamente la procedura dall'altro verso.

Se passassimo a VS2010 costringeremmo tutti i nostri clienti che vogliono aprire le solution a comprare nuove licenze di VS2010.

C'è da considerare inoltre che aprire la solution con VS non è necessario: è presente il debug&trace, il debug step-by-step, e l'applicazione parte con un web server Cassini dedicato come fa VS.

[lucabaldini]

Aggiungo il mio pensiero...

Framework 3.5
La DLL in cui è contenuto il nostro runtime (IJLib.dll) non è compilata in codice nativo bensì utilizzando l'opzione "Target:Any" il cui effetto è quello di compilare la DLL in MSIL (http://it.wikipedia.org/wiki/Common_Int ... e_Language). Quando poi l'applicazione viene eseguita la virtual machine .NET carica la DLL, la interpreta e la "compila al volo" in codice eseguibile dal processore. Questo fa sì che se su una macchina è presente solo il framework 3.5 (o 4) la mia DLL può essere eseguita UTILIZZANDO QUEL FRAMEWORK e non utilizzando il framework su cui ho compilato io. Praticamente il MSIL è analogo al byte-code di java: ogni istruzione JAVA viene tradotta in una sequenza di codici che la macchina virtuale interpreta per poterli eseguire.
Faccio un esempio per spiegarmi meglio. Supponi che io abbia utilizzato la funzione ToSting() della classe nativa Int32 e che, a causa di un difetto, nel framework 2.0 quel metodo non funzioni correttamente. Io compilo la DLL che usa quella funzione utilizzando il framework 2.0 (e come ti ho scritto sopra non è importante il framework che utilizzo per compilare). Poi avvio l'applicazione sul mio IIS su un server dove è presente il framework 2.0. Qui potrei avere problemi dato che la mia DLL viene "compilata al volo" usando il framework 2.0 e quindi la funzione ToString torna un risultato non corretto. Però se eseguo la mia applicazione su un server dove sia presente il framework 3.5 e attivo tale framework sul sito web dentro ad IIS, allora l'applicazione web utilizza il framework 3.5 per "compilare al volo" la mia dll e questa volta il metodo ToString() torna il risultato corretto.
Tutto questo per dirti che io non avrei problemi a passare al framework successivo... ma non ne avrei alcun vantaggio.
Anzi, so per certo che in JAVA avrei problemi dato che SUN ha deciso ad un certo punto, di cambiare il formato analogo all'MSIL quindi un JAR compilato con un framework nuovo non è usabile su un server tomcat dotato di un framework più vecchio.
Non so se questo è un problema anche per Microsoft ma nel dubbio rimarrei fisso al framework 2.0.
Quando dovrò utilizzare funzionalità specifiche del framework 3.5 (JSON?) ci farò un pensierino... magari compilo usando quel framework e segnalo errore se l'utente avvia l'applicazione su un server dove non sia presente quel framework.

Visual Studio 2010
Qui il problema è anche più subdolo. Io genero la solution in formato VS2005. La solution è un file di testo di tipo XML e mi aspetto che tutte le versioni successive di VS siano in grado di analizzare la solution e, qualora sia necessario, di convertirla automaticamente. Questo è sempre stato vero con VB e con VS (6.0, 2003, 2005).
So per certo che il mio VS2005 non è in grado di aprire solution salvate con VS2010 (viene generato un errore che dice, appunto, che non può essere aperta una versione prodotta con un VS futuro... e questa è una mezza follia dato che una solution web non è altro che un puntatore alla cartella web).
Se io producessi la solution in formato 2010 romperei le scatole a tutti gli utenti che hanno VS2005 (me compreso) e che quindi avrebbero problemi ad aprire la solution.

Però se hai una solution prodotta con INDE che VS2010 si rifiuta di aprire giramela via e-mail così analizzo il problema.

[teopost]

Luca, come sempre la tua analisi Luca è precisa e puntuale.
Credo che l'osservazione sugli eventuali problemi di licenza sia un falso problema.
Chiunque utilizzi .NET per sviluppare tende ad aggiornarsi con l'ambiente di sviluppo. Inoltre qui parliamo di una solution che INDE genera per la versione 2005. Sono gia' uscite 2 versioni.
Nel mio computer, come penso anche nei pc di altri vostri colleghi, sono costretto a tenere 2 ambienti di sviluppo. Sia la versione che mi consente di lavorare con INDE che l'ultima.
I motivi sono moplteplici.
Ad esempio solo con la versione 2010 posso sviluppare web service di tipo stateful. La versione 2005 non mi consente di farlo e, aimè purtroppo, neanche INDE che eredita ovviamente questa limitazione.
Altro esempio. Recentemente ci siamo sentiti per rimappare alcune librerie che consentono di generare stringhe JSON dentro INDE. Ebbene mi risulta che con Visual Studio 2010 (o meglio con .net 3.5) esistano già alcune librerie che permettano di farlo.
Altro esempio. Per leggere feed RSS con INDE attualmente devo fare un parsing dell'XML. Con .net 3.5 esistono gia' una serie di classi che prevedono la lettura di feed nei vari formati.
Quello che voglio ribadire è che secondo me INDE dovrebbe cercare di stare un po più al passo con i tempi. D'altronde dal 2005 al 2010 ci sono 5 anni che nell'informatica, come sai, sono tanti :-)
L'implementazione ideale, e probabilmente impossibile, sarebbe che INDE consentisse di generare la solutione per i vari tipi di IDE.

Ciao

[lucabaldini]

Forse non sono stato chiaro. Provo a rispondere alle tue segnalazioni:

Chiunque utilizzi .NET per sviluppare tende ad aggiornarsi con l'ambiente di sviluppo. Inoltre qui parliamo di una solution che INDE genera per la versione 2005. Sono gia' uscite 2 versioni.

Questo, purtroppo, non è sempre vero. Per chi compila in c++, per esempio, non è scontato. Quando sono passato dalla versione 6.0 alla versione 2005 la Microsoft ha cambiato il compilatore e la compilazione di INDE generava qualcosa come un migliaio di errori che, con la versione 6.0, non c'erano. Non so se l'hanno rifatto ma mi aspetto che quando passerò alla versione 2010 per compilare INDE avrò lo stesso problema.
Per chi compila applicazioni .NET forse la cosa è indolore (dato che visual studio NON E' UN COMPILATORE ma un editor di testo che, quando chiedi di compilare, lancia il compilatore .NET che trova installato sulla macchina (CSC.EXE)) e quando chiedi di avviare l'applicazione web o WS lancia CASSINI.

Ad esempio solo con la versione 2010 posso sviluppare web service di tipo stateful. La versione 2005 non mi consente di farlo e, aimè purtroppo, neanche INDE che eredita ovviamente questa limitazione.

Visual Studio è un editor di testo evoluto ma ciò che viene usato dalle applicazioni è il framework .NET. Se volessi creare WS statefull potrei farlo tranquillamente anche con INDE senza cambiare né framework né la versione della solution. Per farlo basterebbe aggiungere un nuovo flag alle procedure per indicare quali siano stateful e quali stateless e dire ad INDE che per i metodi stateful deve aggiungere EnableSession=true

[WebMethod(Description=DESCRIZIONEDELMETODO,EnableSession=true)]

(trovi altre info http://msdn.microsoft.com/it-it/library/system.web.services.webmethodattribute.enablesession.aspx dove è anche scritto che questa funzionalità è presente dalla versione 1.0 del framework!)

Tieni sempre conto che non è necessario Visual Studio per sviluppare applicazioni web... c'è gente (molta gente) che sviluppa in .NET usando compilatori open source (come per esempio SharpDevelop che trovi qui http://www.icsharpcode.net/OpenSource/SD/Default.aspx) dato che, come ti ho scritto sopra, Visual Studio è un editor di testo evoluto e, se io volessi, potrei tranquillamente usare Ultraedit per creare applicazioni web allo stato dell'arte che utilizzino il framework 4.0.

Altro esempio. Recentemente ci siamo sentiti per rimappare alcune librerie che consentono di generare stringhe JSON dentro INDE. Ebbene mi risulta che con Visual Studio 2010 (o meglio con .net 3.5) esistano già alcune librerie che permettano di farlo.
Altro esempio. Per leggere feed RSS con INDE attualmente devo fare un parsing dell'XML. Con .net 3.5 esistono gia' una serie di classi che prevedono la lettura di feed nei vari formati.

Se lo desideri potremmo mappare tranquillamente metodi che esistono solo nel framework 3.5 anche all'interno dei tuoi progetti. Poi, però, puoi eseguire l'applicazione solo su macchine dove quel framework è installato. Quando installi l'applicazione dentro IIS devi indicare che quell'applicazione richiede almeno il framework 3.5 altrimenti quando il compilatore tenta di compilare quelle righe di codice "specifiche della versione 3.5" genera errore di compilazione. Come ti dicevo nella risposta precedente non è necessario compilare il mio framework con la versione 3.5 per poter usare funzionalità della versione 3.5. Se lo desideri puoi tranquillamente mappare quelle classi ed usarle nelle tue applicazioni e, se hai bisogno di aiuto per farlo, ti invito a contattare il servizio di assistenza per farlo insieme.

Quello che voglio ribadire è che secondo me INDE dovrebbe cercare di stare un po più al passo con i tempi. D'altronde dal 2005 al 2010 ci sono 5 anni che nell'informatica, come sai, sono tanti :-)
L'implementazione ideale, e probabilmente impossibile, sarebbe che INDE consentisse di generare la solutione per i vari tipi di IDE.

Non sono d'accordo. Secondo me non è corretto dire "INDE non è al passo con i tempi perché genera solution in formato 2005 o perché ancora oggi non ha un parser JSON integrato e nativo".
Inoltre non mi è chiaro per quali IDE dovrei generare le solution. Ne sono usciti molti: 2003, 2005, 2008, 2010 e altri ne usciranno. Mi stai chiedendo di generare le solution per tutte le versioni di VS?
Allora ti chiedo un aiuto: hai una solution generata con INDE che non si apre con VS2010? Perché se è così ci guardo volentieri e, magari, provo a generarla in maniera "friendly" sia per VS2005 che per VS2010 altrimenti continuo a non capire dove sia il problema che segnali.

[lucabaldini]

Aggiungo solo una cosa riguardo ai WebService stateful. Ad oggi non mi è ancora capitato di aver necessità di creare WS stateful ma se dovesse essere necessario (e dovesse essere una funzionalità richiesta) si può anche pensare di analizzare la cosa e valutare di implementarla.
Tieni conto, però, che i WS sono per loro natura lenti e, come dice M$ stessa,

If session state is not needed for an XML Web service method, then disabling it may improve performance.

[teopost]

Errata corrige.
Ho parlato di web service stateful. Volevo dire RESTful e non SOAP.
Per quanto riguarda la generazione di una solution apribile da visual studio 2010, dopo colloqui telefonico con Luce, sembra che le cose siano molto più semplici del previsto.
Luca mi ha modificato il file InstWeb.sln.
Mettento tale file nella custom, il progetto ora si apre anche con l'ultima versione di visual studio.
Ho subito disinstallato la versione 2005.
Non sarebbe male se il progetto generato da INDE contenesse gia' tale file per ogni versione.
Ad esempio NomeProgetto2005.sln, NomeProgetto2008.sln, NomeProgetto2010.sln
Che ne dite ?
Allego il file.
Ah. Dimenticavo. Grazie Luca!

[r.bianco]

Anche noi usiamo VS2010, sarebbe interessante.

[lucabaldini]

Ora, però, sono curioso... mi potete aiutare a capire perché aprite così spesso le solution con visual studio?
Se è per debuggarle perché non usate il debug nativo o quello step-by-step che sono integrati?
Se è per pubblicarle perché non scrivete un batch che pubblichi la solution senza necessità di avviare tutto VS, qualcosa del tipo:

"C:\Windows\Microsoft.NET\Framework\[VERSIONE_FRAMEWORK.NET]\aspnet_compiler.exe" -p "[DIRECTORY_APP]" -v [NOMEAPP] -f -c -nologo "[PERCORSOPUBBLICAZIONE]

Tra l'altro nella versione 10 la pubblicazione è integrata dentro In.de e i sorgenti vengono automaticamente compilati durante la fase di pubblicazione.
C'è davvero bisogno che io crei 4-5 solution?