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

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:
Quando l'UpdatePanel non fa l'AsyncPostBack...

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

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' smile_teeth

2 Comments Filed Under [ ASP.NET 2.0 ]
Multithreading su Aspitalia.com

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: , ,
4 Comments Filed Under [ .Net 2.0 ASP.NET 2.0 ]
Viewstate e controlli dinamici

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):

  1. Init
  2. LoadViewState
  3. Load
  4. 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:
5 Comments Filed Under [ ASP.NET 2.0 ]
Se passate in QueryString dati codificati Base64...

...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:
One Comment Filed Under [ ASP.NET 2.0 ]
[FIX] Ancora a proposito di VS2005 e debug su IIS7

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 smile_teeth

 

Technorati tags: ,
Un bug veramente noioso di wsdl.exe

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)
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
6 Comments Filed Under [ .Net 2.0 ASP.NET 2.0 ]
WebServices su HTTPS

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

  1. installare Windows Vista Beta 2 (perché io sono tra i comuni mortali che per il momento non hanno a disposizione un abbonamento MSDN)
  2. 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

powered by IMHO 1.3

Add Comment Filed Under [ .Net 2.0 ASP.NET 2.0 ]
Stanchi di Javascript? Provate Script#

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!

powered by IMHO 1.3

One Comment Filed Under [ .Net 2.0 ASP.NET 2.0 ]