Articoli DevLeap

VISUAL STUDIO 2008, .NET FW e CF 3.5

Articoli pubblicati su week.it che ho riuniuto in un unico post.

Uscita la Beta 2 di .NET 3.5 e Visual Studio 2008 (ormai siamo alla RTM, ma era bello lasciare questa frase di inizio agosto che ci ricorda il caldo e le ferie J è giunto il momento di iniziare una serie di articoli settimanali per analizzarne le novità indicando, ove possibile, i puntatori verso informazioni più corpose.

Per prima cosa occorre separare nettamente cosa offre la nuova versione del Framework .NET e quali strumenti mette a disposizione Visual Studio 2008 a supporto delle nuove feature, senza dimenticare i nuovi strumenti indipendenti dalla versione del Framework. Con questa frase voglio sottolineare, se ce ne fosse ancora bisogno, che la piattorma .NET offre, da sempre, librerie e componenti utilizzabili senza l’ausilio di Visual Studio. Dall’altra parte, Visual Studio, in base all’edizione scelta, fornisce non solo strumenti che automatizzano e facilitano l’utilizzano di alcune di queste librerie e componenti, ma fornisce strumenti di supporto per la gestione del ciclo di vita di un software, per l’analisi del codice sorgente e del codice in esecuzione, per la definizione visuale di classi, diagrammi applicativi e di deployment e non ultimo strumenti per la gestione di test sul codice. Quindi se da una parte potremmo scrivere applicazioni, anche complesse, senza utilizzare Visual Studio, dall’altra parte, lo strumento è diventato un alleato importante e indispensabile per la gestione dei progetti software.

Nei vari articoli che seguono, nelle varie settimane, analizzeremo separatamente, le novità che riguardano la piattaforma, come l’integrazione di AJAX nel motore ASP.NET, i nuovi costrutti C# e VB, l’introduzione di LINQ per citarne alcuni, e le novità che riguardano l’ambiente di sviluppo, non tanto rispetto alle novità del Framework, quanto rispetto agli strumenti di supporto della soluzione software, come Unit Testing, nuove funzionalità di refactoring, nuovi designer che appunto prescindono dalla versione del Frameowrk utilizzato: ad esempio, le nuove funzionalità di refactoring possono lavorare anche su progetti .NET FW 2.0/3.0.

Chiudiamo questo primo articolo della serie con un chiarimento sulle versioni con cui lavoreremo: ad oggi, come saprete, i compilatori .NET sono in versione 2.0, versione indicata anche per i linguaggi (C# è in versione 2.0, VB.NET è in versione 8, ovvero la seconda versione di VB.NET dopo la 6.0 che allineata al vecchio mondo COM); il .NET Compact Framework è in versione 2.0 (SQLCE è in versione 3.1), mentre il Framework completo è in versione 3.0: la versione 3.0 ha portato novità con l’aggiunta delle librerie WCF, WPF, WF che si utilizzano ancora con C# 2.0 (e VB.NET 8) e, appunto, i compilatori in versione 2.0.

La versione 3.5 “complica ancora un po’” lo scenario: i compilatori fanno un salto di versione passando alla 3 (quindi avremo C# 3.0 e VB.NET 9), il runtime passa alla versione 3.5 inglobando anche molte librerie ad oggi disponibili come download separato. Il Framework è quindi in versione 3.5 così come il Compact Framework passa alla versione 3.5 e si porta dietro SQL Compact Edition versione 3.5. Visual Studio è invece in versione 2008 e consente la creazione di progetti che si basano sul runtime del Framework 2.0, 3.0 (in pratica versione 2.0 più WPF, WCF, WF) e versione 3.5. Sviluppando un progetto versione 3.5 si ottengono le reference (o si devono fare a mano le reference J) verso le librerie 2.0 per quanto riguarda le funzionalitá base (ad esempio la System.Transaction), verso le librerie 3.0 per quanto riguarda le classi aggiunte nella versione 3.0 (WPF, WCF, WF, WCS) e/o verso le librerie versione 3.5 per le novitá introdotte: queste ultime sono nuove librerie, come il caso di LINQ, rivitazioni di librerie esistenti, come nel caso della System.Web.Extension, oppure aggiunte a funzionalitá della 3.0, come ad esempio i servizi di hosting di workflow in WCF (WorkflowServiceHost).

Mobile Development

La nuova versione di Visual Studio viene equipaggiata con template e SDK per le piattaforme Pocket PC 2003, Windows CE, Windows Mobile 5.0 Pocket PC e Windows Mobile 5.0 SmartPhone e supporta la creazione/gestione di progetti basati sul .NET Compact Framework 2.0 e 3.5. E’ anche possibile convertire un progetto dalla versione .NET CF 2.0 alla versione 3.5. In pratica scegliendo la versione vengono proposte le reference corrette agli assembly .NET nelle varie versioni e agganciato il compilatore allineato alla versione del linguaggio utilizzato. Come abbiamo accennato nel primo articolo della serie, verrà utilizzato il compilatore C# versione 3.0 per progetti .NET CF 3.5 e l’attuale compilatore C# 2.0 per progetti in versione 2.0.

Gli emulatori utilizzano il Device Emulator 2.0 (disponibile oggi al download e installabile anche con Visual Studio 2005), mentre il Device Emulator 3.0 è installabile, almeno per adesso, come download separato. La nuova piattaforma di emulazione fornisce il Device Configuration Manager che elimina la necessità attuale di comporre manualmente file xml per modificare la configurazione degli emulatori. Risulta quindi molto semplice modificare le impostazioni di security per aderire a quelle dei device in commercio: con semplici selezioni da una interfaccia grafica si può lavorare One-Tier, Two-Tier, Locked o Prompt.

Una delle novità più interessanti è sicuramente la possibilità (offerta anche dalla versione Professional) di creare Unit Test su codice .NET CF e eseguirli su device o emulatore. La funzionalità è molto simile a quanto oggi troviamo in Visual Studio Team System for Tester: in pratica sono state aggiunte le librerie mobile per eseguire i test e collezionarne i risultati da riportare nell’IDE di Visual Studio. I risultati possono poi essere pubblicati, associandoli ad una Build, in Team Foundation Server.

Upgrade

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.

Per quanto riguarda SQL CE, 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.

Piú avanti vedremo le novità del .NET CF 3.5 come LINQ e WCF e gli strumenti del .NET CF 3.5 SDK per eseguire profiling e analisi delle performance di una applicazione. Come abbiamo avuto modo di chiarire nel precedente articolo, questi strumenti sono indipendenti da Visual Studio.

Visual Studio 2008 for Mobile Dev

Il .NET CF 3.5 adesso installa le stringhe di risorse sul device/emulatore tramite un nuovo cab denominato NETCFv35.Messages.EN.CAB che si trova sotto x:\program files\Microsoft.NET\SDK\CompactFramework\v3.5\windowsce\Diagnostics.

La creazione di un nuovo progetto presenta una nuova maschera, simile a quanto avveniva in VS 2003: non si sceglie il progetto dall'alberino delle varie solution disponibili, ma è sufficiente scegliere Smart Device: una volta scelto il tipo di progetto in una seconda maschera si sceglie la tipologia di piattaforma e poi la versione del .NET CF da utilizzare per le reference e per la distribuzione del runtime sul device. Si può optare per .NET CF 2.0 o per .NET CF 3.5.

N.B. le immagini incluse sono ridotte come dimensione: accanto ad ognuna il link verso la dimensione reale.

Questa la prima maschera:

Come si nota le piattaforme per cui è installato nativamente l'SDK sono Pocket PC 2003, Windows CE, Windows Mobile 5.0 for Pocket PC e SmartPhone.

Una volta scelta la piattaforma si sceglie la versione del .NET CF da utilizzare:

 Dopo la scelta della versione del .NET CF, come sempre scegliere Device Application, Class Library e così via per creare il tipo di progetto.

Il designer delle Windows Form (visto che WPF non è disponibile sul .NET CF 3.5) si presenta molto simile al precedente: si può scegliere il form factor da assegnare ad ogni form e ruotare lo schermo del designer come nella versione 2005 di VS.

Anche la toolbox si presenta più o meno identica. Questo l'elenco dei controlli:

La configurazione dell'emulatore da Visual Studio prevede quanto conosciamo con l'attuale Device Emulator 2.0 e consente la gestione del livello della batteria: questa funzione risulta molto comoda per testare un'applicativo power-aware (come dovrebbero essere tutti): è inutile lanciare una operazione lunga di analisi sui dati, ad esempio, se resta il 2% di batteria.

Molto interessante il nuovo Device Configuration Manager, primo fra gli strumenti per facilitare la configurazione di device e emulatori: ad oggi è necessario comporre i file .xml di provisioning e "installarli" tramite rapiconfig.exe. Con questo nuovo strumento risulta molto semplice leggere la configurazione, modificarla e vedere le differenze fra la configurazione desiderata e quella attuale. Si possono importare anche i nostri file di provisioning esistenti per una facile migrazione al nuovo strumento.

Risulta molto semplice così testare l'applicazione firmata o non firmata sulle varie configurazioni dei device One-Tier, Two-Tier, Locked, Prompt e così via.

Tramite questo strumento è possibile visualizzare i certificati digitali installati su device e emulatori, installarne di nuovi e verificarne i dettagli. Una nota, i nomi dei certificate store sono cambiati: non abbiamo più il privileged e unprivileged, ma Privileged Store e Standard Store, dove il secondo rappresenta lo store per i certificati con cui le applicazioni possono girare in normal-mode su device two-tier.

Il .NET CF Remote Performance Monitor consente, nella nuova versione di fare un "attach to process" rendendo più semplice l'analisi di una porzioni di applicazione: la versione attuale deve lanciare l'applicazione e quindi ci costringe a visualizzare i dati complessivi di tutta l'applicazione fino a raggiungere il punto in cui si desidera effettuare le verifiche. La parte device-side viene installata in automatico dallo strumento senza bisogno di copiare manualmente i file nella directory \Windows: qualche problemino sulla mia Beta non consente di eseguire questa operazione in automatico e quindi ho dovuto comunque copiare i file a mano. I nuovi file device-side hanno nomi diversi dai precedenti e più precisamente sono: rtf3_5.dll e rtfhost3_5.exe. Tali file si trovano sempre nella directory dell'SDK del .NET CF 3.5 x:\program files\Microsoft.NET\SDK\CompactFramework\v3.5: ricordatevi di scegliere poi la directory corretta in base al processore del device; per gli emulatori si utilizza sempre la versione ARM.

Nella prossima immagine la directory con gli strumenti lato PC di sviluppo. Oltre al .NET CF RPM, troviamo LogViewer, già presente nella versione 2.0 SP1/SP2 e due nuovi strumenti:

Il primo NETCFCLRProfiler è una versione ridotta (e per la verità anche diversa) del Profiler del Framework completo. Consente di analizzare nel dettaglio un'applicazione in esecuzione: anche in questo caso ci si può "attaccare" ad un processo già avviato e l'installazione delle dll lato device è automatica (come sempre sono sfigato e ho dovuto copiare a mano clrpro3_5.dll sul device). Lo strumento visualizza anche sotto forma di flusso grafico le chiamate fra i vari metodi consentendo una semplice (si fa per dire quando si parla di profiling in generale) individuazione dei punti della call stack che possono dare problemi.

Come abbiamo accennato, il compact frameowrk 3.5 arriva con qualche dll in più per supportare LINQ e WCF (sempre in versione ridotta: entrambi sono c.a. 250KB come obiettivo nella versione finale) e i nomi dei cab sono stati leggermente rivisti.

 Nella System.ServiceModel si trovano le "porzioni" del motore di WCF e il binding basicHttpBinding, mentre in Microroft.ServiceModel.Channels.Mail.* il nuovo canale (non disponibile in WCF su desktop) WindowsMobileMailBinding che consente lo scambio di messaggi SOA sfruttando il canale della posta elettronica fra device (Pocket Outlook) e  Exchange 2007; ricordo che Exchange 2007 supporta il push dei messaggi verso il device.

Come sempre le sottodirectory wce400 e wce500 contengono i cab per l'installazione reale su device o emulatore in base alla versione del sistema operativo. Ricordo che Windows Mobile 6.0 si basa sempre su Windows CE 5, per precisione sulla 5.2.

System.Data.Entities contiene invece le parti applicative dell'entitiy framework, mentre il provider è contenuto sotto System.Data.SqlServerCe.Entitiy.dll che arriva con l'installazione di Sql Server Compact Edition 3.5.

SQL CE 3.5 arriva con qualche piccola novità per i device e con grandi novità su utilizzato su desktop, Tablet o UMPC.

La directory di installazione sul pc di sviluppo è x:\program files\Microsoft SQL server Compact Edition\v3.5 e si presenta così:

Come accennato, entity framework viene reso disponibile tramite System.Data.SqlServerCe.Entity, ma solo se utilizzato su PC, Tablet o UMPC: non è quindi disponibile per Windows Mobile.

L'installazione prevede diversi componenti:

1) SSCEVSTools-ENU.msi: installa i componenti design-time in Orcas sotto la classica directory x:\program files\microsoft visual studio 9\Common7\IDE. Questi componenti non devono essere distribuiti

2) SSCERuntime-ENU.msi: installa i componenti di runtime per desktop, tablet e UMPC. Sono indispensabili sia a runtime che a design time. Questo MSI installa anche i nuovi componenti per la versione desktop di SQCE 3.5: Microsoft Synchronization Services for ADO.NET (OCS) e la già citata System.Data.SqlServerCe.Entity.dll.

3) SSCEDeviceRuntime.msi: installa i componenti destinati ai device e emulatori sulla macchina. Questi componenti sono necessari per l'integrazione con VS Orcas anche sulla macchina di sviluppo.

Le novità che abbiamo bollato come minori (rispetto appunto a EntityFramework e OCS) riguardano soprattutto il query processor :

- data type di tipo timestamp

- nested query

- CROSS apply e OUTER APPLY

- CAST

- TOP (finalmente !!!!!) diventa così più semplice paginare i dati per la loro visualizzazione nei minuscoli schermi

Oltre a OCS e Entity Framework, SQL CE 3.5, se utilizzato sul desktop, fornisce la possibilità di rientrare in una transazione creata con la System.Transaction 2.0: in due parole una operazione su SQL CE 3.5 può essere inserita all'interno del TransactionScope.

I Book On Line non sono ancora disponibili.

Abbiamo accennato nei post precedenti come in Visual Studio Orcas sia possibile effettura Unit Testing su device (o emulatore): credo che questa funzionalità, affiancata dal nuovo .NET CF RPM e dal profiler, siano le novità più importanti e utili della nuova versione.

Tra l'latro in Orcas gli strumenti di Unit Testing non sono più all'interno di Team System, ma disponibili nella versione Professional, almeno a quanto ci è dato sapere oggi.

Ecco le maschere di crezione di uno unit test, praticamente identiche (tranne un settaggio) a quanto oggi disponibile in VSTS:

Nella seconda immagine, come si può notare, la configurazione degli host prevede il tipo Smart Device con relativa piattaforma e scelta fra device e emulatore.

Se si crea una performance session su uno Unit Test il codice viene fatto girare sul desktop.

Anche senza l'automatismo in VS Orcas, oggi è possibile eseguire unit test su codice mobile, creando un progetto desktop con i sorgenti mobile linkati al suo interno e oppure compilazioni condizionali nel caso in cui il codice faccia uso di dispositivi, tipo lettore di codice a barre ad esempio, non disponibili sul desktop. Fra qualche giorno posso postare un mio articolo, scritto per Infomedia, proprio su questo argomento. La demo allegata all'articolo è già disponibile sul mio sito Think Mobile all'indirizzo http://thinkmobile.it/files/folders/mmdcii/entry5896.aspx.

Il nuovo Device Emulator 3.0 si presenta così:

A parte la user interface pressochè identica, è possibile salvare la configurazione degli emulatori con Save As e riconfigurare l'emulatore. Il file di configurazione (.defcfg) è anche molto semplice da modificare a mano per cambiare al volo qualcosa senza ricorre alla user interface e soprattutto per poter scambiare la configurazione degli emulatori fra i membri di un team di sviluppo senza doverla ricreare su ogni PC di sviluppo.

.NET Compact Framework 3.5

Il nostro filone su Visual Studio 2008 e .NET 3.5 prosegue con questo articolo dedicato alle novità del .NET Compact Framework versione 3.5. Le novità vedono l’introduzione di LINQ To SQLCE, Windows Communication Foundation, alcune API per lavorare con certificati digitali e qualche aggiunta alle classi Windows Forms. Oltre a questo troveremo un rivisto Remote Performance Manager e un nuovo CLR Profiler.

La versione 3.5 utilizza i compilatori in versione 3 (quindi avremo C# 3.0 e VB.NET 9), quindi molte novitá riguardano il linguaggio stesso e i compilatori. Anche SQLCE fa un salto in avanti presentandosi in versione 3.5. Avremo modo di parlare delle novitá del mini/db in un articolo separato.

l primo nuovo componente è Windows Communication Foundation: si tratta di un subset ridotto dell'attuale versione per il framework completo pensata per comunicazioni device-to-server, server-to-device e device-to-device (Peer to Peer).

Il subset di funzionalità prevede il trasporto via Http (BasicHttpBinding), un subset delle funzionalità di WS-Security e WS-Addressing, con la possibilità di estensioni custom, l'encoding basato su Text o algoritmi custom. Quanto non citato non è presente: manca quindi il supporto a Service e Contract Model, manca per adesso anche l'utility svcutil.exe che uscirà sotto forma di Power Toy successivamente.

E' stato creato un trasporto apposito per sfruttare il canale email per l'invio di messaggi WCF: il tutto è accessibile tramite WindowsMobileMailBinding (non presente nella versione completa sul .NET Framework) e sfrutta i servizi esposti da Exchange 2007 per lo store-and-forward dei messaggi. Tramite Exchange 2007 si sfrutta anche la possibilità di usare Push-Technology per inviare messaggi dal server ai device.

L’elenco completo delle features disponibili con WCF “mobile” rispetto alla versione Full è il seguente:

Il secondo componente importante è LINQ, anch’esso subset del fratello maggiore: sono presenti LINQ to Object, LINQ to XML, LINQ to Dataset; nella Beta2 è apparso il supporto per LINQ to Entities e LINQ to SQL per adesso senza designer associato in Visual Studio 2008: occorre lavorare con Sql Metal per definire il modello. Per una introduzione su LINQ consiglio il libro Introducing LINQ di Paolo Pialorsi e Marco Russo e la relativa community www.introducinglinq.com.

La nuova versione si porta dietro nuovi strumenti di diagnostica: uno strumento centralizzato per abilitare/disabilitare le funzionalità di logging, dal finalizer log, al diagnostic log passando per Interop e statistiche.

Molto interessante il CLR Profiler, versione ridotta della versione del framework completo, che fornisce metodi per tracciare il comportamento delle applicazioni.

Il .NET Compact Framework Remote Performance Monitor 3.5 consente la visualizzazione della FReachable Queue e analisi più dettagliate sugli eventuali memory leak che, contrariamente a quanto pensano in molti, possono comunque verificarsi in ambiente .NET.

L’elenco completo degli strumenti della versione 3.5 del .NET Compact Framework é

.NET CF RPM: migliorato
CLR Profiler: nuovo
Logging Options: nuovo
Finalizer Log: nuovo
Network log: esistente
Native Interop
Loader Log

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.

Questo e gli altri strumenti sono utilizzabili anche con applicazioni .NET CF 2.0, senza bisogno di nessuna ricompilazione

L'unica cosa che occorre fare è eseguire la "vecchia" (si fa per dire) applicazione 2.0 con il runtime versione 3.5. Per farlo occorre creare un file di configurazione (app.exe.config) che indica appunto di far girare l'applicazione con il 3.5 come segue:

<configuration>
  <startup>
    <supportedRuntime version="v3.5.xxxx"/>
  </startup>
</configuration>

dove xxxx sta per la build che state usando (Beta1, Beta2 o l'imminente RC). La Beta 2 attuale è 3.5.71210.

Un modo più semplice per farlo è usare NetCFCfg.exe direttamente dal device: questo softwarino consente di

• Listare le versioni del .NET CF installate sul device
• Visualizzare il contenuto della GAC
• Editare la configurazione di default del device in base alle varie versioni installate
• Editare appunto i file di configurazione delle applicazioni

L'exe può essere copiato a mano nella directory Windows: come sempre occorre prendere quello corretto in base a piattaforma e processore a partire dalla directory C:\Program Files\Microsoft.NET\SDK\CompactFramework\v3.5\WindowsCE (wce500 o wce400 e sottodirectory relativa al processore) o addirittura ottenere una copia automatica quando si attacca il device o l'emulatore ad ActiveSync e si sincronizza il tutto.

VSTS non solo Mobile

Alcuni screen shot che riguardano lo sviluppo con VSTS 2008 in generale.

Per prima cosa la parte server (Team Foundation Server) si presenta così

Si basa su SharePoint v3 (di cui avremo modo di parlare alla SharePoint Conference). Il default web site espone le due classiche directory di reporting server, mentre il sito Team Foundation Server espone i servizi per Build, Services, Version Control, OLAP e Work Item Tracking.

Le varie applicazioni sono divise in 3 Application Pool che ospitano appunto i servizi TFS, la parte di reportistica e l'amministrazione di SharePoint.

Dal menù di un progetto è possibile generare le "metriche del codice"  (Code Metrics suona molto meglio) di cui abbiamo già accennato qualcosa nell'altro mio post sulla CTP di Marzo.

Per capire meglio questa nuova funzionalità prendiamo ad esempio il seguente codice

Una volta generato il Code Metrics si ottiene questo risultato.

"Code Metrics" consente di capire se il codice di un progetto/solution è complesso da manutenere, il livello di coupling, la profondità gerarchica delle classi e l'ormai famoso indice di Cyclomatic Complexity (già presente nel Code Analysis della versione attuale in forma testuale).

Altra opzione "carina" è la gestione delle using di un sorgente C#. Dal menù contestuale si possono infatti organizzare le using:

Ultimo screenshot: la versione VSTS for DB Pro 2008 presenta nativamente l'analisi del codice T-SQL tramite FXCop (che in realtà già dalla versione 2005 si chiama Code Analysis): queste le regole disponibili, immagino già note a molti:

Power Tools VSTS 2008 Architect

Il nostro filone su Visual Studio 2008 e .NET 3.5 prosegue con questo articolo dedicato ad un add-in giá disponibile per Visual Studio 2008 Team System Architect Edition che prendeil nome di Power Tools.

Il componente nasce da una esigenza fondamentale nella progettazione di applicazioni distribuite basate su vari layer: nella versione 2005 di Visual Studio Team System 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.

Se da una parte, questa rappresentazione logica é corretta, dall’altra non consente di rappresentare tutti gli elementi di una soluzione Visual Studio dal punto di vista fisico. 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). Utilizzavamo quindi le application di tipo “Generic Application” per ogni class library presente nella soluzione.

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.

Con questo add-in per la versione 2008 é finalmente possibile rappresentare e soprattutto descrivere i progetti di tipo class library, legarli al diagramma SDM e come sempre, sincronizzarne le impostazioni con il progetto reale. Ogni connessione fra applicazioni e class library gestita dall’Application Diagram 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. Il supporto two-way aderisce a quanto giá presente negli strumenti di design fino dalla versione 2005. La descrizione delle impostazioni relative ai progetti di tipo class library viene poi memorizzata in file .SDM direttamente nel progetto Visual Studio che rappresenta la dll stessa.

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