blogs.ASPItalia.com

Entity Framework nel futuro

Stefano Mostarda — Tue, 11 Oct 2011 22:22:00 GMT

A giugno, il team di EF ha rilasciato una CTP dove hanno fatto vedere alcune novit� di EF vNext. Per quanto mi riguarda, la possibilit� di ritornare pi� resultset da una stored procedure � la cosa pi� interessante. Il supporto per gli enum, gli spatial data, le query autocompilate etc etc, sono feature interessanti, ma un p� pochino per raggiungere NHibernate. Quello di cui sento veramente la mancanza � un type system customizzabile. Quando ho saputo del supporto ad enum e spatial data nel mio cuore ho sperato che il supporto fosse stato costruito sulla base di un sistema estendibile (come NH fa da quando era ancora in gestazione credo) ma sono rimasto terribilmente deluso per l'ennesima occasione persa per fare di Entity Framework un vero O/RM.

Un'altra cosa che non mi entusiasma di EF � la gestione delle relazioni quando si lavora in maniera disconnessa. Le STE sono qualcosa che proprio non riesco ad usare in un ambiente reale. Ogni volta che ci ho provato sono rimasto scottato quindi ormai non le consiglio nemmeno al mio pegior nemico. Non ho interesse ad un loro miglioramento nel futuro. vedremo se il team ce l'avr�..

Ci possiamo consolare con il fatto che Code-First in futuro verr� ampliato per supportare nativamente tutti quegli scenari che adesso sono attivabili solo dietro tonnellate di reflection (mapping di propriet� private e convenzioni custom) e che l'allineamento del database al modello tramite Visual Studio sta diventando finalmente realt�.

La mia sensazione tuttavia � che ormai il team ritenga EF pronto per creare nuove features senza toccare pi� di tanti il motore. Questo � un grosso errore e spero di sbagliarmi perch� c'� molto da fare per raggiungere NH e di questo passo la strada sar� tutt'altro che breve (sempre che l'intenzione sia quella di raggiungere NH).

Stay tuned.

Tags: Entity Framework, Entity Framework 4.1, ORM

Continua a leggere Entity Framework nel futuro.

WebWorkers e WebSocket

Stefano Mostarda — Mon, 03 Oct 2011 09:44:00 GMT

Avete mai fatto applicazioni che facessero uso intensivo di codice Javascript? Avete notato quanto siano lente? Avete mai sognato di poter parallelizzare il vostro codice Javascript? Avete mai desiderato ricevere notifiche in tempo reale dal server senza bisogno di fare polling AJAX?

Se avete risposto si ad almeno una di queste domande allora WebWorkers e WebSockets fanno al caso vostro. Ma partiamo dai WebWorkers.

Javascript � single-threaded. Attraverso un sapiente uso dei metodi setTimeout e setInterval potete creare codice asincrono, ma sempre single-threaded. Questo in moltissime applicazioni va pi� che bene, ma che mi dite di applicazioni che devono andare periodicamente sul server a recuperare dati, fare pesanti calcoli ed aggiornare la UI di conseguenza? In questi casi avere un thread-separato rispetto al thread principale aiuta parecchio ad ottimizzare le performance in quanto la UI non viene bloccata mentre si processano I dati. Finalmente, grazie ai WebWorkers introdotti con HTML5 e Javascript5, creare pi� thread in Javascript diventa possibile. Non abbiamo a disposizione un framework evoluto, ma una serie di API che consentiranno nel futuro di averne.

Il concetto alla base dei WebWorkers � molto semplice: definiamo un file JS che contiene il codice da far girare in un altro thread e poi inizializziamo un thread passandogli in input l'indirizzo del file JS. Ovviamente possiamo passare dei parametri al nuovo thread e ricevere dati dal thread stesso. Quest'ultima feature � fondamentale in quanto il thread secondario non pu� accedere al DOM che � accessibile solo dal thread principale. Insomma, il concetto � che I WebWorkers ci permettono di fare applicazioni molto pi� veloci e responsive che in passato.Bench� supportati ormai da tutti I browser, la nota dolente � alcuni browser come chrome e firefox supportano I WebWorkers solo attraverso il prefisso (Moz o WebKit).

Il discorso dei WebSocket invece � (se possibile) ancora pi� interessante. Il protocollo HTTP � basato sul concetto di richiesta/risposta: il client chiede il server risponde. Per far arrivare degli aggiornamenti dati dal server al client senza che l'utente aggiorni la pagina, utilizziamo la tecnica del polling unito all'uso di XmlHttp per essere asincroni. Questa tecnica simula le notifiche real-time ma offre numerosi svantaggi. Il primo � un incredibile overhead di rete: se io voglio scambiare con il server pochissimi dati, comunque la richiesta � molto corposa per via delle intestazioni http. Il secondo overhead � a livello di canali di comunicazione visto che se ne devono stabilire 2 per ogni richiesta. Con I WebSocket il discorso cambia radicalmente. Possiamo infatti creare con il server un canale bidirezionale attraverso il quale il browser pu� ricevere e inviare dati al server in realtime senza polling; il tutto si basa inoltre sulle porte 80 e 443 e quindi senza avere problemi di firewall. Questo significa abbattere gli overhead precedenti poich� si crea un solo canale e poich� non essendoci HTTP non ci sono nemmeno le intestazioni HTTP ad incrementare la corposit� dei messaggi inviati.

Insomma, WebWorkers e WebSocket rappresentano grosse novit� che faranno parte del nostro toolset nei mesi a venire. Non sono ancora perfettamente integrati in tutti I browser, ma lo saranno molto a breve quindi vi consiglio di dargli una bella occhiata ;).

Stay tuned.

Tags: HTML5, Javascript

Continua a leggere WebWorkers e WebSocket.

E così Reflector diventa a pagamento

Stefano Mostarda — Thu, 03 Feb 2011 23:30:13 GMT

Ebbene si, dopo quasi un decennio di Reflector free, siamo arrivati al fatidico momento in cui questo fantastico tool diventa a pagamento. Ora per spulciare il codice negli assembly degli altri dovremo sborsare 35 dollari.

Che c'� di strano? Assolutamente NULLA. Fa solo effetto vedere il tool pi� famoso nel mondo .NET passare da free a pagamento. Far� effetto vedere richiete per Reflector nei forum che danno link per scaricare software craccato. Non uso ne il mulo ne torrent, ma so gi� che si trover� reflector anche li.

Personalmente, mi aspettavo questa fine. Quando un'azienda acquisisce un tool � perch� ci vede un business e il business dietro Reflector � grande. Pagher� questi 35 dollari senza darci troppo peso perch� per il mio lavoro reflector � utile tanto quanto visual studio. Per�. mi sento tanto come se un'epoca fosse finita

Stay tuned.

Continua a leggere E così Reflector diventa a pagamento.

Entity Framework: DbContext, ObjectContext e la CTP 5

Stefano Mostarda — Mon, 17 Jan 2011 10:06:00 GMT

La Features CTP di Entity Framework � alla versione 5 e come ha annunciato il team non ci saranno altre versioni prima della RTM prevista entro fine marzo. Purtroppo ho paura che alcune decisioni del team non faranno altro che generare confusione. Le nuove classi DbContext e DbSet<T> hanno lo scopo, dichiarato dal team stesso, di rimpiazzare le classi ObjectContext e ObjectSet<T>.

Tutto questo � molto bello perch� le nuove classi hanno un design decisamente pi� pulito. Il vero problema � che DbContext non supporta tutte le feature che ObjectContext supporta (Stored procedure per esempio). Questo significa che in alcuni casi dovremo usare ObjectContext mentre in altri potremo usare DbContext. Non solo, il fatto che la CTP sia arrivata alla numero 5, sta facendo pensare molti sviluppatori che quella sia una CTP di Entity Framework 5. Niente di pi� sbagliato visto che si tratta solo di una serie di estensioni basate su Entity Framework 4.0.

Insomma ancora una volta abbiamo davanti un difficile compito di evangelizzazione dovuto ad alcune scelte infelici da parte di MS. Che dire ormai, ci siamo abituati.... dopo tutto se pensiamo al caos generato dal .NET Framework 3.0 e 3.5 che usavano c#3.0 ma basato sul CLR 2.0... questa di Entity Framework � una bazzecola da spiegare :D

Stay tuned....

Tags: .NET Framework, .NET Framework 4.0, Entity Framework, ORM

Continua a leggere Entity Framework: DbContext, ObjectContext e la CTP 5.

Una extension per Visual Studio per editare i file di template

Stefano Mostarda — Thu, 05 Nov 2009 11:58:57 GMT

Sono un amante dei file di template. Con un p� di modifiche possiamo generare tonnellate di codice ripetitivo. Quello che mi piace meno � che Visual Studio non da minimamente una mano nel modificare questi file. Non c'� ne colorazione del codice ne autocompletion. Per fortuna esiste un'estensione per Visual Studio 2010 che un pochino migliora le cose. Basta andare sul menu Tools -> Extension Manager e nella finestra cercare l'editor "tangible T4 Editor" ed installarlo. Una volta fatto abbiamo un minimo di Code Completion e la colorazione del codice fatta bene.

Quella che viene installata � la versione free, ma volendo c'� una versione commerciale che migliora, e anche di parecchio, il sistema di autocompletion aggiungendo alcune feature interessanti.

Stay Tuned...

Tags: Visual Studio

Continua a leggere Una extension per Visual Studio per editare i file di template.

Finalmente il template per le interfacce in VS2010

Stefano Mostarda — Tue, 04 Aug 2009 14:41:59 GMT

Ho perso il conto delle volte che ho mandato email al team di sviluppo, delle volte che mi sono chiesto perch� questa feature non ci fosse, delle volte che.. boh delle volte :).

Comunque, fatto sta che poco fa apro VS2010 e cerco di creare un'interfaccia IOrderRepository. Ero gi� rassegnato al fatto di dover creare usare il template per le classi e poi cancellare il tutto per scrivere un'interfaccia. E invece no. Con mio sommo stupore, dopo solo 9 anni dall'uscita delle prime beta di VS2002 abbiao finalmente il template per il codice delle interfacce.

Lo so � una cosa incredibilmente stupida, ma sono stato talmente contento che ho dovuto bloggarlo :).

Stay Tuned...

Tags: Visual Studio

Continua a leggere Finalmente il template per le interfacce in VS2010.

Entity Framework e le cancellazioni a cascata

Stefano Mostarda — Fri, 28 Nov 2008 01:36:35 GMT

Sono masochista oltre ogni limite: utilizzo Entity Framework e non uso il designer. Non � un problema di funzionamento del tool, � che ormai la struttura degli XML, seppur difficile all'inizio, mi � chiara e poi sono sempre i soliti 4 nodi che devo usare e grazie all'intellisense in Visual Studio � anche piuttosto facile.

Stasera per fare una prova ho voluto usare il tool visuale. Dopo aver creato la classica situazione ordini-dettagli, mi accorgo che se cancello un'ordine senza aver caricato i dettagli la cancellazione scoppia. Subito penso ad un problema di foreign key sul db, ed infatti il problema risiedeva li. tutto bello aggiorno il modello e noto che nella sezione del ssdl la delete cascade � fedelmente riportata.

Riprovo e ricevo ancora errore e qui comincio ad interrogarmi perch� non capisco il problema. Alla fine scopro che pur aggiornando il modello, nel ssdl la delete-cascad veniva corretaente riportata, menre nel csdl no, lasciando un bel buco aperto. La soluzione per me � stata semplice perch� ho cancellato il file edmx e l'ho ricreato; per quelli che non possono permettersi di fare una cosa del genere, ricordatevi di aggiornare a mano il csdl.

 <Association Name="FK_OrderDetail_Order"> 
    <End Role="Order" Type="EFInactionOrdersModel.Store.Order" Multiplicity="1"> 
        <OnDelete Action="Cascade" /> 
    </End> 
     ...
 </Association>

Stay Tuned...

Tags: .NET Framework 3.5, Entity Framework, LINQ, XML

Continua a leggere Entity Framework e le cancellazioni a cascata.

WCF LINQ To SQL il SP1 e la serializzazione

Stefano Mostarda — Sun, 06 Jul 2008 17:30:00 GMT

Oggi stavo facendo una prova con LINQ To SQL e ad un certo punto ho notato che il codice delle classi autogenerato da Visual Studio non inserisce pi� gli attributi DataMember e DataContract per la serializzazione WCF.
A questo punto ho creato un servizio WCF ed ho esposto la classe e questa veniva serializzata correttamente. Confesso che lo sconforto mi � preso un pochino perch� non capivo cosa stesse succedendo. Armato di reflector vado ad esaminare l'assembly e scopro che gli attributi in realt� sono l�.
Andando pi� a fondo, ho scoperto che una dele nuove caratteristiche del SP1 � che WCF non ha pi� bisogno degli attributi di mapping poich� questi vengono automaticamente iniettati dal compilatore sul'interfaccia pubblica di una classe. Ovviamente, si pu� modificare il tutto inserendo a mano l'attributo DataContract sulla classe e DataMember sulle sole propriet� da esporre con WCF.

Buono a sapersi.... ma uno dei cardini di WCF non era che l'esposizione delle propriet� doveva essere esplicitata dallo sviluppatore?

Stay Tuned...

Tags: .NET Framework, .NET Framework 3.0, .NET Framework 3.5, LINQ, LINQ to SQL, Windows Communication Foundation

Continua a leggere WCF LINQ To SQL il SP1 e la serializzazione.

Una noisa limitazione di LINQ To SQL

Stefano Mostarda — Sat, 31 May 2008 19:47:00 GMT

Lo sappiamo tutti: LINQ To SQL � stato concepito appositamente con delle limitazioni. Mapping 1:1 con il database (con conseguente obbligatoriet� di avere una classe di correlazione per il mapping many-to-many), ereditariet� che non supporta tutti e 3 i modelli, classi apposite per gestire riferimenti a entit� (EntitySet e EntityRef), ecc ecc.

Dal mio punto di vista, la prima e la seconda limitazione sono accettabili per un tool che nasce con lo scopo di gestire progetti semplici. La terza, tuttavia, proprio non la accetto. Per motivi di Lazy Loading e riferimenti al DataContext, EntitySet non � serializzabile. Questo significa che se in un servizio WCF proviamo a esporre un'entit� Fattura che ha una EntitySet di oggetti DettaglioFatttura, riceviamo una bella eccezione di serializzazione a runtime.

Il workaround � presto trovato, basta evitare di mettere il DataMember sulla propriet� in questione e farne una copia che espone una lista generica di oggetti DettaglioFattura, e non un EntitySet, preoccupandosi di valorizzarla correttamente. Facendo cos� i problemi si risolvono, ma il disappunto rimane per una cosa che poteva essere fatta� meglio e non costringerci al workaround.

P.S. A nessun Ughetto � stato fatto male durante la stesura di questo post, anzi, � lui che ha fatto del male a me :D

Stay Tuned...

Tags: .NET Framework 3.0, LINQ to SQL, Windows Communication Foundation, .NET Framework 3.5, LINQ, Database

Continua a leggere Una noisa limitazione di LINQ To SQL.

NHibernate entra nel mio mondo

Stefano Mostarda — Mon, 12 Nov 2007 22:45:00 GMT

Non sono mai stato un grande fan di NHibernate e degli ORM in generale. Questo perch� ho l'impressione a pelle di perdere il potere sulla base dati e sul lavoro anche se poi so cche non � cos�.
Ora comincio a convertirmi. E' da idioti non ammettere che NHibernate sia importante per gran parte delle applicazioni odierne. Prima con LINQ To SQL, poi con ADO.NET EF ed ora con NHibernate mi rendo conto che il futuro � quello: ORM per il lavoro spicciolo di persistenza e integrazione custom per le operazioni batch o query speciali o altro ancora. C'� ancora una sacca di applicazioni che non traggono benefici, o ne traggono pochi, da NHibernate quindi bisogna comunque essere in grado di scriversi a mano il DAL delle applicazioni.
Detto questo non ho intenzione di inaugurare una sezione su NHibernate perch� penso che ci sia gi� parecchio materiale in giro e finirei per dire cose gi� dette e stradette da altri; quello che voglio dire � semplicemente che NHibernate da ieri ha un nuovo utilizzatore.

Stay Tuned...

Tags: NHibernate, ORM

Continua a leggere NHibernate entra nel mio mondo.

Transactional NTFS + Transactional Database con Vista e Windows Server 2008 (parte seconda)

Stefano Mostarda — Sun, 07 Oct 2007 21:34:00 GMT

Nel post precedente avevo parlato dei test che avevo fatto per fare in modo che la scrittura dei file su disco fosse transazionale. La cosa � bella, no anzi bellissima, no anzi spettacolare, ma ancora pi� sensazionale se associata all'utilizzo di un database.

Il test � semplice anche perch� per fare tutto ci si deve affidare alla classe TransactionScope e quindi il pi� � fatto.

Alla fine scrivo l'nformazione su di un file, poi segnalo sul database la buona riuscita dell'operazione ed infine mi scordo di committare. Il risultato � che il mio database non � cambiato di una virgola ne tantomeno il mio filesystem ha dovuto registrare un nuovo file.

L'ultima cosa che devo fare � uno stress test perch� comunque la cosa va di Interop e quindi le prestazioni comunque ne risentono. Comunque con o senza Interop, una feature del genere vale la pena implementarla ovunque.

Detto questo, non posto codice perch� un uccellino mi ha detto che qualcuno si sta sporcando le mani pi� di me su questo argomento e quindi aspetto che sia lui a spiegarvi nel dettaglio le grosse novit�.

Stay Tuned...

Continua a leggere Transactional NTFS + Transactional Database con Vista e Windows Server 2008 (parte seconda).

Transactional NTFS con Vista e Windows Server 2008

Stefano Mostarda — Wed, 03 Oct 2007 22:45:00 GMT

Daniele probabilmente leggendo questo post e l'ora a cui lo sto facendo non cambier� idea su di me e continuer� a pensarla allo stesso modo, anzi forse anche peggio se cio � possibile :D.

Comunque preso dall'euforia (di cosa non posso dirlo pubblicamente altrimenti rischio pi� di quello che chiunque di voi possa mai immaginare) ho pensato bene di darmi alla sperimentazione del TfX cio� File System transazionale. Roba dell'altro mondo su Windows fino all'avvento di Vista e WS2008. Partendo da un articolo apparso qualche mese fa su Msdn Magazine, mi sono divertito a preparare un paio di esempi per vedere come sfruttare questa tecnica al volo. Grazie ad un wrapper allegato con l'articolo ed un p� di esperienza maturata su un progetto che fa pesante uso di file, ho avuto la pazienza di creare un'applicazione che:

Scrive su un file
Crea pi� file
Scrive su pi� file
il tutto sempre in maniera transazionale.

Per chi lavora con i file e tramite questi deve fare elaborazioni, spesso si � trovato di fronte all'esigenza di rinominare temporaneamente o spostare dei file solo per simulare una transazione. Questo non � pi� necessario grazie a alle nuove feature di NTFS e questo direi che mi piace molto pi� di molto :).

Lo svantaggio attuale � che non ci sono classi native, ma ci si deve affidare all'interop; io direi che se questo � il solo prezzo che dobbiamo pagare per avere file transazionali... ben venga.

Non ho fatto prove di interazione con il database per transazionalizzare il tutto (dite la verit� � anche il sogno di alcuni di voi) ma credo che a breve lo far� e vi dir� come � andata.

Stay Tuned...

Tags: Windows Client, Windows Server, Windows Vista

Continua a leggere Transactional NTFS con Vista e Windows Server 2008.

Il controllo history di AJAX??? Carino ma...

Stefano Mostarda — Mon, 23 Jul 2007 22:36:00 GMT

Questa sera, complice un caldo meno afoso degli altri giorni, sono rimasto a casa a spippolare con ORCAS e le ASP.NET Futures ed in particolare con il mio fidato AJAX.

La vera novit� che ho notato � stata l'introduzione del controllo History lasciato alle mani sapienti del maestro Nikhil Khotari fino a maggio ed ora integrato realmente in ASP.NET AJAX.

Il controllo parte da un concetto molto semplice: si piazza un IFrame nascosto nella pagina e si gioca con questo per modificare l'url della pagina ad ogni postback asincrono per garantire che si attivi l'history del browser e che la pagina sia anche bookmarkabile (italiondo puro questo termine :).
Alla fine di un postback asincrono l'url diventa cos�: http://localhost:1089/Page.aspx#%7B%22__s%22%3A%7B%22key%22%3A%223-%20780%22%7D%7D
Ad ogni postback ci dobbiamo preoccupare noi di impostare i dati necessari a riportare la pagina nello stato in cui si trova qualora l'utente premesse back. Alla pressione del tasto back, dobbiamo preocuparci di recuperare lo stato ed utilizzarlo per rivalorizzare la form correttamente.

Ma lo stato dove viene memorizzato? Questa � la domanda ovvia e la risposta � altrettanto ovvia: "nello stringone dopo il carattere "#" nell'url". Questa soluzione mi fa porre una domanda: "Ma con quantit� di dati abbastanza grandi, serializzarli in una stringa e poi deserializzarli nella form, non � un dispendio, in alcuni casi enorme, di tempo, banda e codice?" Basta pensare alle pagine con tantissimi controlli per capire che ripristinarne lo stato da una stringa � un'operazione abbastanza noiosa e soggetta ad errori.
Inoltre, non ho visto uno straccio di punto di estendibilit� il che mi fa pensare che salvare lo stato in un altro store non sia attualmete supportato.

A parte questo appunto, il controllo mi sembra ben fatto. Ora con l'UpdatePanel, l'UpdateProgress modale che tra poco prover� a sottomettere all'AjaxControlToolkit, e l'History si ha veramente la suite completa per rendere le applicazioni AJAX - Style veramente veramente complete.

Tags: AJAX, ASP.NET, ASP.NET 2.0, ASP.NET 3.5, ASP.NET AJAX

Continua a leggere Il controllo history di AJAX??? Carino ma....

Javascript e le tabelle create dinaamicamente

Stefano Mostarda — Fri, 02 Mar 2007 16:55:00 GMT

Sono un patito di FF. La cosa non riguarda questioni di sicurezza, o anti IE; semplicemente FF mi piace di pi�. Il target degli utenti per cui sto sviluppando ultimamente � tuttavia il classico utente che installa il Sistema operativo e lavora con IE.

Io, tutto sommato, continuo imperterrito a sviluppare con FF ed ogni tanto mi trovo davanti a problemi di compatibilit� Cross-Browser. Oggi l'ultimo: una tabella creata dinamicamente da javascript non funziona.

Il codice era questo:

var table = document.createElement("table");
var row = document.createElement("tr");
var cell = document.createElement("th");
cell.innerHTML = "value";
row.appendChild(cell);
table.appendChild(row);

Beh, con Firefox tutto ok, con IE la tabella non veniva mostrata. Dopo una decina di minuti di infruttuose ricerche su google mi convinco che il problema � talmente stupido che l'ho avuto solo io nella storia. Mi armo di pazienza e IE Developer Toolbar e comincio ad ispezionare l'HTML generato internamente da IE per visualizzare una tabella e mi accorgo che manca il tag TBODY.

Ebbene si, una volta creato il tag "table", si deve creare il tag "tbody" ed a questo vanno appese le righe. Infine questo va appeso alla tabella.

var table = document.createElement("table");
var tbody = document.createElement("tbody");
table.appendChild(tbody);
var row = document.createElement("tr");
var cell = document.createElement("th");
cell.innerHTML = "header" ;
row.appendChild(cell);
tbody.appendChild(row);

Lo posto qui cos� me lo ricordo quando mi ricapiter�.

Stay Tuned...

Tags: Javascript

Continua a leggere Javascript e le tabelle create dinaamicamente.

Abilitare i metadati con WCF

Stefano Mostarda — Fri, 08 Dec 2006 19:09:00 GMT

Nelle prime beta, ogni servizio esposto da WCF per default publicava i metadati cos� da permettere a qualunque client di creare un proxy. Questo comportamento � stato cambiato ed ora per default i servizi non danno queste informazioni. La cosa non rappresenta comunque un problema in quanto da configurazione si pu� risolvere il tutto in poche righe di app.config.

Basta agiungere al servizio un nuovo endpont che pubblichi i Metadati:

<endpoint address="" binding="mexTcpBinding" contract="IMetadataExchange"/>

Molta attenzione va data al binding. Questi, infatti, sono personalizzati per ogni protocollo supportato.Quindi abbiamo mexTcpBinding per il tcp, mexHttpBinding per l'HTTP e mexHttpsBinding per i canali HTTP protetti.
Una volta inserito l'endpoint si configura il behavior del servizio che specifica la pubblicazione dei metadati

<behaviors>
  <serviceBehaviors>
    <behavior name="Metadata">
      <serviceMetadata />
    </behavior>
  </serviceBehaviors>
</behaviors>

Per l'Http bisogna anche impostare l'attributo httpGetEnabled del nodo serviceMetadata per specificare che il WSDL � importabile con una semplice richiesta GET.

Per collegare il tuto si associa il behavior al servizio

<service name="MyService" behaviorConfiguration="Metadata">

Stay Tuned...

Tags: .NET Framework, .NET Framework 3.0, Windows Communication Foundation

Continua a leggere Abilitare i metadati con WCF.