Maurizio's blog 3.0

For those who develop applications using C# or Javascript, but I think Java too, (I’m not a Java developer and then I don’t know if what I’m going to say is true for them as well) ,  there are two kind of writing styles for indentation and code’s blocks formatting .

These styles, known as K&R (Kernighan & Ritchie) style and Allman style, concern the way the opening curly brace is opened, when defining a block of code.

The former places the brace in the same line as the preceding line of code, as you can see in this example:

return {
   name: "Joe"
};

the latter places the curly brace in its own line, as shown here:

return
      {
        name: "Joe"
      };

So, the question is:

Can I use both of these styles or not when writing code ?

The answer is: yes, except for Javascript code.

In Javascript you must always use the K&R style if you want to avoid some subtle bugs that may be very difficult to identify.

For example, if you used the code in Allman style showed below

the return value would be “undefined” and not an object as expected, because the browser insert a semicolon after the word “return”.

If the code below had written in K&R (Kernighan & Ritchie) style:

as shown in first example, the return value would have been an object as expected.

If you use Log4Net as log engine for your applications (in my opinion is the best choice), this simple row in application configuration file can save you by a waste of time and probably by a headache too.

When Log4Net doesn’t log anything due to a configuration error it never throw an exception, and this is the expected (and correct) behavior of a log system which should never block an application due to its internal error. Unfortunately when something went wrong it is quite difficult discover the reason if you don’t have a break in your code.

With that configuration instruction Log4Net “logs” its initialization process in output windows and in Trace system.

If you add a trace listener you can also save this output in a file.

Here’s an example:

This is very useful in production environment where Visual Studio is not installed and then an output window is not available.

Com’è noto, la modalità XP Mode di Windows 7 consente di eseguire una applicazione funzionante sotto Windows XP all’interno di una macchina virtuale XP completamente invisibile all’utente, e con il collegamento all’applicazione visibile nel menù di avvio di Windows 7. Quindi, lanciando l’applicazione dal menù di avvio di Windows 7 verrà automaticamente avviata la macchina virtuale con l’autologon impostato, senza che l’utente si accorga di questo, e dopodicchè l’applicazione in questione sarà eseguita come se apparentemente facesse parte di Windows 7.

Se l’applicazione è dotata di un pacchetto di setup durante la sua installazione nella macchina virtuale XP Mode sarà automaticamente impostato un collegamento nel menù di avvio di Windows 7, onde permetterne l’esecuzione.

Cosa succede l’applicazione non è dotata di un pacchetto di installazione ma è semplicemente copiata nella directory di destinazione ?

Succede che il predetto collegamento, necessario al lancio, non viene creato e quindi l’applicazione pur essendo presente non è di fatto lanciabile (da Windows 7), e quindi è perfettamente inutile!.

Aggiungo inoltre, solo perchè mi è già successo, che alcune applicazioni, tipo una banale applicazione scritta in Visual Basic 6, pur avendo un normale setup, quest’ultimo non crea alcun link nel menù di avvio di Windows 7.

Come ovviare allora al problema ?

Semplice, basta creare un collegamento al nostro eseguibile e copiarlo nella directory C:\Documents and Settings\All Users\Menù Avvio della macchina virtuale XP Mode, e come per magia, esso apparirà nel menù di avvio di Windows 7 sotto le la voce Windows Virtual PC\Applicazioni Windows XP Mode.

Interessantissimo post di Stefano Pronti del nuovo blog MSDN di Supporto Tecnico agli Sviluppatori, che spiega le disastrose conseguenze di non richiamare il metodo Dispose su risorse unmanaged, utilizzate all’interno di una web application.

Per farla breve, le risorse unmanaged utilizzavano un thread secondario rispetto a quello che prende in carico la web request, ed in questo thread secondario veniva sollevata una eccezione non gestita durante la fase di finalizzazione del garbage collector, che, come è noto, viene eseguito in un thread diverso.

In questo caso il comportamento di ASP .NET a partire dalla versione 2.0 è quello di interrompere immediatamente il processo in esecuzione, con conseguenze facilmente immaginabili.

Ho già parlato qui di questo comportamento di ASP .NET e di come sia possibile utilizzare la modalità pre-versione 2.0 di gestione delle eccezioni non gestite sollevate all’interno di thread diversi.

Anche a me è capitato di dover “impazzire” con una applicazione in produzione, abbastanza vasta, che soffriva di frequenti ed improvvise cadute della sessione corrente, con enorme disagio degli utenti.

Nel caso specifico non è stato indispensabile attaccare un debugger per ottenere il dump della memoria al momento dell’eccezione, è bastato debuggare il codice, che non conoscevo neanche bene, e scoprire che venivano creati thread aggiuntivi (!?) il cui codice, in particolari circostanze, sollevava l’eccezione fatale che provocava il riavvio del worker process.

Cosi:

using System.Diagnostics;
void Log(string eventMessage)
{ 
   Console.WriteLine("Event logged by " + (new StackTrace()).GetFrame(1).GetMethod().Name); 
   Console.WriteLine("Event: " + eventMessage);
}

Fonte: Tips & Tricks for ASP.NET, IIS, and Visual Web Developer

L’extender CalendarExtender presente nell’Ajax Toolkit presenta un bug se si cerca di globalizzarlo, ovvero adattarlo ad una specifica cultura. Infatti, la label presente in basso con l’indicazione della data odierna non viene globalizzata ma rimane impostata fissa alla cultura inglese, per cui apparirà sempre la scritta “Today”. Affinchè i controlli dell’Ajax Toolkit possano essere personalizzati sulla base delle varie culture non basta impostare la specifica cultura nel file di configurazione dell’applicazione web (tag globalization), oppure impostarla tramite browser, ma occorre anche abilitare il rendering dello script al supporto di culture specifiche, tramite la proprietà EnableScriptGlobalization dello ScriptManager, che deve essere ovviamente impostata a True (il valore di default è False).

Il Data Access Application Block, contenuto all’interno della Enterprise Library 4.1 consente di richiamare store procedures passando esclusivamente il valore dei singoli parametri richiesti (mediante l’utilizzo del metodo GetStorepProcCommand dell’oggetto DatabaseFactory), nello stesso ordine con cui questi sono espressi nella firma della procedura. Poichè ADO .NET richiede comunque che ogni informazione in merito ai parametri della store sia obbligatoria (quindi tipo di dato, dimensione, precisione, scala, ecc), il metodo effettua internamente una chiamata al metodo DeriveParameters di ADO .NET che, attraverso un round-trip al database server, consente di recuperare tutte le informazioni necessarie sui parametri. Poichè come detto, questa chiamata richiede un round-trip verso il server, il data access application block fornisce anche un meccanismo di caching delle informazioni sui parametri recuperate dal server.

Oracle e SqServer hanno un meccanismo differente circa il ritorno di un resultset da una store procedure. Oracle infatti richiede, a differenza di Sql Server, l’utilizzo di un cursore come parametro di output per recuperare il resultset derivante da procedure che lo ritornano, fornendo anche un tipo speciale di dato, cursor appunto, nel suo provider nativo per .NET.

Se si usa il Data Access Application Block per invocare store procedure Oracle che ritornano un resultset attraverso l’uso di un cursore come parametro di output, non è necessario indicare quest’ultimo tra i parametri (anche perchè, pur provando ad indicarlo esplicitamente, non si troverebbe il tipo di dati cursor disponibile tra i tipi di dati in quanto viene usato l’enum System.Data.DbType che rappresenta genericamente i tpi di dati  per qualsiasi .NET Data Provider).

Basta infatti passare un generico parametro di output avente il valore null come primo parametro della store procedure Oracle e l’oggetto OracleDatabase farà il lavoro per noi. Questo oggetto infatti assume che il primo parametro di una store procedure sia un cursore di output per la restituzione del resultset

Avevo già parlato qui (post immediatamente sotto :-)) di uno strano crash di Visual Studio 2008 SP1, a seguito dell’esecuzione comando “Choose items” della toolbox.

Il problema sembrava essere dovuto alla presenza dei PowerCommands e di una loro presunta incompatibilità con il Service Pack 1. Infatti per poter tornare alla “normalità” era necessario un’azione estrema, ovvero rimuovere i PowerCommands, ed a quel punto il problema spariva.

Oggi scopro che attraverso un assemply redirection nel file di configurazione di Visual Studio (devenv.exe.config) il problema si risolve definitivamente, e che il crash si verificava anche nell’editor XAML. Maggiori info qui.

Quindi la soluzione è inserire questo frammento XML nel file di configurazione di Visual Studio:

Non sono un sistemista, nè lo saro mai, ma anche occupandosi solo di sviluppo è utile avere sottomano tools e/o tips prettamente sistemistici che possono essere sicuramente utili.

Eccone uno:

1) netsh interface ip set address “Connessione alla rete locale (LAN)” static 10.xxx.xxx.xxx 255.255.255.0 10.xxx.xxx.xxx 0
2) netsh interface ip set dns “Connessione alla rete locale (LAN) ” static 10.xxx.xxx.xxx primary
3) netsh interface ip add dns “Connessione alla rete locale (LAN)” 10.xxx.xxx.xxx
4) netsh interface ip show config “Connessione alla rete locale (LAN) “

I comandi sopraelencati, messi opportunamente in un file .bat, permettono di settare al volo la configurazione di una scheda di rete ben precisa, ovvero quella la cui descrizione è “Connessione alla rete locale (LAN)”, nell’esempio.

Ovviamente basta cambiare la descrizione della scheda per puntarne un’altra.

La prima riga del batch setta rispettivamente l’indirizzo ip, la subnetmask ed il default gateway. La seconda riga imposta l’indirizzo ip del server dns primario, mentre la terza quello del dns secondario. La quarta riga visualizza a console le impostazioni della scheda appena settate.

Questo vale quando vogliamo settare indirizzi ip ben specifici. E se invece vogliamo che la scheda sia impostata con indirizzi ip ottenuti da un server DHCP ?

Ecco i comandi:

1) netsh interface ip set address “Connessione alla rete locale (LAN)” dhcp
2) netsh interface ip set dns name=”Connessione alla rete locale (LAN)” source=dhcp
3) netsh interface ip show config “Connessione alla rete locale (LAN)”

Per la descrizione della scheda vale quanto già detto. La prima riga imposta la modalità DHCP. La seconda imposta la modalità DHCP per i server DNS, mentre la terza mostra a console la nuova configurazione.

Una caratteristica che ogni buon software dovrebbe, a mio avviso, avere riguarda la leggibilità del codice sorgente, intesa nel senso letterale del termine. Leggibilità significa che, quando si legge codice scritto da altri, non si dovrebbe faticare più di tanto a leggerlo “a colpo d’occhio”.
Molto spesso però si finisce per fare una gran fatica per comprendere codice magari anche non troppo complesso dal punto di vista della tecnica di programmazione, ma scritto decisamente senza alcuna linea guida.
Tra le linee guida minori che, secondo il mio parere, riveste comunque una certa importanza, è da menzionare la lunghezza delle varie linee di codice. Mi riferisco a quelle linee, es dichiarazioni di metodi, di interfacce, ecc., che superano di gran lunga la larghezza di uno schermo a media risoluzione (es. 1024×768) e che costringono ad un lunghissimo scrolling in orizzontale per leggere tutto il contenuto. L’abitudine a scrivere su una sola riga fisica una istruzione peggiora a mio parere la leggibilità del codice, al pari di scrivere senza conformarsi ad alcuna linea guida.
L’ambiente VS non aiuta certamente, in quanto l’editor di codice sorgente non fornisce una guida, una specie di righello alla Word per intenderci, in modo da rendere immediatamente percebibile al programmatore che la scrittura sta per superare il margine destro della finestra.
Però, attraverso un trick non documentato che comporta una semplice modifica al registro di Windows, è possibile ottenere una linea guida verticale del colore desiderato e posizionata alla colonna desiderata, rendendo la soluzione flessibile alle varie risoluzioni dello schermo.
Basta infatti aprire l’editor del registro ed inserire la chiave “Guides” di tipo stringa
nella posizione:

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\Text Editor]

attribuendogli ad es. il valore

“RGB(255,0,0) 120”

Come è facile intuire questa chiave crea un righello del colore specificato (in questo caso rosso)
alla colonna specificata (120),  all’interno dell’editor del codice di Visual Studio.
E’ possibile anche creare più di un righello indicando più posizioni di colonna separate da virgola.
Questa soluzione funziona con VS 2003. Per VS 2005 occorre creare la chiave alla posizione
“…\8.0\Text Editor” invece che 7.1.

Se si modifica il Registry mentre VS è in esecuzione occorre riavviarlo affinchè la modifica abbia effetto.