.NET Framework 1.0 / 1.1 / 2.0

TextBox ReadOnly in .NET 2.0 e successivi

Il controllo TextBox di una web application dispone della proprietà ReadOnly che, ovviamente, impedisce l'interazione dell'utente con il controllo quando è impostata a True. Ma c'è un particolare importantissimo da considerare: a partire dalla versione 2.0 del .NET Framework il contenuto di un textbox in modalità "ReadOnly" è inviato al server durante un postback della pagina, ma il server ignora questo valore; in altre parole il contenuto del textbox viene perso durante un postback. Questo comportamento mira ad impedire attacchi alla sicurezza, che potrebbero modificare un valore che dovrebbe essere mantenuto inalterato. La perdita del valore del textbox può essere inaccettabile in certi contesti applicativi e potrebbe...

posted @ Tuesday, February 26, 2008 10:13 AM | Feedback (1)

Eccezioni non gestite in ASP .NET 2.0

Le eccezioni non gestite generate da una applicazione ASP .NET compilata con la versione 2.0 del .NET Framework sono trattate diversamente da quanto avveniva con le applicazioni ASP .NET compilate con la versione 1.0/1.1. Queste ultime semplicemente ignoravano le eccezioni non gestite sollevate all'esterno del contesto corrente, es. un thread diverso da quello principale, mentre le eccezioni sollevate all'interno del contesto erano trattate normalmente come qualsiasi eccezione non gestita. Con il .NET Framework 2.0 questo comportamento è cambiato: le eccezioni non gestite sollevate fuori dal contesto provocano l'immediata interruzione del worker process e conseguentemente dell'applicazione. L'unica traccia è un laconico...

posted @ Thursday, January 10, 2008 7:43 PM | Feedback (0)

Metriche del codice e SourceMonitor

Ho provato SourceMonitor, un interessante tool freeware per effettuare metriche sul codice sorgente scritto in vari linguaggi di programmazione, tra cui C#, C, C++, VB .NET, Delphi.Attraverso una interfaccia di gestione molto semplice acquisisce una serie di informazioni, le metriche appunto, analizzando il codice sorgente di un progetto. Queste informazioni possono essere salvate in diversi momenti e nominate (checkpoints), onde poter mettere a confronto metriche di uno stesso progetto create in momenti diversi.Analizzare le metriche del proprio codice aiuta ad evidenziare eventuali colli di bottiglia, ovvero parti dello stesso da sottoporre a code review, e a migliorare quindi la qualità...

posted @ Thursday, January 10, 2008 3:21 PM | Feedback (0)

Fix applicate dal .NET Framework 2.0 SP1

A questo link è disponibile la serie di fix apportate dal Service Pack 1 del .NET Framework 2.0. Per il momento memorizzo il link, ma non appena il tempo me lo permette conto di dargli una lettura.

posted @ Monday, December 24, 2007 2:48 PM | Feedback (0)

Implementazione esplicita di membri di interfaccia

L'implementazione esplicita di una interfaccia presenta caratteristiche significative rispetto ad una implementazione per così dire non esplicita. Ad esempio, si consideri l'interfaccia: public interface IExplicitImplementation  { string Method1(string par); } e la seguente classe che la implementa in modo esplicito: public class Class1 : IExplicitImplementation  { string IExplicitImplementation.Method1(string par) {              return "Hello world " + par; } } Le caratteristiche salienti sono: - Il client che consuma la classe Class1 utilizzando una istanza di quest'ultima è impossibilitato a richiamare il metodo Method1 in quanto quest'ultimo NON fa parte dell'interfaccia pubblica della classe (non è visibile con l'intellisense ed il tentativo di richiamare comunque il metodo genera un...

posted @ Thursday, October 25, 2007 12:13 PM | Feedback (0)

Come terminare un processo corrotto in .NET

Da .NET 2.0 in poi è possibile terminare un processo corrotto irreparabilmente attraverso il medodo Environment.Failfast(string message), il quale provvede a: Scrivere una entry nell'Application Event Log con il messaggio specificato NON eseguire alcun blocco try-finally ancora in sospeso NON esegue alcun finalizer sugli oggetti ancora in memoria Esegue un dump dell'applicazione Termina il processo I punti 2-3 sono necessari in un contesto simile in quanto la loro esecuzione potrebbe danneggiare risorse usate dall'applicazione stessa. Tuttavia gli oggetti CriticalFinalizerObject (di cui magari parlerò in un post a parte) sono comunque eseguiti prima di terminare il processo.

posted @ Thursday, October 25, 2007 6:54 AM | Feedback (0)

XML Serializer Generator Tool

La serializzazione XML in .NET è una operazione onerosa in termini di risorse di sistema a causa della creazione a runtime di un assembly temporaneo contenente funzionalità fortemente tipizzate di "reader" e "writer" del tipo da serializzare, le quali comportano un utilizzo intensivo di CodeDom e Reflection. Osservando con il tool Reflector il codice del costruttore della classe XmlSerializer (comprendente vari overloads) è possibile notare tutto ciò unito all'utilizzo del meccanismo di caching dell'assembly temporaneo creato (sembra però che non tutti gli overloads del costruttore facciano uso della cache con conseguente creazione dell'assembly ad ogni utilizzo). Questo meccanismo è poco...

posted @ Saturday, August 18, 2007 3:24 PM | Feedback (0)

Deserializzazione in .NET 2.0

Il meccanismo di deserializzazione ha subito una modifica (a mio avviso migliorativa) in .NET 2.0 rispetto a quanto avveniva in .NET 1.1. La versione 2.0 ha la capacità di deserializzare un oggetto anche se questo presenta nella sua forma serializzata informazioni aggiuntive (es. membri pubblici) non presenti invece nella particolare versione dell'oggetto che  stiamo deserializzando. Mi spiego meglio. Supponiamo che abbiamo la nostra onnipresente classe Person con 3 campi pubblici, ovvero FirstName, LastName e Age, e che alcune istanze di questa classe siano serializzate in formato binario attraverso l'uso della classe BinaryFormatter utilizzando una applicazione scritta in .NET 2.0, e che il risultato...

posted @ Tuesday, February 13, 2007 7:55 PM | Feedback (0)

Uso di reflection per invocare metodi interni

In un post precedente ho parlato dell'uso dell'attributo AllowPartiallyTrustedCallers a proposito della sicurezza applicata all'invocazione di metodi pubblici definiti all'interno di un assembly strong-named.  Rimanendo sempre sullo stesso tema, un altro attributo utile a "limitare" i possibili chiamanti di un determinato metodo è StrongNameIdentityPermissionAttribute, usato in questo modo: [StrongNameIdentityPermissionAttribute(SecurityAction.LinkDemand, PublicKey = "public key")] public string MyMethod(string parameter) {} La presenza di questo attributo permette la chiamata al metodo MyMethod dell'esempio solo al codice contenuto in un assembly firmato con strong name e che presenta la chiave pubblica specificata nell'attributo stesso. Qualsiasi altro codice che tentasse di...

posted @ Wednesday, January 31, 2007 7:48 PM | Feedback (0)

String intern pool

L'Intern pool, di cui non è la prima volta che ne parlo, è un hashtable mantenuto internamente dal CLR contenente stringhe generalmente usate per memorizzare valori costanti. In questo hashtable sono memorizzate le costanti stringa a livello di compilazione ed ogni stringa aggiunta esplicitamente attraverso l'utilizzo del metodo string.Intern, il quale aggiunge una stringa nell'intern pool (quindi nell'hashtable) e ne ritorna il riferimento se la stessa non è già presente, in caso contrario  ritorna sempicemente il riferimento ad essa. In questo modo è garantito che se due stringhe (o più) contengono gli stessi valori letterali sarà utilizzato (e quindi sarà presente...

posted @ Wednesday, January 24, 2007 8:01 PM | Feedback (0)

Verificare che il .NET Framework sia installato e relative versioni

Per verificare che il .NET Framework sia installato ed eventualmente in quali versioni è possibile procedere in questo modo: La semplice presenza del file MSCOREE.DLL (Microsoft .NET Runtime Execution Engine) nella directory %SYSTEMROOT\system32 è sintomo che almeno una versione del CLR è installata La chiave del registry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy contiene delle sottochiavi, una per ogni versione installata, nella forma vX.X (es. v2.0) La versione 2.0 del  .NET Framework contiene una nuova utility denominata CLRVer.exe, che, come il suo nome lascia intuire, elenca tutte le versioni del CLR installate sulla macchina su cui viene eseguita. Molto interessanti sono i parametri -all, che elenca tutte le applicazioni managed...

posted @ Wednesday, December 20, 2006 1:40 PM | Feedback (0)

App_offline.htm e i 512 byte

Nonostante qualche commento negativo letto in Rete, a me il comportamento di ASP .NET 2.0 in presenza del file app_offline.htm nella root della web application mi sembra abbastanza comodo e funzionale. Ricordo che questo file è utile quando si è in fase di manutenzione della propria applicazione web e si vuol fornire un messaggio "user friendly" agli utenti informandoli che l'applicazione non è momentaneamente disponibile, o qualsiasi cosa si voglia. In presenza di un file con tale nome infatti, l'engine di ASP .NET 2.0 effettua lo shutdown dell'applicazione, scarica l'appDomain e risponde ad ogni richiesta dei files normalmente gestiti dallo stesso...

posted @ Saturday, November 18, 2006 4:09 PM | Feedback (0)

LinkDemands, il corretto modo di utilizzarlo

Una cosa che non sapevo, e che desidero condividerla con gli (eventuali) lettori di questo blog: un link demand a livello di metodo sovrascrive sempre un link demand a livello di classe anche se trattasi di permessi differenti. Esempio, data questa classe: [FileIOPermission(SecurityAction.LinkDemand, Unrestricted=true)]public class ClassA  [EnvironmentPermission(SecurityAction.LinkDemand, Read="VAR1" )]  public void Method1)  {  }} Il link demands a livello di metodo effettua l'override di quello a livello di classe, anche se si tratta di permessi differenti. In questo caso il link demands EnvironmentPermission sostituisce il link demands FileIOPermission, con la conseguenza che quest'ultimo permesso non viene richiesto per il metodo in questione. Morale, occorre esplicitamente...

posted @ Thursday, November 02, 2006 1:37 PM | Feedback (0)

Array bound check: operazione onerosa ?

Questa è una domanda che mi sono posto anch'io parecchie volte: il controllo dei limiti inferiore e superiore di un array che il compilatore JIT opera durante l'esecuzione di una tipica applicazione .NET è una operazione onerosa o no, e se si di quanto ? Ci si può fare una idea abbastanza significativa leggendo questo post di Rico Mariani, il quale ha effettuato dei test comparati su una applicazione .NET che utilizza il compilatore JIT tradizionale e la stessa applicazione che invece utilizza un compilatore JIT da lui stesso modificato, e precisamente senza il controllo dei limiti degli array (mscorjit.dll). Dal post si...

posted @ Tuesday, August 29, 2006 3:00 PM | Feedback (0)

NDOC 2.0 ? No, Sandcastle

La versione di NDOC per il Framework 2.0 sembra che non vedrà mai la luce, almeno leggendo le ultimissime notizie. Peccato, ho usato NDOC su parecchi progetti e devo dire che sono sempre stato soddisfatto dei risultati raggiunti con l'utilizzo di questo tool, soprattutto quando manca il tempo per documentare un progetto usando classiche soluzioni alternative. Però potremo produrre docuntazione "MSDN like" usando Sandcastle, il tool usato internamente da Microsoft per la documentazione tecnica dei progetti che la stessa ha deciso di rendere disponibile al download. Si tratta di un tool che via reflection ottiene le informazioni sui vari assembly integrandole con la eventuale...

posted @ Saturday, August 05, 2006 4:00 PM | Feedback (0)

.NET Pet Shop 4.0

E' disponibile per il download la versione 4.0 di .NET Pet Shop, una applicazione "benchmark" di esempio per confrontare le prestazioni di una applicazione ASP .NET di classe enterprise con una equivalente applicazione J2EE. La versione 4.0 è focalizzata su ASP .NET 2.0 e mostra come ottenere una applicazione robusta riducendo il numero di righe di codice sorgente necessarie. In questa versione è possibile vedere all'opera le seguenti caratteristiche della versione 2.0 di ASP .NET e del .NET Framework: Uso del nuovo namespace System.Transaction per la gestione di applicazioni distribuite senza ricorrere a COM+, aumentando le prestazioni Uso dei generics Master Pages,...

posted @ Saturday, February 18, 2006 4:27 PM | Feedback (0)

Accedere alla porta seriale in .NET 2.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.

posted @ Tuesday, January 31, 2006 7:29 PM | Feedback (1)

Enterprise Library 2.0

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

posted @ Monday, January 23, 2006 6:08 AM | Feedback (0)