martedì, gennaio 29, 2008

Convert int[] to string[]

It's very common to need to convert an array of type T1 to an array of type T2.
Net 2.0 offers an interesting static member of the Array class: ConvertAll.
Using anonymous methods (MSDN) in conjunction with ConvertAll, you can convert an array of "simple" type to an array of another "simple" type in only ONE line of code.

An example: int[] to string[]

int[] inInt = new int[] { 47, 46, 45, 101 };

string[] outStr = Array.ConvertAll<int, string>(inInt, new Converter<int, string>(delegate(int x) { return x.ToString(); }));


or (smaller):

string[] outStr = Array.ConvertAll<int, string>(inInt, delegate(int x) { return x.ToString(); });


You can also convert string[] to int[]:

int[] outInt2 = Array.ConvertAll<string, int>(outStr, delegate(string s) { return int.Parse(s); });



If you need to convert between more complex type, probably you need more code in the delegate body. But the idea is the same: use a delegate as a converter between 2 types.

domenica, gennaio 27, 2008

Sviluppo "parallelo"

Ormai sono anni che i processori sono a tutti gli effetti dei "multi"processori. Si era iniziato con l'HyperThreding, poi i Dual Core, poi i QuadCore ed avanti così. Ma per gli sviluppatori la domanda è: ma ve ne fate realmente qualcosa di questi oggetti che sono in grado di eseguire più istruzioni in parallelo? Per molti la risposta è: NO! Ed il motivo è molto semplice: le applicazioni Console e Windows Form che sviluppano sono intrinsecamente mono-processo, o meglio mono-thread. Discorso a parte ovviamente per le applicazioni web tipo asp.net: questo effettivamente è un mondo effettivamente multi-thread.
Lo sviluppo parallelo non sempre è applicabile. Anzi sovente la logica è instrinsecamente lineare e non ci sono spazi per parallelizzarla. In altri casi invece questo è possibile. Ma qui iniziano i dolori. Senza un adeguato supporto fornito dal linguaggio/framework è molto oneroso (e tedioso) gestire i vari thread paralleli. Ed è forse per questo che, a meno di situazioni particolari in cui le performance sono fondamentali, si rinuncia allo sviluppo "parallelo" e si rimane sul tranquillo "seriale".
Come ho detto in precedenza, l'hardware è ormai molto avanti. Il software (sviluppo e framework) è ancora un po' indietro. Ma le cose stanno cambiando: un segno è l'uscita come Community Tecnology Preview di Parallel Extensions to .NET. Questa libreria fornisce una serie di estensioni a NET 3.5 per supportare in modo nativo una serie di costutti paralleli. Vedi articolo su MSDN Magazine.

martedì, gennaio 08, 2008

Typed dataset: consigli e tips

L'utilizzo dei typed dataset in Visual Studio 2005 semplifica e velocizza molto la scrittura di codice per l'accesso ai dati, quello che comunemente viene chiamato DAL (Data Access Layer). Ma i problemi sono dietro l'angolo....

Vedi: http://docs.google.com/Doc?id=dchmct9k_152cj9qfgdm

Come al solito, i commenti sono i benvenuti.

domenica, gennaio 06, 2008

compilation debug="true"

In web.config, tra le altre cose, c'è la modalità di compilazione. Durante lo sviluppo dovrebbe essere impostata a true: <compilation debug="true" />
Ma quando si porta l'applicazione in produzione, è importante ricordarsi di impostarla a false.
Questo per una lunga serie di motivi:
  • timeout: con true le pagine asp.net non vanno mai in timeout. Ottimo per il debug, disastroso in produzione.
  • compilazione batch: compilazioni più lenta con true.
  • ottimizzazione del codice: se true, non c'è ottimizzazione del codice. Performance peggiori.
  • utilizzo memoria: maggiore utilizzo di memoria con true
  • ... altri motivi
Attenzione: l'opzione di debug di compilation all'interno di web.config, non è la stessa cosa dell'opzione debug/release di Visual Studio. La prima ha effetto sulla compilazione "al volo" di asp.net e su come l'applicazione asp.net è eseguita da IIS (vedi timeout). La seconda invece ha effetto sulle dll compilate da Visual Studio.


Per maggiori info (in inglese):

Fiddler and Visual Studio 2005

There are some problem using Fiddler with Visual Studio 2005 Development Server (Cassini). In particular if you're using IE7 and Vista.
On many blogs there are many workarounds and tips. The only that works with me is to add a new entry in the HOSTS file (C:\Windows\System32\drivers\etc). In my case, I added:
127.0.0.1 myself
Now, the url in Ie7 will be http://myself:51784/page.aspx. It works both with and without Fiddler runnig.

mercoledì, gennaio 02, 2008

GridView, UpdatePanel e doppi click

Su vari post ho letto di persone che hanno problemi con GridView contenute in UpdatePanel Ajax.
Anche io ho trovato vari problemi. Il più strano è la necessità di premere 2 volte i linkbutton perchè questi facciano il loro lavoro. In realtà il postback avviene 2 volte ma la prima volta sembra andare perduto. La seconda volta funziona.
Facendo un po' di ricerche e di debug sembra che il primo post venga gestito come un"postback ajax" (passatemi questo termine) mentre il secondo è un trattato come un vero postback.
La soluzione che ho trovato è quello di registrare la GridView nella collezione dei Trigger del UpdatePanel che la contiene. Il trigger deve essere un PostBack e non un AsyncPostBack. In questo modo LinkButton tornano a funzionare al primo colpo.


<asp:updatepanel id="updtPnl" runat="server" updatemode="Conditional">
<contenttemplate>
<asp:gridview id="GV1">
.....
<asp:gridview>
</contenttemplate>
<triggers>
<asp:PostBackTrigger ControlID="GV1" />
<triggers>
<asp:updatepanel>


Anche la documentazione ufficiale relativa a PostBackTrigger sembra confermare questo uso. Non capisco però perchè funzioni con click in sequenza. Boh...


Probabilemente i problemi sono dovuti anche alla struttura abbastanza annidata dei componenti della mia pagina asp.net. In successione i "contenitori" sono:
- master page
- content page
- multiview
- view
- updatepanel
- gridview
- linkbutton (o imagebutton)


Sinceramente non ho fatto prove con una struttura più semplice. Appena trovo 10 minuti...