Roberto Brunetti

VS 2008 Upgrade a SQL CE 3.5

Questa mi era sfuggita nelle varie probe che avevo fatto: oltre all'ormai famoso upgrade.exe che consente sul device di aggiornare il database .sdf alle nuove versioni (era presente anche in SQLCE 3.0 e SQLCE 3.1), è possibile convertire i database direttamente da VS 2008. E' sufficiente aprire il file sdf dal progetto (o da dove volete ovviamente) per poter effettuare l'upgrade al volo.

Se non si è capito :-) sto migrando un progetto reale .NET CF 2.0 a .NET CF 3.5 :-)

VS 2008 Upgrade from VS 2005 for Mobile Dev

Quando si apre un progetto/solution VS 2005 in VS 2008 vengono aggiornati i file di progetto e della solution al nuovo formato.

Occorre tenere presente che:

• Un progetto .NET CF 1.0 viene aggiornato (come reference) alla versione 2.0 del .NET CF
• Un progetto .NET CF 2.0 rimane invariato, non viene quindi portato alla versione 3.5 del runtime
• I riferimenti a SQLCE 3.0 (SQL 2005 Mobile Edition) e SQLCE 3.1 vengono aggiornati a SQL CE 3.5
• I progetti SmartPhone 2003 vengono aggiornati a Windows Mobile 5.0 for SmartPhone

Dopo la conversione, su ogni progetto, con tasto dx, è possibile aggiornare le librerie al .NET CF 3.5. 

E' poi possibile, come in VS 2005, modificare la "Target Platform" per portare i progetti da una piattaforma all'altra.

.NET CF 3.5 Power Tools Network Logger

Fra gli strumenti interessanti della nuova versione del .NET Compact Framework troviamo i vari Logger che consentono di creare appunto file di log sulle operazioni effettuate dalle applicazioni .NET CF.

Gli strumenti non sono inclusi in Visual Studio 2008, ma arrivano come Power Tools, per adesso scaricabili da http://www.microsoft.com/downloads/details.aspx?familyid=c8174c14-a27d-4148-bf01-86c2e0953eab&displaylang=en&tm e in versione September CTP.

Una volta installato il tutto si puó utilizzare Logging Configuration per abilitare e disabilitare, su device e emulatori, le varie opzioni di logging:

• Loader
• Native Interop
• Network
• Error
• Finalizer

Ogni logger scrive le informazioni in un file di log nella stessa directory dove gira l'applicazione.

Per effettuare analisi sul traffico di rete, i pacchetti spediti, i byte inviati e ricevuti é possibile usare il Network Logger Viewer che visualizza, in forma "grafica" il file di log relativo.

Ad esempio questo i log su una chiamata ad un servizio WCF in basicHttpBinding effettuata dall'emulatore.

Nella prima griglia si vedono, in base ai timestamp, i vari record di invio/ricezione pacchetti e abilitando (come da figura) le colonne Bytes Sent e Bytes Received si puó facilmente analizzare quante informazioni sono state inviate.

Per ogni record, nella finestra sotto troviamo il dettaglio dei byte scambiati e lo stream relativo, mentre nella finestrina a destra si vede la rappresentazione testuale.

In questo esempio, la chiamata riguarda appunto un servizio WCF che accetta un valore intero e restituisce, come da figura sotto la scadenza di una polizza.

WCF su .NET CF 3.5

Dopo il rilascio dei Power Toys per .NET CF 3.5 September CTP ecco la lista (sembra finale) del subset delle feature supportate da WCF sul Compact Framework 3.5.

Workflow Tracking Service

Articolo da me pubblicato su Week.it del 18 settembre 2007.

Il motore di Windows Workflow Foundation espone nativamente un servizio per tenere traccia delle operazioni effettuate all’interno di instance di workflow. È un ottimo strumento per monitorare in tempo reale oppure a posteriori lo svolgimento delle operazioni delle varie activity eseguite all’interno dei vari workflow.

Il servizio non é abilitato per default e necessita delle creazione della struttura e logica (stored procedure) su un database Sql Server: operazione che si effettua manualmente tramite il lancio di due file .sql facilmente rintracciabili nella directory Windows Sdk.
Una volta creata la struttura è sufficiente fornire la connection string verso il database creato al servizio di tracking e aggiungere il servizio stesso al runtime di workflow interessato.

È possibile utilizzare lo stesso database per diverse tipologie di workflow e condividere la struttura a più workflow runtime. Il servizio, per default, lavora nella stessa transazione utilizzata dal persistence service: questo implica che le informazioni di tracking verranno salvate nel database solo durante i persistence point e quindi non siano visibili fino a che il workflow non viene persistito. Il motivo è semplice: mantenere allineate le informazioni di tracking con lo stato del workflow. È possibile modificare questo comportamento tramite un semplice flag che indica al servizio di tracking d’inserire le informazioni appena disponibili. Valutare con cura la scelta su questo comportamento.

Se il database di tracking è lo stesso del database utilizzato per la persistenza é consigliabile utilizzare anche il servizio (da aggiungere sempre ai runtime) SharedConnectionWorkflowCommitWorkBatch che consente di riutilizzare lo stesso oggetto connection per persistenza e tracking evitando l’utilizzo di due connessioni che implicano una transazione distribuita e quindi l’uso di Distributed Transaction Coordinator (Ms Dtc).

Il secondo consiglio riguarda le informazioni da tracciare: per default si tracciano tutti gli stati di tutte le attività presenti nel workflow (e del workflow stesso visto che in ultima battuta è a sua volta una activity).
Potrebbe quindi venir tracciata una grossa mole di dati, spesso non interessante ai fini di monitoraggio. Conviene creare quindi un profilo di tracking che indichi solamente quali stati tracciare in modo da ridurre al minimo indispensabile le informazioni da memorizzare. Il servizio espone anche la possibilità di partizionare i dati su base temporale, spostando in automatico o manualmente tramite lancio di stored procedure (da schedulare ovviamente), i dati in tabelle storiche.

Visual Studio Team System 2008 Architect Power Tools

Dopo un mese di fuoco trovo finalmente il tempo di fare un post su questo strumento a mio avviso fondamentale per disegnare e progettare applicazioni che fanno uso di class library...praticamente tutte :-)

Nella versione 2005 di VSTS Architect Edition non era possibile rappresentare nel diagramma AD (Application Diagram) progetti di tipo class library che, come da documentazione, dovevano essere considerati parte del progetto principale: in pratica un progetto Windows Form, oppure ASP.NET, oppure Web Service ospitava nel digramma tutte le dll referenziate.

Noi, in DevLeap, avevamo optato per un workaround in modo da rappresentare in AD e DD (Deployment Diagram) i progetti di tipo DLL. Tutte le nostre implemtazioni fanno uso di UI Layer, composto da uno o piú progetti di tipo class library, di un Biz Layer che si appoggia a dei factory per l'accesso ai dati o la chiamata a servizi (Web Service o WCF). A tal proposito si vedano i post

http://blogs.devleap.com/rob/archive/2005/09/06/5670.aspx
http://blogs.devleap.com/rob/archive/2007/04/11/solution-che-accompagner-molte-demo-della-devcon-2007.aspx

In pratica il diagramma relativo alla parte BIZ/DAL evidenzia l'uso di Generic Application per rappresentare i progetti di tipo Class Library.

In Visual Studio 2008 Architect Edition, a parte altre interessanti novitá, la situazione é rimasta praticamente invariata, a meno di non installare i Power Tools per la versione Architect. Per adesso sono allineati alla Beta 2 di VSTS 2008.

Questo add-in consente di rappresentare e soprattutto descrivere i progetti di tipo class library, legarli al diagramma SDM e come sempre sincronizzarne le impostazioni con il progetto reale.

Ad esempio, partendo da un semplice esempio, é possibile rappresentare i progetti di tipo Class Library che appaiono nella toolbox dopo l'installazione dei Power Tools.

Ogni connessione fra applicazioni e class library verrá poi gestita con una reference fra i progetti Visual Studio, cosí come ogni reference effettuata dai progetti si riflette sul diagramma tramite la visualizzazione della connessione.

Tempo fa ho eseguito l'upgrade della nostra soluzione (presentata a DevCon 2005 e DevCon 2007) composta ormai da una settantina di progetti Visual Studio in unica solution: si veda il post http://blogs.devleap.com/rob/archive/2007/05/10/upgrade-to-orcas-beta-1.aspx.

Dopo aver montato i Power Tool ho deciso di ridisegnare AD e DD facendo uso dei progetti di tipo class library.

Giustamente il risultato che mi si é presentato riaprendo il diagramma dopo l'installazione é il seguente

In pratica l'AD si é accorto delle varie reference a progetti class library dai progetti reali e ha rappresentato le "figurine" e le relative connection sul diagramma. I nomi dei progetti sono gli stessi dei nomi reali dei progetti .csproj a cui sono stati tolti in automatico, come da prassi, i ".".

Per eliminare le Generic Application che avevamo usato come placeholder nella versione 2005 occorre procedere eliminando prima tutti i file .SDM (delle generic application) dalla solution di Visual Studio e poi eliminare dal diagramma i relaitivi elementi grafici.

Gli SDM relativi alle applicazioni di tipo Class Library vengono memorizzati direttamente nel relativo progetto Visual Studio, come accade da sempre per i tipi di applicazioni gestiti dall'AD.

Altra operazione che avevamo fatto come workaround era stata quella di legare le class library dello strato DAL al database, operazione non piú necessaria in quanto il legame fra applicazione e DB sta giustamente nell'applicazione principale (Windows Form, WPF, ASP.NET che sia) ove infatti, da sempre, sono memorizzate le connection string nei rispettivi file .config.

Alla prossima.