Descriviamo un po’ la situazione in cui ci troviamo:

• abbiamo un web service (sviluppato in ASP.Net);
• vogliamo realizzare una libreria (class library .Net 3.5) per offrire una sorta di “interfaccia comune” verso il web service in modo tale che qualsiasi applicazione (in particolare applicazioni “stand alone” .Net) possa richiamare i servizi esposti senza troppi “grattacapi”.

Come si dovrebbe procedere: da Visual Studio (2008 SP1), nel progetto della nostra class library, si passa alla creazione di un “web-reference” (in relazione al web service in questione). Non serve fare altro: sulla carta non è necessaria alcuna particolare operazione sul progetto dell’applicazione che utilizza la nostra nuova class library. In realtà, se compilate ed eseguite il programma, potrete vedere da voi stessi che l’applicativo non è in grado di collegarsi al web service.

Qui di seguito il messaggio contenuto nell’eccezzione che viene generata quando tentate di accedere al web service: “Could not find default endpoint element that references contract ‘___’ in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.”

Motivo? Diciamo che i “riferimenti” o (entry point) al web service non vengono “copiati” dalla class library all’applicazione che la utilizza. Questi riferimenti sono contenuti nel file .config della class library (in dettaglio possiamo trovare tutte le informazioni all’interno del tag <system.serviceModel>). Il file .config della class libray, purtroppo, non “segue” la libreria nell’applicazione che la utilizza (se andate a vedere nella cartella bin del vostro applicativo, troverete solo il fiel .config relativo  a quest’ultimo).

Il problema è aggirabile manualmente: basta copiare tutto il contenuto del tag <system.serviceModel> dal file .config della class library a quello dell’applicazione (operazione fattibile ma assai scocciante).

Qui di seguito un esempio della parte da copiare.

<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="WebServiceSoap" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536" messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None" realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://_/_.asmx" binding="basicHttpBinding" bindingConfiguration="WebServiceSoap" contract="_" name="_" />
</client>
</system.serviceModel>

Per poter “scrivere” nel file .config dell’applicazione andate nel Solution Explorer del Visual Studio: tasto destro del mouse sul progetto in questione, andate alla voce Add nel menù che via appare  ed a questo punto cliccate sulla voce New Item.

A questo punto vi apparirà una nuova finestra: selezionate General nella parte sinistra ed Application Configuration File in quella destra. Qui di seguito un’immagine che illustra le operazioni appena elencate.

Bene! Tutto il contenuto del nuovo file .config (che  ritroverete nella lista dei file del vostro progetto) sarà ricopiato nel file .config “ufficiale” dell’applicazione.

Il problema sembra essere ben conosciuto, ma al momento non ho letto ancora nulla in merito ad una sua soluzione nel futuro Visual Studio 2010. Ho letto che la gestione dei file .config è stata migliorata permettendo una sorta di “diversificazione” tra debug e release, ma nulla circa il problema qui sopra evidenziato.

Segnalo che pochi giorni fa Microsoft ha rilasciato una bug-fix per Visual Studio 2008 e Visual Web Developer 2008 che risolve alcuni problemi con:

• la modalità view Source e Design view dell’ HTML designer;
• editor HTML e Javascript;
• modalità di build di un web site.

Molti sono i blog che segnalano questa notizia: io riporto come fonte il post di Pietro Brambati (Developer Evangelist).

Maggiori informazioni possono essere trovate qui e qui.

Segnalo questo interessantissimo post di Raffaele Rialdi (MVP di Microsoft) che riporta una serie di utilissimi link per capire le novità del Microsoft .Net Framework 3.5 e del Visual Studio 2008. Come potrete leggere dal suo articolo, presto pubblicherà anche le novità riguardanti la programmazione nativa in C++ su Visual Studio 2008… e spero che le renda on-line quanto prima

Chi conosce Raffaele Rialdi può facilmente immaginare il livello di qualità dei link da lui segnalati