Month: April 2011

ASP.NET : TextBox e l’attributo EnableViewState = false

Come sappiamo, il protocollo HTTP è di tipo state-less, ossia senza stato. Ciò vuol dire che non è possibile mantenere delle informazioni di stato tra una richiesta e l’altra, cioè ciascuna richiesta è completamente indipendente dalla precedente.

Con ASP.NET è stato introdotto il meccanismo del ViewState per superare questo limite. Oltre a poter essere abilitato o disabilitato a livello di pagina, è possibile anche gestirlo a livello di singolo controllo attraverso l’attributo EnableViewState.

Ci sono, però, alcuni controlli per i quali, pur settando EnableViewState = false, il loro valore viene mantenuto in seguito ad un Postback. Uno di questi è la semplicissima TextBox. Come è possibile ciò ?

Consideriamo una pagina aspx nella quale abbiamo una TextBox ed un Button.

<asp:TextBox ID="MyTextBox" runat="server" EnableViewState="false"/>
<asp:Button ID="MyButton" runat="server" Text="Click" onclick="MyButton_Click" />

Osserviamo che ho volutamente settato EnableViewState = false per il controllo TextBox. Se visualizziamo la pagina per la prima volta, avremo il seguente risultato.

4520.aspnet_viewstate1_4EBC81F0

Sino a qui non c’è nulla di strano; proviamo però a digitare del testo nella TextBox e cliccare sul bottone in modo da eseguire un Postback alla pagina. Pur non avendo abilitato l’uso delViewState sulla TextBox, il risultato sarà il seguente.

8054.aspnet_viewstate2_53BEBF9F

Come è possibile ciò ? In che modo lo stato del controllo è stato mantenuto pur avendo disabilitato la gestione del ViewState ?

Ebbene, la risposta è semplice; il controllo TextBox fa parte di un gruppo di controlli che implementano l’interfaccia IPostBackDataHandler e per i quali il valore immesso dall’utente viene trasferito attraverso l’header HTTP della richiesta POST al server e non viene immesso nel valore del campo hidden __VIEWSTATE.

Per rendercene conto, consideriamo una parte dell’HTML della pagina appena visualizzata…

<div class="aspNetHidden">
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUJNDQ4MjgxMTgxZGTNOC5r+KAS/pEPhvuwtdjw6Xg+DdjKydHf4P3AT9X6Rw==" />
</div>

<div class="aspNetHidden">

    <input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" value="/wEWAwKy+bGFCQL1vtaTBwK4ooke2vLPwEEWgJUPhhabX+TyTbj9KOi3hO+pZVItu7X/OoU=" />
</div>
    <div>
        <input name="MyTextBox" type="text" value="Paolo" id="MyTextBox" />
        <input type="submit" name="MyButton" value="Click" id="MyButton" />

…ed utilizzando Wireshark, analizziamo il contenuto della richiesta HTTP POST eseguita verso il server al momento del Postback.

1385.aspnet_viewstate3_7CE657DD

Come si può osservare, al server viene trasmesso il valore del __VIEWSTATE ed a parte il valore immesso nella TextBox come un normale campo INPUT di una form.

In realtà, però, la proprietà Text della classe TextBox è implementata nel modo seguente.

public string Text
{
 get
 {
  string text=(string)ViewState["Text"];
  return (text==null)? String.Empty : text;
 }
 set
 {
  ViewState["Text"]=value;
 }
}

Ciò vuol dire che in fase di salvataggio e caricamento del valore di Text, comunque viene utilizzato il ViewState, indipendentemente dal fatto che esso sia abilitato o meno. Inoltre, laTextBox implementa il metodo LoadPostData dell’interfaccia IPostBackDataHandler attraverso il quale carica il valore immesso ricavandolo dalla collection dei dati post della form.

bool IPostBackDataHandler.LoadPostData(string postDataKey, 
                                   NameValueCollection postCollection)
{
    // recupera il valore dal ViewState
    string text1 = this.Text;
    // recupera il valore dalla collection post della form
    string text2 = postCollection[postDataKey];
 
    if (!text1.Equals(text2))
    {
        this.Text = text2;
        return true;
    }
    
    return false;
}

Advertisements

Windows CE 6.0 R3 Build System Series – 8. cebuild.bat e sysgen.bat : il cuore del build

Con questo articolo si conclude l’analisi approfondita dei tool che costituiscono il sistema di build, rimandando altri eventuali approfondimenti alla documentazione ufficiale Microsoft su Windows CE 6.0 R3.

Non ci resta che analizzare i tool che costituiscono il cuore del sistema di build, ossia ilcebuild.bat ed il sysgen.bat che sono strettamente correlati tra loro, in quanto il primo invoca più volte il secondo per eseguire le fasi di Sysgen prima e Build poi. Per questo motivo, l’analisi è riferita principalmente al cebuild.

Sysgen

In primo luogo essa cancella tutti i file di log (build.log, build.wrn e build.err) che vengono creati nella %_WINCEROOT% ed esegue il parsing degli argomenti ricevuti dal blddemo.bat, attraverso i quali setta le seguenti variabili :

  • parametro –r –> WINCEREL;
  • parametro ––> __QBLDLOCAL = 1;
  • parametro –q –> __QBLDQUICK = 1;
  • parametro –c –> __QBLDCLEAN = –c;
  • parametro –d<deptree_entry> –> costruisce la __QBLDNEWDEPTREES a partire dalla _DEPTREES;
  • parametro –qbsp –> __QBLDQUICKBSP = 1 (esegue il build e sysgen solo della BSP e non dell’intero _DEPTREES);

Se la __QBLDQUICKBSP non è stata settata, deve essere eseguita la fase di Sysgen sull’intero _DEPTREES e viene invocato ciclicamente il cebldtree.bat per ogni directory presente nel _DEPTREES. A partire dal cebldtree, viene lanciato il build.exe per eseguire la compilazione, se necessario, dei componenti delle directory PRIVATE e PUBLIC.

1258.cebuild2_5DC72E7D

Successivamente viene invocato il sysgen.bat, il quale attraverso l’utilizzo al suo interno delcesysgen.bat permette l’esecuzione del file .bat associato al progetto della directory del _DEPTREES ricevuta in ingresso, in modo che vengano settate le Sysgen Variable corrispondenti.

7206.cebuild1_697C75AF

Post-Sysgen Buld (BSP e Subproject)

Al termine della fase di Sysgen per tutti i progetti del _DEPTRESS, si passa alla fase di build della BSP e dei sottoprogetti eseguita allo stesso modo.

Viene invocato il SysgenPlatform fornendo come parametro la %_TARGETPLATROOT% e successivamente il build.exe per eseguire la compilazione dei componenti della BSP.

Inoltre, per ogni sottoprogetto dell’OS Design viene lanciato il ProjSysgen.bat. L’elenco dei sottoprogetti sui cui eseguire tale azione è descritto attraverso la variabile %_USER_SYSGEN_BAT_FILES, definita in fase di inizializzazione del sistema di build.

Infine, come estensione del processo di build, viene verificata l’esistenza di un eventuale codice sorgente custom e quindi compilato.

5141.cebuild3_7AECD687

Windows Embedded CE 6.0 R3 QFEs : Marzo 2011

Sono stati rilasciati i QFEs di Marzo 2011 per Windows Embedded CE 6.0 R3 e sono scaricabili al seguente indirizzo :

Windows Embedded CE 6.0 Monthly Update March 2011

Riporto di seguito i principali fix, come descritto nel file allegato al download :

Component:  COMM

  • 110325_KB2514361 – GetHostByAddr function may return incorrect WINS server name.

Component: Core GWES

  • 110310_KB2507166 – MS Mincho font is not available without the AC3FontCompression technology.
  • 110310_KB2506662 – This update addresses some font issues with ClearType option enabled.

Component: CoreOS

  • 110310_KB2498860 – A hang may occur upon detaching USB devices.

Component: Drivers

  • 110331_KB2519657 – This update addresses an issue with FAL inserting free sectors twice into its internal “free sector list”.

Component: FSD

  • 110318_KB2516401 – Windows Embedded CE 6.0 may not be able to read the CD if it contains invalid volume descriptors for UDFS file system.

Component: FSDMGR

  • 110329_KB2516902 – This update addresses memory leak.

Component: Internet Explorer

  • 110314_KB2492878 – This update addresses an issue in Internet Explorer.
  • 110315_KB2514454 – Internet Explorer may not display a multi-byte character correctly.
  • 110303_KB2475284 – This update addresses an issue with File_Print menu not working correctly.

Component: Kernel

  • 110321_KB2514264 – This update addressess a possible deadlock issue.

Component: MSFlash

  • 110310_KB2504074 – The Transaction Log recovery process in the FlashMDD may not handle bad log blocks correctly. This may result in premature failure of the recovery process.

Component: Pictor

  • 110311_KB2475955 – This update allows OEMs to enable/disable the resolution change.

Component: SOURCE

  • 110331_KBSOURCE – This release installs updated source files.

Component: TCP/IP

  • 110315_KB2509871 – This update addresses an issue with accessing file share when using ethernet card that uses hardware checksums.

Component: TimeSVC

  • 110302_KB2491392 – SetSystemTime may set the system time incorrectly.

Windows CE 6.0 R3 Build System Series – 7. Blddemo.bat : il “coordinatore” del sistema di build

Il sistema di build è costituito da una serie di tool e di script che sono coordinati da un unico file batch : il blddemo.bat. A seguito dell’inizializzazione del sistema, come visto nell’articolo precedente, la compilazione vera e propria dell’immagine viene avviata lanciando quest’ultimo che ha il compito di invocare in sequenza tutti i tool e gli script necessari per eseguire le quattro note fasi.

In primo luogo, è importante sapere che esso prevede alcuni parametri in ingresso, attraverso i quali ne è possibile modificare il comportamento. E’ altresì importante essere a conoscenza del fatto che invocare il blddemo senza parametri, determina l’esecuzione di tutte le fasi tra cui anche la prima, ossia la Pre-Sysgen, che esegue la compilazione delle directory PRIVATE e PUBLIC non necessarie. E’ tipicamente raro e caldamente sconsigliato lanciare il blddemo in questa modalità.

La generica riga di comando per la sua invocazione è la seguente :

BldDemo [[no]clean] [[no]cleanplat] [nuke] [norel] [Params for CEBUILD]

Osserviamo che, alcuni parametri sono specifici per il blddemo mentre altri sono destinati al batch cebuild.bat che è considerato il Master Build Tool e che viene invocato dallo stesso blddemo al suo interno.

La prima parte dei parametri, specifici per il blddemo, hanno il seguente significato :

  • clean : indica se eseguire una pulizia o meno delle directory %_PROJECTROOT%\cesysgen e %_PLATFORMROOT%\cesysgen che contengono i componenti del sistema operativo e della BSP filtrati attraverso la fase di Sysgen precedente;
  • noclean : non esegue il clean del punto precedente;
  • cleanplat : simile al clean ma ripulisce la cartella %_PLATFORMROOT%\target che contiene i componenti buildati della BSP (librerie ed eseguibili);
  • nocleanplat : non esegue il clean del punto precedente;
  • nuke : permette la ricerca del batch BldNuke.bat nelle cartelle %_PROJECTROOT% e %_PRIVATEROOT%\bat ed eventualmente la sua esecuzione;
  • norel : richiede esplicitamente di non eseguire la fase di Build Release Directory;
  • nomakeimg : non permette l’esecuzione della fase di Make Run-Time Image;
  • rel : esplicita la richiesta di esecuzione della fase di Build Release Directory;
  • Params for CEBUILD : una sequenza di parametri che saranno passati al file cebuild.bat che viene invocato all’interno del blddemo stesso. Tipici valori sono –q per un “quick” build, ossia senza la fase di Pre-Sysgen; –qbsp ossia un “quick” build ma esclusivamente sulla BSP;

Di seguito, riporto alcune tipiche modalità di esecuzione del blddemo :

  • blddemo clean : prima di avviare il build, viene eseguito un clean delle directory relative ad una compilazione precedente. In particolare, vengono ripulite la %_PROJECTROOT%\cesysgen e %_PLATFORMROOT%\cesysgen che come sappiamo contengono le librerie ed i file eseguibili filtrati sulla base dei componenti selezionati nell’OS design. A seguito del clean, parte la generazione dell’immagine dalla fase di Pre-Sysgen e quindi viene eseguita una compilazione completa includendo anche il codice in PUBLIC e PRIVATE;
  • blddemo –q : la “q” sta per “quick” ed è l’opzione più tipica, in quanto la compilazione parte dalla fase di Sysgen;
  • blddemo –qbsp : alla configurazione precedente viene aggiunta l’opzione “bsp” attraverso la quale si parte direttamente dalla fase di Sysgen e Build della sola BSP;
  • blddemo clean –q : esegue una pulizia prima di avviare l’esecuzione “quick”;

Passiamo ora alle operazioni eseguite al suo interno.

In primo luogo, verifica se esiste ed eventualmente lancia il file pblddemo.bat che lo sviluppatore può creare per customizzare il processo di build.

6518.blddemo1_492B0534

Subito dopo, viene eseguito il parsing dei parametri forniti in ingresso e sulla base di essi vengono settate le seguenti variabili :

  • clean / noclean –> _BLDDEMO_CLEAN = 1 (o vuoto);
  • cleanplat / nocleanplat –> _BLDDEMO_CLEANPLAT = 1 (o vuoto);
  • nuke –> _BLDDEMO_NUKE = 1;
  • norel / rel –> _BLDDEMO_NOREL = 1 (o vuoto);
  • nomakeimg / makeimg –> _BLDDEMO_NOMAKEIMG = 1 (o vuoto);

Se _BLDDEMO_NUKE = 1 viene invocato il BldNuke.bat, il cui scopo è poco  chiaro ma si presume che possa essere usato come “arma nucleare” (nuke) per un build completo dell’immagine.

0743.blddemo2_393BC070

Se è richiesto un clean attraverso le variabili _BLDDEMO_CLEAN = 1 e/o _BLDDEMO_CLEANPLAT = 1, viene eseguita tale operazione di pulizia.

5428.blddemo3_38635A86

Vengono anche cancellati eventuali vecchi file batch relativi alle Pre e Post Custom Build Actions che possono essere definite nelle proprietà dell’OS Design. Allo stesso modo, eventuali Pre e Post Sysgen Actions relative ai sottoprogetti.

0755.blddemo4_0BDA2AA0

Viene invocato il pbxmlutils che permette di riprodurre un ambiente di build da linea di comando in relazione a tutto ciò che settiamo attraverso la UI di Platform Builder e che viene aggiunto all’interno del file pbxml del nostro OS Design. In pratica, questo tool è in grado di leggere le impostazioni del file <MyOSDesign>.pbxml.

Successivamente, vengono invocati i file batch relativi all’esecuzione delle Pre-Sysgen Custom Build Actions e Pre-Sysgen Subproject Build Actions, ossia tutto ciò che precede la fase di Sysgen.

A questo punto, viene lanciato il cebuild.bat passandogli tutti i parametri ricevuti in ingresso :

2337.blddemo5_0F0C1288

Come vedremo negli articoli successivi, questo è il batch che si occuperà di eseguire le fasi principali di Sysgen e Build BSP.

Al termine dell’esecuzione del cebuild, viene verificata l’eventuale presenza del file build.errnella %_WINCEROOT% il quale indica il fatto che ci sono stati degli errori durante le fasi di Sysgen e/o Build BSP, per cui l’esecuzione del blddemo viene interrotta.

Se non si sono verificati errori, vengono invocati i batch relativi alle Post-Sysgen Custom Build Actions e Post-Sysgen Subproject Build Actions, quindi ciò che è postumo al Sysgen.

A questo punto è possibile proseguire con le due ultime fasi; viene invocato il buildrel.batse la variabile _BLDDEMO_NOREL non è stata settata…

3288.blddemo6_4A5F7846

… ed il makeimg.exe se la _BLDDEMO_NOMAKEIMG non è stata settata.

6232.blddemo7_08E4C5ED

A questo punto viene creato il log con l’insieme di tutti i settaggi della fase di Sysgen nel fileSysgenSettings.out e viene visualizzato il log makeimg.out generato dal makeimg (solo se la environment variable BLDDEMO_MI_LOG non è stata settata).

Infine, se la variabile MAKEIMG_MI_LOG risulta uguale a “imageupdate”, viene eseguito il comando “dir” sul file NK.bin generato, per visualizzarne le informazioni.

7875.blddemo8_5A1F0D4A

Windows CE 6.0 R3 Build System Series – 6. Inizializzazione del sistema di build : PBInitEnv.bat e wince.bat

Come già descritto negli articoli precedenti, il sistema di build deve essere correttamente inizializzato per poter essere utilizzato al fine della compilazione di un’immagine di Windows CE. Tale inizializzazione consiste nel setting di una serie di Sysgen Variable ed Environment Variable, che viene eseguita mediante due specifici file batch, il PBInitEnv.bat ed ilwince.bat (quest’ultimo invocato durante l’esecuzione del primo).

Di seguito, descriverò le principali operazioni eseguite da ciascuno di essi.

PBInitEnv.bat

Tale file batch è reperibile al percorso %_PROJECTROOT% ed il suo scopo è quello di settare le principali Environment Variable, nonchè le Sysgen Variable associate ai componenti selezionati nel Catalog Items e quelle relative alla BSP per i driver inclusi nell’immagine. Tale file viene sempre modificato ogni qual volta aggiungiamo/rimuoviamo componenti dall’immagine, perché a tali azioni corrisponde il set o meno di una variabile.

Inizialmente, esso setta alcune Environment Variable di tipo generico tra le quali la _WINCEROOT, _FLATRELEASEDIR, _PROJECTROOT. E’ da sottolineare che ogni qual volta utilizziamo una configurazione di build differente (Release, Debug oppure una nuova configurazione derivata da esse), la _FLATRELEASEDIR cambia (a meno che non la definiamo noi forzatamente sempre uguale attraverso le proprietà del progetto) per cui il PBInitEnv.bat viene modificato.

5481.pbinitenv1_38D56F89

Dove MyOSDesign è il nome del progetto sul quale stiamo lavorando e MyPlatform è la corrispondete BSP.

Successivamente viene invocato il wince.bat al quale vengono passati i tre seguenti parametri :

  • target cpu : indica la CPU target (nel nostro caso è ARMV4I);
  • project : indica il progetto del sistema operativo (nel nostro caso è MyOSDesign);
  • platform : indica la BSP del target device (nel nostro caso è MyPlatform);

6523.pbinitenv2_76825745

Al termine dell’esecuzione del wince.bat, vengono ripulite tutte le variabili relative alle impostazioni dell’immagine (le IMG_XXX ed IMGNO_XXX) ossia quelle che sono settate attraverso le “Build Options”.

6786.pbinitenv3_0A9B73CF

Inoltre, vengono settate tutte le Sysgen Variable (SYSGEN_XXX) e le BSP Variable (BSP_XXX, BSPNO_XXX) relative rispettivamente ai componenti ed ai driver selezionati attraverso il Catalog Items.

5040.pbinitenv4_29DE1AA2

8836.pbinitenv5_503FFDED

Viene settata la variabile WINCEDEBUG che indica la configurazione di build correntemente utilizzata (debug/retail) e tutte le variabile che lo sviluppatore può aver impostato manualmente attraverso la scheda “Environment Variables” nelle proprietà del progetto.

2086.pbinitenv6_0F9DB17E

Inoltre, vengono settate tutte le variabili relative alle impostazioni dell’immagine (le IMG_XXX ed IMGNO_XXX) ossia quelle che sono definite attraverso le “Build Options”.

Successivamente, viene impostata la variabile _USER_SYSGEN_BAT_FILES, come un elenco di tutti file batch ProjSysgen.bat associati ai sottoprogetti inclusi nell’OS Design. Tali file batch saranno lanciati successivamente dal cesysgen.bat, per eseguire il Sysgen sui sottoprogetti.

Infine, vengono impostate le variabili relative alla localizzazione, anche in questo caso definite attraverso la scheda “Locale” delle proprietà del progetto.

8322.pbinitenv7_00F30599

wince.bat

Si trova al percorso %_PUBLICROOT%\COMMON\OAK\MISC e viene invocato dal PBInitEnv.bat per proseguire l’inizializzazione dell’ambiente di build e soprattutto per settare il _DEPTREES, la variabile che conterrà l’elenco delle cartelle sulle quali eseguire le operazioni di Sysgen e Build.

Come anticipato nel paragrafo precedente, esso riceve in ingresso i tre seguenti parametri :

  • target cpu : indica la CPU target (nel nostro caso è ARMV4I);
  • project : indica il progetto del sistema operativo (nel nostro caso è MyOSDesign);
  • platform : indica la BSP del target device (nel nostro caso è MyPlatform);

In prima istanza, setta tutte le directory root principali, quali _PUBLICROOT, _PRIVATEROOT, _PLATFORMROOT, _MAKEENVROOT (dove si trovano tutti i file batch) e così via.

Estraendo i tre parametri ricevuti in ingresso, inizializza correttamente le variabili _TGTCPU, _TGTPROJ e _TGTPLAT e ne esegue un processo di validazione.

7827.wince1_1982A2E9

Esse corrispondono rispettivamente a “target cpu”, “project” e “platform”. E’ da osservare che per ricavare ciascun parametro, viene utilizzato sempre l’accumulatore %1 ma grazie all’operazione di shift, ciascun parametro rimanente viene spostato in tale accumulatore (shiftando appunto verso sinistra).

Eseguendo il parsing su tali variabili, vengono settate la _TGTCPUFAMILY e _TGTCPUISA.

0410.wince2_06CDA932

A questo punto, viene settata la _PROJECTROOT ma soprattutto, se esiste, viene invocato il batch file a livello di progetto %_TGTPROJ%.bat, se è stato creato dallo sviluppatore per poter settare altre eventuali variabili di ambiente personalizzate.

3733.wince3_3139DA4F

Successivamente, viene costruita una delle variabili principali del sistema di build, ossia la _DEPTREES che contiene tutte le cartelle nell’ambito delle quali saranno eseguite le operazioni di Sysgen e di Build successive.

Alla _DEPTREES vengono aggiunte sia le cartelle nella _PUBLICROOT …

0003.wince4_3780B0DD

… sia quella relativa al progetto.

4722.wince6_2F890E7B

Successivamente, viene settata la variabile PATH di Windows con i percorsi dei vari tool che saranno utilizzati dal sistema di build e viene invocato il %_TARGETPLATROOT%\%_TGTPLAT%.BAT che ha il compito di settare una serie di BSP Variable strettamente legate alla platform e non necessariamente in relazione con l’OS Design.

6378.wince5_5D0A2E3E

Infine, se esistenti, vengono lanciati una serie di file batch opzionali che permettono una customizzazione dell’ambiente di build. Alcuni esempi sono :

  • setenv.bat : esegue delle operazioni di inizializzazione private definite dallo sviluppatore (%_WINCEROOT%\developr\%USERNAME%\setenv.bat);
  • postWinCE.bat : esegue delle inizializzazioni eventualmente necessarie e specifiche per i sottoprogetti dell’OS Design (%_PROJECTROOT%\postWinCE.bat);

7144.wince7_557EBED1

WP7 : update NoDo arrivato !! LG-E900 aggiornato !!

Finalmente dopo tanta attesa e senza alcun pesce d’Aprile, proprio oggi pomeriggio ho collegato il mio LG900 al PC attraverso Zune ed ho ricevuto la notifica della disponibilità dell’aggiornamento…ovviamente….NoDo !!

Aggiornamento eseguito senza alcun problema ed ecco il risultato.

5141.wp7_nodo1_010C88CF

La versione SO è passata alla 7.0.7390.0 (dopo il preupdate era 7.0.7008.0) ed è possibile anche vedere il MAC e l’ID della SIM.

La tanto attesa funzionalità di copia/incolla è nelle immagini seguenti.

2211.wp7_copiaincolla1_39A70D0F

6663.wp7_copiaincolla2_7B11999B

Osserviamo, evidenziate in rosso, le icone che compaiono nella fase di Copia (dopo aver selezionato un testo) e nella fase di Incolla (quando il cursore è all’interno di una textbox).

A questo punto non ci resta che scoprire il resto….