DDL

Errori WCF “poco chiari”

Ormai lavoro sempre attraverso servizi WCF per tre principali motivi:

• Spesso mi trovo a dover delocalizzare geograficamente i miei programmi per cui avere l’accesso ai dati vicino al DB non va mai male
• Non devo installare la connessione al DB a tutte le macchine client (attualmente uso Oracle XE come DB)
• Se devo cambiare qualcosa, spesso il problema è lato servizi e posso rimediare senza “disturbare” gli utenti.

Purtroppo spesso WCF è criptico nella segnalazione degli errori e molto frequentemente ritorna una eccezione del tipo “The connection was closed unexpectedly” che non aiuta molto nella soluzione del problema, anche se ho incluso la seguente voce nel file di configurazione:

<serviceDebug includeExceptionDetailInFaults="true" />

All’ennesimo errore ho “googlato” un po’ scoprendo questa pagina che spiega come abilitare e analizzare la traccia dei servizi WCF.
“Basta” aggiungere una parte di configurazione al web.config del servizio

<system.diagnostics>
    <trace autoflush="true" />
    <sources>
            <source name="System.ServiceModel" 
                    switchValue="Information, ActivityTracing"
                    propagateActivity="true">
            <listeners>
               <add name="sdt" 
                   type="System.Diagnostics.XmlWriterTraceListener" 
                   initializeData= "SdrConfigExample.e2e" />
            </listeners>
         </source>
    </sources>
</system.diagnostics>

sulla pagina sopra riportata trovate tutte le possibili configuazione del tracing.Vorrei solo sottolineare che l’attributo “initializeData” consente di definire il nome del file di trace e può essere un path completo, nel caso venga utile e che l’attributo “switchValue” permette di decidere il livello di tracing desiderato.Il file di trace così prodotto può essere aperto con l’utility “SvcTraceViewer” che organizza il file in maniera molto più leggibile.Alla fine il vero problema era “Maximum number of items that can be serialized or deserialized in an object graph is '65536'”, risolto aggiungendo la seguente configurazione alla sezione del serviceBehaviors:

<dataContractSerializer maxItemsInObjectGraph="2147483647" />

Spesso nelle mie LOB applications mi trovo a dover gestire messaggi belli “cicciotti”… ma questo potrebbe essere materiale per un altro post

posted @ venerdì 19 agosto 2011 14:13