Maurizio's blog 3.0

Nella versione 1.1 del .NET Framework accedere alla porta seriale per poter leggere/scrivere dei dati richiede l’uso delle API di Windows preposte allo scopo. Pertanto è necessario creare una classe wrapper che incapsula l’accesso alle API e fornisce i metodi pubblici necessari alla gestione della porta ed all’invio/ricezione delle informazioni. Nel .NET Framework 2.0 questa classe wrapper è già presente e ne viene fornito un esempio di utilizzo attraverso uno snippet code presente nell’elenco degli snippet code di Visual Studio 2005.

Pertanto, questa operazione, prima non certamente banale, è diventata di una semplicità disarmante nel Framework .NET 2.

Con l’uscita della versione 2.0 del Framework .NET molte applicazioni ASP .NET migreranno alla nuova versione, che assicura una compatibilità al 100% all’indietro e una migliore compatibilità verso gli standard Web (vedi XHTML). Questa migrazione avverrà certamente per gradi, e ci troveremo sicuramente in situazioni in cui sullo stesso server saranno installate applicazioni ASP .NET compilate con differenti versioni del Framework. Questo non è affatto un problema grazie alla cosiddetta esecuzione side by side del codice gestito, mediante la quale differenti versioni del Framework .NET possono essere installate sullo stesse ambiente di esecuzione; quindi saranno comuni i casi in cui sulla stessa macchina gireranno applicazioni ASP .NET compilate con differenti versioni del Framework, le quali conviveranno in modo pacifico.

Ma c’è una eccezione a questa regola e riguarda le applicazioni ASP .NET che, come sappiamo, possono essere eseguite all’interno di processi distinti attraverso la creazione di uno o più application pool, configurabili attraverso il pannello di controllo di IIS.

La regola è questa: non è possibile far girare applicazioni ASP .NET compilate con differenti versioni del .NET Framework all’interno di uno stesso processo (worker process), pena un errore a run-time documentato chiaramente nell’application log. In casi del genere occorre creare differenti application pool (almeno 2, uno per il framework 2.0 e l’altro per la versione 1.1) ed associare ad ognuno le applicazioni compilate con la stessa versione.

Un’altra soluzione può essere quella di creare application pool distinti per ogni applicazione ASP .NET funzionante 

Se si ospitano più applicazioni web ASP .NET in application pool distinti su macchine multiprocessore dotati di SO Windows 2003 si potrebbe andare incontro ad un lento degrado delle prestazioni fino ad ottenere:

a) OutOfMemoryException

b) Classico messaggio d’errore “Server Application Unavailable”

Questo comportamento è causato dal funzionamento del meccanismo del garbage collector su sistemi multiprocessore. Su tali sistemi il GC è attivo in modalità Server; questa modalità permette di aumentare le sue prestazioni attraverso la creazione di un heap distinto per ogni processore presente, caratteristica che in presenza di vari worker process porta ad un consumo eccessivo di memoria e da qui ai messaggi di errore menzionati. Questo indesiderato comportamento delle applicazioni ASP .NET è indipendente dalla versione del .NET Framework utilizzata, e si verifica su tutte le versioni di Windows 2003 con IIS 6.0 in modalità nativa con multiple appication pool configurate.

Per ovviare a tale inconveniente occorre forzare l’utilizzo della modalità di funzionamernto “Workstation” del GC, modalità che crea sempre un solo heap e quindi non causa un eccessivo consumo di memoria anche in presenza di application pool distinti.

Per abilitare questa modalità occorre modificare il file aspnet.config, raggiungibile nella directory della specifica versione del Framework che si sta utilizzando nel percorso WIndows\Microsoft.NET\Framework, aggiungendo la seguente riga:

<gcServer enabled=”false”/>

al nodo configuration\runtime.

Questa anomalia è documentata qui

Erika Ehrli mostra in questo articolo come implementare un add-in per Visio 2003, utilizzando Visual Studio .NET 2003, per effettuare una query LDAP sugli utenti in Active Directory e creare un diagramma in Visio suddiviso per dipartimento. Nonostante non sia un sistemista ma uno sviluppatore, penso che un add-in come questo mi tornerà utilissimo; in passato mi sono sempre chiesto se Visio non avesse tra i propri diagrammi qualcosa del genere. Davvero un ottimo ed utile esempio di Office Development da provare al più presto

Finalmente ha visto la luce la versione 2.0 della famosissima Enterprise Library, completamente rivista e ridisegnata in funzione della versione 2.0 del .NET Framework. Coloro che come me hanno utilizzato la versione disegnata per il .NET Framework 1.1 avranno certamente apprezzato la flessibilità e facilità di utilizzo che questi componenti forniscono allo sviluppatore e, caratteristica molto importante, la capacità di integrarsi in modo estremamente rapido in applicazioni reali

Visto che ogni inizio anno è tempo di promesse e buoni propositi, non sarò certo io a tirarmi indietro.

In ordine sparso ecco la mia lista di previsioni/speranze/promesse per l’anno appena iniziato:

• Concludere in tempi ragionevolmente brevi il nuovo percorso di certificazione Microsoft MCPD
• Partecipare allo sviluppo di un software open-source (di quelli non banali)
• Imparare un nuovo linguaggio di programmazione  (mi piacerebbe il C++, ma la vedo molto dura)
• Guadagnare di più
• [ ……personale …..]
• [ ……personale……]
• Aver finalmente dato una dimora fissa al mio blog
• Curare di più il mio nuovo sito xplayn.org e questo blog
• Conoscere altri amici informatici grazie alle community e/o blogs
• Che il mio amico di avventura Francesco possa accrescere le proprie soddisfazioni professionali (ed i propri guadagni), perchè se lo merita

Mi auguro che tutto questo si avveri, e auguro a tutti i lettori occasionali e non di questo blog di esaudire i proprio desideri per questo anno appena iniziato.