Spesso accade di ricevere dei misteriosi e noiosi timeout utilizzando WCF lato silverlight per raggiungere i propri servizi sul server senza traccia alcuna di precise eccezioni .NET. Quasi sempre il problema è da ricercarsi nei file di configurazione. Altre volte nella tipologia di entità restituite dal server. Un modo per scovare i veri errori in queste situazioni misteriose è quello di utilizzare gli strumenti di diagnistica standard di Windows Communication Foundation. Sostanzialmente dopo aver opportunamente attiviato il tracciamento delle attività WCF ed eventualmente dei messaggi con l'apposito tool:

  i file prodotti con estensione ".svclog" possono essere aperti direttamente con un doppio click da Shell/Explorer provocando il caricamento del file di trace direttamente nell'apposito visualizzatore:

  WCF Trace Viewer:

Nella colonna sinistra e' possibile rintracciare le attivita' di comunicazione con errori selezionando le righe in rosso. Nei pannelli nella parte destra a partire dall'alto e' ancora possibile selezionare ed entrare nel dettaglio della intera comunicazioni in tutte le parti elementari che la costituiscono ed e' ancora possibile selezionare le righe rosse per ispezionare meglio trace di errori e altri messaggi essenziali per il debug nei pannelli subito sotto come mostrato nella grafica.

Infine, come suggeritomi da Juwal Lowy in una sua mail sul thread dei Regional Director MSDN di oggi un ulteriore modo e' descritto nel suo libro al capitolo 6:

http://www.amazon.com/Programming-WCF-Services-Juval-Lowy/dp/0596521308/ref=sr_1_1?ie=UTF8&s=books&qid=1226789196&sr=1-1

Giuseppe

Mi sono imbattuto in questo post:

http://blogs.msdn.com/cesardelatorre/archive/2010/04/30/using-entity-framework-self-tracking-entities-with-appfabric-cache-velocity-and-net-4-0-rtm.aspx

sostanzialmente il serializzatore di Velocity non riconosce le collezioni TrackableCollection come serializzabili perché manca l'apposito attributo. Aggiungendo opportunametne l'attributo [CollectionDataContract] come suggerito nel post il problema é risolto.

Giuseppe

Come dimostrato da un case study pubblicato da Microsoft Corp, basato su un lavoro di conversione di SIS-Evolution, con VB Migration Partner  è stato  possibile convertire, in sole 2,5 ore, 25.000 linee di codice comprendente le funzioni più critiche di un’aplicazione di totali 950.000 linee di codice VB6.
Il prodotto della conversione è stato un sorgente .net compilabile e un eseguibile funzionante. Un risultato ancora più significativo se confrontato a quello delle 13 ore impiegate dal più vicino concorrrente tra i sei migliori prodotti di migrazione selezionati dalla stessa SIS-Evolution.
Di notevole importanza la possibilita di VB Migration Partner di essere customizzato per raggiungere livelli di efficienza molto elevati  (opportunità di cui la SIS-Evolution non ha comunque usufruito).
SIS-Evolution, azienda Austriaca con la necessità di convertire un’applicazione VB6 mission critical, ha impiegato tre programmatori che migrando 50.000 linee al mese hanno raggiunto il notevole traguardo di migrare l’applicazione completa in soli nove mesi, grazie anche  alle capacità, come testimonia la  SIS-Evolution, di riprodurre fedelmente anche l’interfaccia utente dell’applicazione d’origine.

Maggiori dettagli in un articolo di Francesco Balena raggiungibile con questo link.
http://www.vbmigration.com/Blog/post/2009/12/CASE-STUDY-SIS-Evolution-becomes-official-Microsoft-Corp-case-study.aspx

In questo periodo sto facendo molta consulenza per aziende italiane alle prese con la migrazione da VB6, usando ovviamente la versione preliminare di VB Migration Partner. Oramai la beta è stabile e si comporta davvero molto bene. In un solo giorno, ad esempio, abbiamo migrato una applicazione di circa 20mila righe che lavora in modo intensivo con ADO in circa mezza giornata, e tutto funziona a meraviglia!

Anche se la migrazione sta andando bene, a volte i programmi migrati sono più lenti del codice VB6 originario. Per esperienza le cause sono principalmente due: (1) l'uso di COM Interop per accedere agli oggetti ADO, (2) un uso massiccio di concatenazione di stringhe. Per il primo problema non c'è molto da fare, purtroppo: occorre migrare il codice di accesso al database da ADO a ADO.NET, un compito più semplice a dirsi che a farsi. Per il secondo problema ci sarebbe invece una soluzione semplice: basterebbe sostituire la variabile stringa con una variabile StringBuilder, e le concatenazioni sarebbero automaticamente più veloci. Peccato che questa sostituzione comporti una revisione completa del codice, perchè richiede di trasformare tutti gli operatori & (concatenazione) con il metodo Append, per non parlare dei casi in cui la variabile stringa viene usata come argomento a funzioni come Trim o Left. Ad esempio, il seguente codice richiede ben 17 secondi sul mio sistema a 3GHz:

Dim s As String = ""
Dim sw As Stopwatch = Stopwatch.StartNew()
For i As Integer = 1 To 100000
    s = s + "*"
Next
MsgBox(sw.Elapsed.ToString)

Per fortuna la soluzione è davvero semplice: basta creare una classe che utilizzi internamente un oggetto StringBuilder, che ridefinisca gli operatori & e +, e che supporti la conversione implicita da-a stringa. Il codice di questa classe StringBuilder6 si scrive davvero in pochi minuti:

Imports System.Text

Public Class StringBuilder6

    Private buffer As New StringBuilder

    ' return the inner string

    Public Overrides Function ToString() As String
        Return buffer.ToString()
    End Function

    Public Shared Operator +(ByVal op1 As StringBuilder6, ByVal op2 As String) As StringBuilder6
        op1.buffer.Append(op2)
        Return op1
    End Operator

    Public Shared Operator &(ByVal op1 As StringBuilder6, ByVal op2 As String) As StringBuilder6
        op1.buffer.Append(op2)
        Return op1
    End Operator

    ' convert to string

    Public Shared Widening Operator CType(ByVal op As StringBuilder6) As String
        Return op.ToString()
    End Operator

    ' convert from string

    Public Shared Widening Operator CType(ByVal str As String) As StringBuilder6
        Dim op As New StringBuilder6()
        op.buffer.Append(str)
        Return op
    End Operator

End Class

A questo punto per velocizzare il codice visto prima è sufficiente modificare UNA SOLA ISTRUZIONE, ovvero la dichiarazione della variabile stringa:

Dim s As StringBuilder6 = ""

Dopo questa sostituzione, il ciclo visto prima viene eseguito in 8 millesimi di secondo, ovvero circa 2000 volte più velocemente!!! Non male, per una fix così semplice

Indipendentemente dal fatto che state migrando codice da VB6 o se avete scritto codice VB.NET (o C#) da zero: se trovate dei punti in cui fate uso massiccio di concatenazione di stringhe e che pensate possano rallentare l'esecuzione, provate a sostituire la variabile stringa con un oggetto StringBuilder6: in alcuni casi il programma girerà molto ma molto più velocemente.