Per quanto possiamo testare e debuggare un applicativo web localmente tramite Visual Studio, quando lo mettiamo in produzione la realtà che si presenta è sempre differente. Gli utenti con in grado di creare situazioni non previste e capire come si sta comportando il nostro applicativo è sempre fondamentale.

Per questi scopi viene in aiuto Application Insight, il servizio cloud di Microsoft che fornisce metriche, statistiche, ma tiene anche traccia degli errori che si sono verificati. Possiamo sfruttarlo per applicativi ospitati sul cloud, ma anche on premises. Oltre ad avere un riepilogo della tipologia di errori e quante volte si verificano, possiamo avere il dettaglio di ognuno di essi. Nel caso di applicativi .NET possiamo visualizzare anche lo stack trace dell'eccezione dandoci un grande aiuto, anche se questo spesso non è sufficiente.

Di recente è stata aggiunta la possibilità di debuggare queste eccezioni attraverso lo snapshot debugging. In pratica, uno speciale collector del SDK di Application Insight, monitora le eccezioni e quando si verificano, con un processo esterno, crea un minidump che, unito ai simboli (file pdb), permette in qualsiasi momento di effettuare il debug a posteriori.

Questa funzionalità può essere sfruttata negli applicativi .NET, web app o cloud service, sviluppati sia con .NET Core o con il .NET Framework. Ponendo di avere un applicativo con gli insight già abilitati, è sufficiente installare il nuovo pacchetto Microsoft.ApplicationInsights.SnapshotCollector. Oltre alla dll, il pacchetto referenzia anche delle dll native e un processo che serve poi per collezionare il minidump.

Occorre a questo punto abilitare la telemetria. Nel caso di un'app .NET Core dobbiamo creare un ITelemetryProcessorFactory che istanzi il SnapshotCollectorTelemetryProcessor.

public class SnapshotCollectorTelemetryProcessorFactory : ITelemetryProcessorFactory
{

    public ITelemetryProcessor Create(ITelemetryProcessor next)
    {
        var snapshotConfigurationOptions = new SnapshotCollectorConfiguration
        {
            // Quante volte si deve verificare l'errore prima di effettuare lo snapshot
            ThresholdForSnapshotting = 3,
            // Quanti esempi di snapshot fari per lo stesso errore
            MaximumSnapshotsRequired = 1,
            // Numero di errori da monitorare contemporaneamente
            MaximumCollectionPlanSize = 50,
            // Ogni quanto resettare il numeri di errori
            ProblemCounterResetInterval = TimeSpan.FromHours(6),
            // Numero massimo di snapshot al giorno
            SnapshotsPerDayLimit = 10,
        };
        return new SnapshotCollectorTelemetryProcessor(next, snapshotConfigurationOptions);
    }
}

// Nello Startup file
public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton<ITelemetryProcessorFactory, SnapshotCollectorTelemetryProcessorFactory>();
}

Quando creiamo il processor dobbiamo passare anche una configurazione, fondamentale nella sua taratura. Come possiamo vedere nei commenti, ci permette di indicare quante volte è necessario che si verifichi un'eccezione, prima di effettuare il dump, oppure quanti dump fare al giorno. Sebbene la creazione del dump impatta minimamente l'applicativo, anche se in produzione, ogni minidump è grande almeno 60MB, perciò è fondamentale mettere valori che non facciamo lavorare inutilmente il sistema.

Fatta la configurazione possiamo pubblicare e vedere se compaiono errori nel portale degli Application Insight. Nel solito pannello di dettaglio di un errore, però, compare la voce Open debug session.

Essa apre direttamente sul portale lo stack trace con le variabili e i rispettivi valori al momento dell'errore.

Tramite il pulsante che troviamo in questo schermata possiamo aprire lo stesso stack all'interno di Visual Studio 2017, previa installazione dell'estensione, scaricabile da http://aspit.co/bk6