Il WebServiceEndpoint è diventato .NETWebServiceEndpoint. A discapito del nome e all'integrazione di alcuni strumenti della versione 9 rispetto a WCF, non consente di creare Endpoint verso servizi WCF. Un collegamento come il seguente crea sempre una Web Reference classica nel progetto consumer del servizio:
In questo caso infatti il client Windows si ritrova una directory Web Reference con all'interno la classica Web Reference con tanto di reference.cs.
Questo accade anche se nei progetti (visualizzandoli nella solution di VS) non esiste più il comando Add Web Reference. Ha preso il suo posto Add Service Reference che consente di creare appunto una reference verso servizi WCF e verso i classici .asmx di .NET 2.0. Il namespace per default è ServiceReference così come il folder nel progetto.
Anche nel caso di "aggancio" con ASMX, lato cliente viene usato WCF tramite un basicHttpBinding o un customBinding.
Il menù Configure Service Reference che dovrebbe essere una sorta di UI helper per la gestione del .config del consumer non è ancora stato implementato in questa CTP.
Facendo qualche prova capita frequentemente di dover eseguire operazioni di Refactoring: occhio che se fare refactoring dell'interfaccia di un servizio WCF e della classe, la configurazione ABC nel config non viene aggiornata.
Per default il primo progetto creato con Visual Studio 9.0 è ancora legato al runtime .NET versione 2.x. Per legare il progetto al runtime .NET 3.5 si può inserire nel .config (web.config o app.confg) la seguente configurazione del compilatori:
<system.codedom>
<compilers>
<compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CSharp.CSharpCodeProvider,System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<providerOption name="CompilerVersion" value="v3.5"/>
</compiler>
<compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.VisualBasic.VBCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" compilerOptions="/optioninfer+">
<providerOption name="CompilerVersion" value="v3.5"/>
</compiler>
</compilers>
</system.codedom>
Unit Test
Dal menù di creazione di uno Unit Test su un metodo è possibile creare un nuovo test su un assembly al posto del classico codice sorgente. Valgono le regole attuali per i membri private accessibili tramite il PrivateAccessor autogenerabile.
Test List diventa Test List Editor e consente, come adesso, di organizzare i test in raggruppamenti per una più semplice identificazione e esecuzione a comando o su una Build.
E' possible eseguire Unit Test su progetti mobile (Smart Device Project). Nell'immagine seguente mostro la directory dei tool per il device e le relative dll.
La creazione di uno Unit Test (con Add Assembly citato prima) è la seguente:
Il progetto mobile risultante è un Device Project a tutti gli effetti (che potrebbe essere anche fatto girare sul desktop come tutti i progetti mobile con qualche workaround...a tal proposito si vedano i miei post sul sito http://thinkmobile.it). Il framework di esecuzione del test è referenziato (ovviamente) nel progetto test:
Il frameowrk di test per smart device è un subset degli strumenti disponibili nell'edizione Tester di VSTS. Queste le funzionalità non supportate:
- Web tests and the Microsoft.VisualStudio.TestTools.WebTesting API
- Generic tests
- Load tests and the Microsoft.VisualStudio.TestTools.LoadTesting API
- ASP.NET unit tests and Microsoft.VisualStudio.TestTools.UnitTesting.Web API
- C++ test projects
- C++ unit tests
- Data driven unit tests
- Obtaining code coverage data in unit tests
- Creating a performance session
- Web services unit tests
- Working with controllers, agents, and rigs
- The following Team System testing tools are implemented differently for smart devices:
- Smart device specific C# and Visual Basic test projects
- A version of the Test Host adapter that runs on the device
- Extra Test Run Configuration settings for smart devices
- Must attach manually to debug smart device unit tests. For information about manually attaching to process, see How to: Debug while Running a Test in an ASP.NET Solution
- Different method of Test Deployment
- Device specific port of the Microsoft.VisualStudio.TestTools.UnitTesting API with the following classes removed:
- DataSourceElement
- DataSourceElementCollection
- TestConfiguration
- TestConfigurationSection
- WebServiceHelper
Performance Session
Nelle proprietà di una Performance Session è possibile indicare i counter del Performance Monitor da collezionare durante la fase di analisi: questo consente di effettuare analisi più accurate da un unico strumento di analisi. Si può anche decidere di eseguire una Performance Session senza collezionare i dati semplicemente agendo dal menù contestuale (senza dover entrare nelle proprietà)
Durante una sessione di performance si può attivare il Runtime Control che consente di definire vari "mark" per effettuare analisi su porzioni della sessione. I vari mark vengono poi riepilogati nel report al termine della sessione.
E' stata modificata l'interfaccia per l'analisi dei .vps (Performance Session Data) per consentire l'impostazione di query sui dati, filtri sui vari elementi da analizzare: è possibile ad esempio visualizzare solo i dati di una certa function oppure con un certo valore. Il tutto si effettua dall'interfaccia di visualizzazione seguente:
Le query create e i dati relativi possono essere salvati in un file .vsps ed è possibile salvare e ricaricare la definizione delle query tramite file .vspf.
L'analisi dei dati comprende anche ETW, Marks e i processi entrati in causa.
Un nuovo strumenti di analisi consente di visualizzare i "Code Metrics" per 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). Ecco il nuovo strumento su un mio progetto di Test:
ASP.NET
Un nuovo progetto ASP.NET usa i compilatori della versione 3.5: nel web config infatti otteniamo da subito:
<system.codedom>
<compilers>
<compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CSharp.CSharpCodeProvider,System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<providerOption name="CompilerVersion" value="v3.5"/>
</compiler>
<compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.VisualBasic.VBCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" compilerOptions="/optioninfer+">
<providerOption name="CompilerVersion" value="v3.5"/>
</compiler>
</compilers>
</system.codedom>
L'editor delle pagine e in generale dei sorgenti web fornisce Intellisense su Javascript e sulle AJAX. Ecco un esempio su Javascript
Le AJAX Extension comunque vanno installate.
Ho un solo grosso problema: sabato cerco di capire...il designer dei Workflow che dovrebbe avere le nuove dialog per le Rule non si apre :-(
Per il resto, giusto come considerazione, ho montato tutto su una macchina virtuale assegnando 1.360 MB di RAM...e devo dire che viaggia benone, considerando che purtroppo la macchina virtuale è su un disco esterno che non è veloce quanto il mio disco interno. In una settimana, un solo crash dell'ambiente senza perdere niente. Ottimo direi.
Per la parte mobile, purtroppo il .NET CF 3.5 che era presente nella CTP di Gennaio non c'è più. Sabato, dopo la creazione di uno snapshot :-) spero di avere il tempo di provare a montare la parte mobile della CTP di gennaio sopra la CTP di Marzo...speriamo bene :-)