ASP.NET 2.0

Forzare la rigenerazione del file .designer.cs in ASP.NET

Marco De Sanctis — Tue, 18 Dec 2007 16:05:15 GMT

In Visual Studio 2005 accade a volte che il file .designer.cs non venga correttamente generato con i controlli contenuti nel markup della pagina.

La memoria è corta, quindi me lo segno qui sul blog: per forzarne una rigenerazione, è sufficiente eliminare il file .designer.cs e poi fare tasto-dx sulla pagina, Convert to Web Application.

Technorati tags: ASP.NET

Quando l'UpdatePanel non fa l'AsyncPostBack...

Marco De Sanctis — Fri, 19 Oct 2007 23:12:12 GMT

...potreste aver dimenticato di assegnare l'ID al vostro LinkButton

Giuro che questa mi ha fatto veramente impazzire, ma è così, provare per credere!!

Ma io mica mi fermo qui! Perchè, dannazione??

Il PageRequestManager, ad ogni postback, utilizza l'argomento eventTarget della funzione __doPostback per determinare qual è il controllo che ha richiesto il submit e discriminare se eseguire una chiamata out-of-band (ad es. se il controllo si trova dentro ad un UpdatePanel) o meno.

Ottimo, ma ovviamente ha bisogno di recuperare un'istanza per capire in che posizione del DOM si trovi. Come fa?

var controllo = document.getElementById('....');

Ma... attenzione: se non assegnamo l'ID al LinkButton, ASP.NET emette il seguente markup:

<a href="javascript:__doPostBack('ctl03','')">Btn without Id</a>

Sfido chiunque a ritrovare questo tag cercando l'elemento con id='ctl03'

Technorati tags: ASP.NET, AJAX, UpdatePanel, PageRequestManager

Multithreading su Aspitalia.com

Marco De Sanctis — Tue, 16 Oct 2007 08:04:25 GMT

Dopo il mio precedente lavoro su NHibernate, oggi Aspitalia.com ha pubblicato un mio nuovo articolo sul multithreading.

Grazie mille a Daniele per lo spazio che mi ha concesso e a Ricky per la pazienza nel correggerlo!

Technorati tags: Articoli, Multithreading, ASP.NET

Viewstate e controlli dinamici

Marco De Sanctis — Wed, 16 May 2007 14:27:00 GMT

Volevo rispondere a questo post di Gian Maria, poi il testo era un po' lungo e allora ho optato per la modalità stand alone :D

Anche in ASP.NET 2.0, come accadeva nella 1.1, è necessario ricreare controlli dinamici durante la fase di Init al fine di preservare correttamente il viewstate. La ragione risiede nel fatto che il ripristino dello stato dei controlli avviene in maniera posizionale. Consideriamo una pagina con una DropDownList (il cui contenuto è ripristinato tramite Viewstate) e il seguente snippet di codice, che aggiunge un button prima della ddl stessa:

protected void Page_Load(object sender, EventArgs e)
{
    this.form1.Controls.AddAt(0, new Button());
    if (!IsPostBack)
    {
        ddlTest.DataSource = getDataSource();
        ddlTest.DataBind();
    }
}

Se analizziamo il ciclo di vita della pagina, ad esempio attivando il trace, notiamo che l'ordine degli eventi è il seguente (ho volutamente omesso tutto ciò che non interessa questo discorso):

Init
LoadViewState
Load
SaveViewState

Bene. Visualizziamo nel browser la nostra pagina, LoadViewState non viene sollevato perché non siamo in un postback, Load costruisce il button dinamico, SaveViewState salva lo stato di un albero di oggetti che, grossomodo è

Button
DropDownList

Supponiamo di effettuare un postback. Cosa accade?

LoadViewState prova a ripristinare lo stato del Button, ma questo ancora non esiste: l'evento Load ancora non si è verificato e l'albero degli oggetti ora è composto dalla sola DropDownList! Il risultato è che LoadViewState invierà i dati del Button al metodo LoadViewState della DropDownList, che ovviamente non sarà in grado di ripristinare correttamente lo stato, proponendoci nel postback una DropDownList vuota.

Creando il button in fase di Init, invece, il problema non si pone, dato che LoadViewState opera in un contesto coerente con quello in cui è stato eseguito il SaveViewState al precedente rendering della pagina.

EDIT: quanto segue è frutto di uno sforzo congiunto da parte mia e del buon Alk :)

In ASP.NET 2.0 (devo verificare cosa accade su 1.1) in realtà è comunque possibile aggiungere controlli dinamici in una fase successiva al LoadViewState: basta utilizzare un placeholder o un qualunque altro controllo contenitore. Come è possibile?

In fase di postback, la Form ripartisce di nuovo il viewstate tra i suoi controlli di primo livello, al PlaceHolder va una porzione di albero e alla DDL un'altra. Quest'ultima, quindi, non si accorge minimamente dell'esistenza di controlli dinamici, riceve dati corretti e può quindi ripristinare il suo stato.

La cosa che sulle prime mi ha sbalordito, è che anche i controlli aggiunti in seguito nel placeholder conservano le informazioni di stato. Non mi spiegavo come ciò fosse possibile, dato che comunque essi vengono creati dopo la fase di LoadViewState. La risposta sta nella classe ControlCollection. Quando viene ripristinato lo stato, un oggetto Control effettua un caching della porzione di viewstate ad esso inviato dal suo contenitore. All'aggiunta di un controllo child

this.plcHolder.Controls.Add(new Button());

viene eseguito il metodo Control.AddedControl che, nel caso la cache interna del viewstate non sia vuota, forza un nuovo Load dello stato per il controllo child (eventualmente anche per Id e non più in base all'ordine).

Technorati tags: ASP.NET

Se passate in QueryString dati codificati Base64...

Marco De Sanctis — Mon, 30 Apr 2007 00:03:00 GMT

...ricordatevi di scrivere, prima della decodifica

string goodBase64string = 
    base64FromQueryString.Replace(" ", "+");

altrimenti potreste ritrovarvi una bella FormatException per "Invalid length for a Base-64 char array".

HTH

Technorati tags: ASP.NET

[FIX] Ancora a proposito di VS2005 e debug su IIS7

Marco De Sanctis — Sun, 22 Apr 2007 08:31:00 GMT

Nonostante avessi configurato correttamente la Windows Authentication, aperto Visual Studio con i privilegi elevati, ecc.ecc. di punto in bianco non sono riuscito più ad attivare il debug della mia applicazione con il classico F5:

Unable to start debugging on the Web Server. An authentication error occurred while communicating with the Web Server.

o qualcosa del genere.

Sono andato avanti un paio di giorni agganciandomi manualmente al processo w3wp.exe, poi stamattina ho trovato questo post che mi ha risolto il problema

Technorati tags: ASP.NET, Windows Vista

Un bug veramente noioso di wsdl.exe

Marco De Sanctis — Fri, 20 Apr 2007 09:05:00 GMT

Alcuni web service che sto realizzando, usano come parametri e valori di ritorno dei tipi che implementano l'interfaccia IXmlSerializable.

Il tool wsdl.exe utilizzato per generare i proxy per l'accesso lato client, ha un fastidioso bug descritto in questa KB: considera ogni tipo IXmlSerializable come se fosse un dataset e quindi produce metodi con signature errate.

L'aspetto più antipatico della questione è che, stando sempre a quanto scritto nella KB che ho linkato, non c'è soluzione se non quella di andare a cambiare a manina ogni metodo incriminato.

Uff, non vedo l'ora di migrare completamente a WCF!

Persistere il ViewState sul database (o dove ci pare)

Marco De Sanctis — Mon, 26 Jun 2006 22:27:00 GMT

Il viewstate di ASP.NET alle volte è una gran comodità, che però paghiamo in termini di prestazioni ad ogni postback, dato che un bel campo hidden di grandezza che a volte può essere considerevole, è costretto ad andare avanti e indietro tra client e server.

Click sul titolo per leggere

WebServices su HTTPS

Marco De Sanctis — Sun, 11 Jun 2006 23:26:00 GMT

Quella passata è stata una settimana a dir poco massacrante, in cui non ho avuto un solo attimo di respiro (weekend compreso). Per fortuna mi sono buttato alcuni impegni alle spalle e all'una e spiccioli di domenica sera ho finalmente il tempo per

installare Windows Vista Beta 2 (perché io sono tra i comuni mortali che per il momento non hanno a disposizione un abbonamento MSDN)
Bloggare un po'

Nelle attività che ho svolto ultimamente, mi sono ritrovato nella necessità di invocare un Web Service sotto https senza che il server avesse a disposizione un certificato riconosciuto (il tipico caso in cui, se navigassimo con il browser, beccheremmo un bel warning con dialog box che ci chiede se vogliamo proseguire o meno).

Se però stiamo accedendo ad un webservice da codice, ovviamente, non c'è nessuna dialog che ci proponga una qualche scelta, bensì l'invocazione risponde picche e solleva un'eccezione. Come ovviare? Ho trovato una risposta nel blog di Jan Tielens, ed è raggiungibile clickando qui

Stanchi di Javascript? Provate Script#

Marco De Sanctis — Tue, 23 May 2006 12:54:00 GMT

Premetto che non l'ho provato, provo a darci un'occhiata stasera, ma l'idea del bravo Nikhil Kothari mi intriga parecchio: un compilatore C# che invece di generare IL spara fuori del Javascript, con il vantaggio di avere a monte la possibilità di scrivere script lato client con un linguaggio Object Oriented, avere membri pubblici, privati, virtuali, interfacce, supporto per Intellisense e Refactoring di VS2005, ecc.ecc.ecc. Mica male!! Chissà come si comporta in quanto a compatibilità con i diversi browser!

BTW, trovate un piccolo articolo introduttivo, il download e anche un filmato a questo link!