December 2005 - Posts
Mii dite cosa fate ?
Oggi ci sono state 122 Aggregate View sui miei post di oggi e 169 web view...rilassatevi :-) e godetevi questi giorni di semi-ferie invece di leggere i miei post :-)
Scherzi a parte: Buon anno a tutti; che sia l'anno che volete...informatica a parte....
Auguroni
RoB
Gli Unit Test creati con VSTS consentono di dichiarare il fallimento dell'operazione andando a testare tramite la classe Assert i valori di ritorno di una chiamata a un metodo.
Spesso però il codice da testare potrebbe correttamente intercettare un'eccezione e scatenare un'eccezione applicativa. Un metodo di accesso ai dati ad esempio potrebbe intercettare un SqlException a fronte di problemi con il database e scatenare una DevLeap Exception che lo strato Biz o UI andrà a gestire. Ci sono due metodologie per testare correttamente la gestione delle eccezioni.
1) Nel metodo di Test si inserisce un Try/Catch e si agisce di conseguenza
Ad esempio potremmo fare questo
[TestMethod]
public void ListTest()
{
SalamiDal target = new SalamiDal();
try
{
target.List();
// Eventuali test con Assert.
}
catch (DevLeapException ex)
{
// Non fare niente: l'eccezione è stata correttamente scatenata
}
}
PS Prima che vi domandate perchè sto testando una roba che si chiama SalamiDal sappiate che si tratta di un'applicazione di Gestione Salumeria :-)
2) Il secondo metodo da usare su test molto specifico è indicare sul test tramite l'attributo ExpectedException l'eccezione che ci aspettiamo. Questa seconda strada evita la scrittura del blocco try/catch e fa sì che il test vada a buon fine solo se SalamiDal nel nostro caso scateni l'eccezione indicata.
Ad esempio il codice precedente potrebbe essere riscritto così:
[TestMethod]
[ExpectedException(typeof(SalamiManagement.Exceptions.DevLeapDBException))]
public void ListTest()
{
SalamiDal target = new SalamiDal();
try
{
target.List();
// Eventuali test con Assert.
}
catch (DevLeapException ex)
{
// Non fare niente: l'eccezione è stata correttamente scatenata
}
}
In questo caso il test da esito positivo se il metodo List di SalamiDal scatena un'eccezione di tipo SalamiManagement.Exceptions.DevLeapDBException. Con questa seconda modalità possiamo aspettarci una sola eccezione per ogni metodo di test, quindi il tutto è meno elastico rispetto al codice del primo esempio in cui potremmo intercettare diverse tipologie di eccezioni, scrivere costrutti condizionali per testare diverse cose.
Ultima nota: per testare ad esempio un fallimento di una Open di una DBConnection occorrerebbe modificare il file app.config del progetto test per poi riportarla ai valori corretti per testare il corretto funzionamento con la connessione corretta, oppure stoppare SQL Server, oppure negare l'accesso all'utente.
Visto che però i progetti VS non costano niente :-), perchè non creare un secondo progetto di test in cui inserire i test per gestire le eccezioni sul database: in questo modo avremmo sempre a disposizione sia il test che riesce a usare il db e il progetto che invece non riesce ad aprire la connessione. Sarà sufficiente indicare due connection string diverse nei due progetti e lanciando i test verificheremo entrambe le possibilità.
Personalmente creo sempre due progetti di test per ogni progetto da testare, il primo che testa il corretto funzionamento in condizioni normali, il secondo con un config volutamente sbagliato per testare le varie condizioni di gestione eccezioni.
La sequenza indicata deve essere rispettata scrupolosamente !!!
Installare XP SP 2 oppure Windows 2003 SP1 oppure Windows Vista (CTP di Dicembre..occhio)
Installare WinFX RTC: comprende i runtime binaries per eseguire applicazioni WinFX
Installare Visual Studio 2005 versione finale: va bene anche una versione Express
Installare il Windows SDK: comprende librerie, documentazione e esempi per lo sviluppo su WinFX.
Per l'integrazione con VS 2005 occorre poi installare "Visual Studio Code Name "Orcas" CTP WinFX Development Tools" che spesso viene chiamato anche Visual Studio 2005 Extensions for WinFX.
Per lavorare in VS 2005 su progetti di tipo Workflow occorrono anche le Visual Studio 2005 Extensions for Windows Workflow Foundation.
Spero di risparmiarvi un po' di tempo per capire i passi di installazione: dopo 11 ore di Setup sembra funzionare tutto su Windows Vista.
Nella December CTP di WinFx c'è per la prima volta una primissima versione di Cider, ovvero il designer per Windows Presentation Foundation (ex Avalon). La cosa carina è che funziona con la versione finale di Visual Studio 2005 e anche con la versione Express.
Si può installare su XP SP2, Windows 2003 SP1 e Windows Vista in versione December CTP.
In pratica da dicembre possiamo installare
WinFX RTC che consente di far girare le applicazioni WinFX
Visual Studio 2005 (anche Express)
Windows SDK
Visual Studio Extensions for WinFX (progetti e sample che si incastrano in VS)
Visual Studio Extensions for Windows Workflow Foundation
Sorry per l'informazione ritardata :-)
Sto testando il nuovo Web Migration Wizard (si veda il post http://blogs.devleap.com/rob/archive/2005/12/28/6427.aspx) sull'applicazione che usiamo come esempio nel nostro corso ASP.NET 1.x Core per portare alcuni degli esempi sul nuovo corso ASP.NET 2.x Core.
Ho notato due cosette:
Se in ASP.NET 1.x si caricava a runtime uno user control custom dal codice di una pagina:
Control userCtl = Page.LoadControl(
"UserControlCustom.ascx");
((UserControlCustom)userCtl).Titolo =
"Digita il tuo login";
phA.Controls.Add(userCtl);
Il cast verso UserControlCustom funge in quanto la classe è definita nel code-behind di UserControlCustom.ascx e quindi il buon Visual Studio 2003 compilava il tutto nel famoso assembly della cartella bin facendo si che a runtime si potesse usare la classe in quanto referenziata. In realtà sappiamo che VS 2003 compila tutti i file .vb o .cs presenti nel progetto nell'assembly binnato :-)
Con ASP.NET 2.0 il codice dei code-behind (pardon...code file) non viene più compilato da Visual Studio 2005; ci pensa ASP.NET 2.0 a runtime a compilare il tutto: qualunque cs o vb si trovi nella cartella app_code viene autocompilato a runtime. Tutti i file .cs/.vb delle classi definite nel progetto di un vecchio progetto vengono infatti portati giustamente nella cartella app_codice: i file dei code behind (ancora...CODE FILE...non mi abituerò mai ) vengono invece lasciati nella cartella del progetto accanto ai rispettivi aspx. Questo vale anche per il controllo usato nell'esempio UserControlCustom.ascx. Il suo codefile quindi non viene compilato dal runtime di ASP.NET 2.0 e di conseguenza non viene reso disponibile a runtime. Per ovviare al problema il wizard di migrazione inserisce l'attributo:
<%
@ Reference Control="~/UserControlCustom.ascx" %>
nella pagina che lo caricherà a runtime; il nuovo wizard in pratica analizza il codice del codebehind (stavolta è giusto) e aggiunge questa Reference nella pagina se trova qualche LoadControl nel codice. Tramite questa reference il runtime di ASP.NET 2.0 sa che la pagina utilizza (in realtà forse...visto che il codice del codefile potrebbe avere del codice condizionale e caricare il controllo solo in determinate circostanze) il controllo ascx e ne compila il code-file. Ottimo lavoro Wizard.
Vero ! Se intendiamo Progetti EXE/DLL che girano su device; diverso (e non in questo post) il ragionamento su applicazioni ASP.NET 2.0 Mobile per cui si applicano invece tutte le caratteristiche di VSTS per progetti ASP.NET 2.0.
1) I designer (Application Diagram, Logical DataCenter Diagram e di conseguenza Deployment Diagram) non hanno SDM specifici per client mobile e per device
2) Unit Testing impossibile su progetti mobile: il progetto di avvio degli Unit Test può essere solo un progetto Windows
3) Performance Session impossibili su progetti mobile: non è in grado di avviare un test (sampling, instrumentation) su un progetto mobile perchè non è in grado di girare su device
4) Code Coverage impossibile su progetti mobile: vedi sopra
Tra l'altro, più in generale, Team System non supporta progetti di tipo class library: da luglio 2005 utilizzo un workaround che dopo quasi 6 mesi mi sembra funzionare bene (mi ci trovo bene insomma) in attesa di una prossima versione che supporti progetti class library e progetti mobile.
Vi propongo la mia soluzione:
1) Nell'application diagram utilizzo un'applicazione Windows per definire l'exe: non implementandolo ovviamente altrimenti otteniamo un progetto windows :-)
Per i database SDF utilizzo un database normale come se niente fosse: non serve a molto ma fa capire meglio l'architettura generale. Ad esempio: http://thinkmobile.it/photos/application_diagram/images/4842/original.aspx
2) Nel Logical DataCenter Designer utilizzo un Windows Client per rappresentare il device con una connessione verso se stesso per bindare le connessione alle DLL dall'eseguibile. Ad esempio: http://thinkmobile.it/photos/application_diagram/images/4853/original.aspx: la connessione verso il device è rappresentata da DeviceClientComponentiEndPoint nella figura.
Ricordo :-) che nei miei progetti non scrivo mai più di una riga di codice negli eventi del form ma faccio tutto da una dll che gestisce l'interfaccia utente: chi è venuto a qualche nostra conferenza sa di cosa parlo. Dal 1997 consigliamo di sviluppare a componenti... che spesso ancora oggi sono validi e utilizzati.
3) Nel Deployment Diagram bindo l'exe e tutte le DLL relative sul Device che è rappresentato da un client windows. Il database viene legato comunque a un "database server" che rappresenta solo e esclusivamente l'sdf. Le connessioni da exe a dll e fra dll si legano alla connessione che nell'LDD punta verso lo stesso client.
Risolte le limitazioni dei designer, veniamo al vero problema: supporto per Unit Test, Performance Session, Stress Test
Una volta generata la struttura della soluzione mobile creo un progetto class library windows per ogni class library mobile che si chiama come il progetto mobile con il suffisso DeskTop. Ad esempio se la struttura della soluzione mobile è la seguente http://thinkmobile.it/photos/application_diagram/picture5081.aspx creo un progetto windows class library DevLeap.SQL2005MobilePerformance.Mobile.BIZ.DeskTop in cui link tutti i sorgenti del relativo progetto mobile. A questo punto è possibile creare Unit Test su tutti i metodi delle classi del progetto Biz.Desktop per eseguire appunto Unit Test su di essi. Visto che i sorgenti sono linkati, se durante il test riscontro errori posso correggere il codice del progetto BIZ.Desktop e ritestare: visto che il codice sorgente è linkato da Visual Studio sto correggendo in realtà anche il progetto mobile. Fregato VS 2005, risultato ottenuto con poco sforzo e senza dispersione dei sorgenti :-)
Stesso ragionamento applicato per le performance session: in questo caso sono validi tutti i dati sulle chiamate alle funzioni, sul call stack, sui tempi di eseguzione (da prendere in modo RELATIVO visto che girano sul desktop): ottimo per eseguire un test esattamente come si farebbe per applicazioni desktop. Ovviamente i dati su Garbage Collection e similari non vanno considerati visto che sul device saranno completamente diversi: ad esempio il .NET CF 2.0 esegue un GC se l'applicazione supera 1 Mb di RAM...cosa che sul desktop non è detto che succeda :-)
Visto che uno Unit Test può portarsi dietro i risultati del Code Coverage, il problema è risolto con questa semplice tecnica :-)
"Discorso diverso" si applica al test sull'accesso ai dati visto che sul device utilizzeremo un SDF...mentre sul desktop...un SDF lo stesso !
Per usare un SDF sul desktop seguite le mie indicazioni sul post di luglio 2005 che riporto per completezza:
Seguire queste operazioni semplici operazioni: portare nella bin questi file
sqlceme30.dll
sqlceoledb30.dll
sqlceqp30.dll
sqlcese30.dll
sqlceca30.dll
sqlcecompact30.dll
sqlceer30en.dll
System.Data.SqlServerCe.dll
Fare una reference all'ultima (facendo browse e prendendola dalla tua cartella bin e non da quella di VS 2005) e poi usa normalemente SQL 2005 Mobile sia per accesso locale che per replica.
Ma dai....il gioco è veramente fatto: abbiamo tutti gli elementi per lavorare con VSTS eliminando tutte le limitazioni della prima versione di un prodotto che a mio avviso è spettacolare così com'è !
Ricordarsi di non prendere i dati di performance in modo assoluto ma sempre in modo relativo da test a test e che da uno Unit Test si può creare uno Stress Test sul desktop, molto più comodo che usare Hopper fin dalle prime implementaioni del progetto mobile.
Hope useful.
Articolo introduttivo su ATLAS pubblicato su week.it nel settembre 2005 al ritorno dalla Microsoft PDC:
Los Angeles — Atlas è un framework per evitare Post dell’intera pagina eseguendo dietro le quinte le richieste delle informazioni necessarie e modificando solo le parti di pagina necessari. Rappresenta l’implementazione Microsoft di Ajax (Active Javascript And Xml). Non è il primo tentativo: nel ’95 prima di Asp (senza .Net) c’era Advanced Data Connector; poi c’è stato Dhtml fin da Internet Explorer 4.0 e nelle prime Beta di Asp.Net 1.0, SmartNavigation. Ma forse questa è la volta buona: queste tecnologie erano valide, soprattutto come teorie e sicuramente la seconda è ancora attuale, ma sono uscite troppo presto rispetto al supporto dei browser, alla loro «potenza» e alla connettività disponibile.
Veniamo al punto: il client scarica la libreria «Client Script Library» che contiene una serie di classi e funzionalità che in ultima battuta contattano la parte server che si installa sopra il motore di Asp.Net 2.0. Sul client possono risiedere anche servizi applicativi, per esempio uno store locale e funzionalità aggiuntive per il browser.
Il cuore di Atlas è in realtà un type system per Javascript che contiene classi, interfacce, metodi, enum e event-handler multicast simili a quanto conosciamo nella piattaforma .Net.
Le comunicazioni verso il server si basano su XmlHttp (WebRequest, WebResponse, MethodRequest) e passano attraverso Atlas Web Services Bridge che accede a sua volta a servizi Asmx e Wcf (Windows Communication Foundation o «Indigo»).
Il proxy lato client viene generato in automatico ed è ovviamente integrato con le funzionalità di Asp.Net come autenticazione, autorizzazione e caching: in pratica queste funzionalità diventano accessibili direttamente lato client. Il formato dei dati è Javascript Object Notation.
Per ogni Web service l’url xxx.asmx/js restituisce il Javascript per il lato client: viene autogenerato in base ai metodi esposti come webmethod dal Web service di riferimento e contiene il codice Javascript lato client che invocherà tali metodi.
Lato client sarà quindi sufficiente inserire il codice javascript che invoca le funzioni javascript autogenerate e aggiungere un paio di che puntano a AtalsCore.js (le funzionalità base) e appunto xxx.asmx/js. Se i metodi richiedono autenticazione occorre, poi, ovviamente anche creare l’interfaccia utente che richieda le credenziali all’utente e una funzione Javascript che invoca Web.Services.AuthenticationService.Login(); questa funzione è esposta dalle funzionalità core di Atlas (AtlasCore.js).
Atlas espone anche Web.Component e Web.UI.Control: i primi sono building block riutilizzabili, i secondi sono associati a Dhtml. I componenti si possono creare da codice (var txt1 = new Web.UI.TextBox(document.getElement(«txt1»)) partendo da un elemento Html presente nel form, oppure con una sintassi dichiarativa. Con la stessa tecnica (codice o dichiarazione) può essere «configurato» il binding di un controllo verso una sorgente dati.
L’alternativa è usare i nuovi controlli server-side Asp.Net ( Sul lato server è possibile creare classi che derivano dalla classe base DataService per definire i metodi Crud (create, read, update, delete) che lavorano sui dati che verranno invocati dai controlli che supportano il binding automatico.
Una volta definita la DataSource si possono usare controlli come I vari controlli supportano template per definire il layout da presentare all’utente. L’ultimo passo è definire in un file Xml quale metodo invocare sulla classe per ottenere i dati da legare al controllo sull’interfaccia utente.
Il binding può essere bidirezionale: occorre impostare la proprietà Direction=»InOut», e inserire pulsanti e codice script che invocherà i metodi server-side di update/delete ecc.
Una classe della libreria di base consente di eseguire il test sull’aggiornamento dei dati per evitare di eseguire l’update se non necessario e chiedere conferma all’utente non appena viene cliccato un hyperlink se alcuni dati sono stati modificati.
Per generare l’intefaccia di insermento è necessario, a parte comporre l’interfaccia utente, intercettare l’evento OnItemCreated che richiamerà il metodo server-side (sempre tramite il proxy) per eseguire l’inserimento ed eseguire un refresh della tabella Html nel caso la pagina presenti il set di record.
Una serie di controlli di validazione (simili ai Validation Control server-side) consentono d’eseguire controlli sui dati digitati dall’utente e inviare i corrispondenti messaggi di errori.
Per default viene usato un «Behavior» denominato AutoComplete che compone l’interfaccia utente nel modo classico.
Atlas supporta Css: si possono associare classi Css ai vari controlli per modificare il layout e la presentazione così come è possibile modificare il behavior per ottenere un comportamento totalmente diverso: per esempio si possono creare griglie floating all’interno della pagina per ottenere un risultato simile a quanto esiste già oggi in Asp.Net 2.0 con le Web Parts.
Dovrebbe essere chiaro, a questo punto, che possono essere salvate in ASP.Profile le modifiche all’interfaccia effettuate dall’utente: il meccanismo, rispetto alle Web Parts che interagiscono con Profile senza praticamente scrivere neanche una riga di codice, è abbastanza manuale in quanto occorre leggere le varie coordinate e passarle alla parte server, così come riposizionare «le cose» nel caso di refresh della pagina.
Se si deciderà di implementare Atlas (ci sono pareri molto discordanti sull’uso di Ajax) è ovvio che cambieranno la modalità (e i controlli) di presentazione dei dati: è consigliabile ancora una volta (è dal 1997 che lo ripetiamo) separare il codice della pagina rispetto alla logica applicativa inserendo, visto che siamo in .Net, questa ultima in classi esterne all’applicazione e richiamabili oggi da Asp.Net 2.0, domani da Asp.Net 2.0 con Atlas e, perché no, da client Windows Form e Avalon (anzi Windows Presentation Foundation).
Questo il post finale che comprende anche le Demo e le Slide di Marco Frontini:
http://thinkmobile.it/blogs/rob/archive/2005/12.aspx
Ho pubblicato slide e demo della Microsoft Mobile Developer Conference II dove Fabio, Marco e io abbiamo presentato le novità di .NET CF 2.0, VS 2005 for Mobile Devices, SQL Server 2005 Mobile Edition.
I dettagli su http://thinkmobile.it/blogs/rob/archive/2005/12/18/5044.aspx
Buon download
Si dice che esista un CAB per l'installazione semplificata di MSMQ su Windows Mobile 5.0..ma cercando su google non si trova niente.
Il componente è stato incluso fra gli Redistributable Server Component for Windows Mobile 5.0 e non è pacchettizzato (come accadeva per i binary MSMQ nell'SDK di Windows CE 4.2) nell'SDK per Windows Mobile 5.0 for Pocket PC.
Sul mio blog su thinkmobile trovate il contenuto del pacchetto http://thinkmobile.it/blogs/rob/archive/2005/12/11/5038.aspx.
All'interno si trova anche MSMQ.ARM.CAB cioè il cab per l'installazione su processore ARM (anche gli emulatori di VS 2005 sono basati su ARM !) della parte client.
http://www.microsoft.com/downloads/details.aspx?FamilyID=dc8332d6-565f-4a57-be8c-1d4718d3af65&displaylang=en
E' un driver di rete virtuale per l'emulatore Pocket PC o Smartphone. Consente al sistema operativo dell'emulatore (o volendo di un macchina ospitata in Virtual PC) di emulare una connessione di rete: la rete fisica sulla macchina host viene virtualizzata e di conseguenza è possibile associare un IP al Device Emulator. L'emulatore può connettersi via TCP o UDP senza nessun bisogno di legarsi al PC tramite ActiveSync.
Breve articolo pubblicato su week.it del 30 ottobre:
La versione 2.0 del .NET Framework presenta una nuova serie di classi per la gestione delle transazioni locali e distribuite. Questa evoluzione/rivoluzione deriva dalla necessità di avere un modello semplice e chiaro per la gestione delle trasazioni da codice.
La versione 1.x del Framework fornisce due modalità per la gestione delle transazioni: la prima, definita gestione esplicita, consente di utilizzare il metodo BeginTransaction direttamente su un oggetto IDbConnection per ottenere un oggetto IDbTransaction su cui eseguire poi il Commit e RollBack; il secondo metodo, definito gestione implicita, si appoggia a EnterpriseServices per definire, tramite attributi su classe e metodi, il “rapporto” rispetto alla transazioni gestite da COM+. Entrambe le metodologie presentano numerosi svantaggi e nessuno dei due è “migliore” dell’altro. Le transazioni esplicite non consentono, ad esempio, di gestire transazioni distribuite su più database o più in generale su risorse che supportano le transazioni come MSMQ o sul FileSystem di Windows Vista, e non consentono di gestire transazioni eseguite da più componenti anche su un uno resource manager. Il modello che si appoggia a COM+ non consente di determinare dal codice di ogni metodo il relativo supporto alla transazioni e gestisce qualunque transazione tramite MS DTC (non necessario per transazioni locali).
La versione 2.0 presenta numerose novità a riguardo: per prima cosa il modello di programmazione è stato unificato consentendo allo sviluppatore di progettare metodi che lavorano sia con transazioni locali sia con transazioni distribuite utilizzando lo stesso pattern implementativo e gli stessi oggetti. Le transazioni 2.0 iniziano sempre come transazioni locali senza appesantire l’esecuzione tramite MS DTC; solo quando vengono invocati componenti remoti o vengono coinvolti più resource manager, la transazione viene promossa (Transaction Promotion) a transazione distribuita e verrà coordinata da MS DTC: il modello consente di utilizzare solo le risorse necessarie rispetto al lavoro da compiere.
SQL Server 2000, MSMQ, Oracle e DB2 necessitano ancora di MS DTC anche per transazioni locali in quanto non supportano le nuove interfacce necessarie: saranno previsti aggiornamenti ai prodotti citati per unificarsi al nuovo modello; la storia si ripete: la stessa cosa accadde con l’uscita di MS DTC e MTS).
Il cuore del nuovo modello è la classe System.Transaction che rappresenta la transazione per tutti i transaction manager. L’oggetto consente di eseguire l’enlist dei vari resource manager, di impostare l’Isolation Level, di ottenere informazioni sulla transazione in corso e, tramite il metodo Rollback, di eseguire l’abort della transazione. La classe espone anche il metodo Completed (secondo il pattern per gli eventi .NET 2.0) per conoscere l’esito di una transazione. Non ha il metodo Commit e a tal proposito, nel prossimo articolo vedremo qualche dettaglio su CommittableTransation, TransactionScope e TransactionClone.
Seconda parte: http://www.weekit.it/index.php?option=com_content&task=view&id=36962&Itemid=191
Un interessante guida/help per la migrazione da ASP.NET 1.x a ASP.NET 2.0: http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspp/html/conversionissuesasp_net.asp.
VS 2005 fa la maggior parte dei cambiamenti ad un progetto ASP.NET 1.x tramite in Migration Wizard: come sempre un occhio al risultato non guasta e questa guida ci da una mano nei controlli.
More Posts
Next page »