ExeWatch 1.8: SDK .NET per WPF e WinForms, Custom Metrics, Health Monitoring e On Premise

TL;DR: ExeWatch 1.8 segna un passo importante: arriva l’SDK .NET/C# (WPF, WinForms, servizi), le custom metrics con grafici temporali, l’health monitoring automatico con notifiche, la condivisione delle applicazioni in sola lettura e — su richiesta di diverse aziende — la possibilità di deployment on premise. Provalo su exewatch.com

ExeWatch oltre il mondo Delphi

Quando ho presentato ExeWatch la prima volta, lo descrivevo come uno strumento di monitoraggio per applicazioni Delphi. Era la verità, ma era anche una visione parziale. I fondamentali che ExeWatch offre — logging strutturato, timing, breadcrumbs, device info, anomaly detection — non sono specifici di un linguaggio. Sono necessità universali di chiunque sviluppi software che gira “fuori dal browser”, dove i log di produzione sono storicamente difficili da ottenere.

Nelle ultime settimane abbiamo ricevuto richieste concrete da team che sviluppano in C# e che cercavano qualcosa con le stesse caratteristiche di ExeWatch ma per il mondo .NET. Non tool generici di APM pensati per microservizi cloud, ma qualcosa di mirato per applicazioni desktop, servizi Windows, WPF e WinForms.

Invece di dire “non è il nostro target”, abbiamo scritto l’SDK.

SDK .NET / C#

L’SDK .NET è ora disponibile con feature parity rispetto a quello Delphi. Supporta .NET 8.0+ su Windows e copre tutti gli scenari comuni:

• Console, WPF, WinForms, Windows Service — un unico pacchetto base, più un hook opzionale per WinForms (ExeWatch.WinForms) che cattura le eccezioni del thread UI
• Zero dipendenze NuGet — come per l’SDK Delphi, nessuna dipendenza esterna
• Stessa API — chi conosce l’SDK Delphi si troverà subito a casa
• Offline persistence — i log vengono salvati su disco prima dell’invio, con retry automatico
• Configurazione server-side — flush interval, batch size e sampling rate controllabili dal dashboard senza ridistribuire l’applicazione

L’inizializzazione è identica a quella Delphi:

using ExeWatch;

ExeWatchSdk.Initialize(new ExeWatchConfig
{
    ApiKey = "ew_win_your_key",
    CustomerId = "ACME-Corp"
});

EW.Info("Application started", "startup");

Da quel momento in poi, l’API è la stessa. Timing, breadcrumbs, metriche:

// Timing con categoria
EW.StartTiming("invoice.generate", "pdf");
// ... genera il PDF ...
EW.EndTiming("invoice.generate");

// Breadcrumb per tracciare il percorso utente
EW.AddBreadcrumb("Clicked Export", "ui");

// Counter e gauge
EW.IncrementCounter("invoices.generated", 1);
EW.RecordGauge("queue.size", pendingJobs.Count);

Per WinForms basta aggiungere una riga per catturare le eccezioni del thread UI:

using ExeWatch;
using ExeWatch.WinForms;

ExeWatchSdk.Initialize(config);
ExeWatchWinForms.Install();  // cattura Application.ThreadException

Il repository degli esempi include tre sample .NET completi: una console app, un’applicazione WinForms interattiva e un Windows Service.

Custom Metrics

Fino alla versione precedente, ExeWatch raccoglieva le metriche (counter e gauge) ma le mostrava solo come valori aggregati. Con la 1.8 le metriche hanno una pagina dedicata con grafici temporali.

Nella pratica, questo significa che puoi tracciare grandezze specifiche del tuo dominio applicativo e visualizzarle nel tempo accanto ai log e ai timing:

// Delphi — traccia metriche di business
EW.IncrementCounter('orders.processed', 1);
EW.IncrementCounter('orders.failed', 1);
EW.RecordGauge('queue.pending', FPendingQueue.Count);

// Gauge periodico — campionato automaticamente ogni 30 secondi
EW.RegisterPeriodicGauge('memory_mb',
  function: Double
  begin
    Result := GetCurrentMemoryMB;
  end);

// C# — stessa API
EW.IncrementCounter("orders.processed", 1);
EW.RecordGauge("connections.active", pool.ActiveCount);

Dalla pagina Metrics puoi anche cancellare i dati di una metrica specifica direttamente dalla modal di dettaglio, utile durante lo sviluppo o per ripulire dati di test.

Health Monitoring

Una delle domande più frequenti che ricevevamo era: “Come faccio a sapere se la mia applicazione sta andando bene senza guardare la dashboard ogni 5 minuti?”

La risposta è l’health monitoring. Ogni applicazione ha ora un Health Score calcolato automaticamente in base a tre parametri: error rate, crash e operazioni lente nelle ultime 24 ore. Lo stato risultante è uno fra Healthy, Degraded e Unhealthy.

Il sistema include una logica anti-flapping: non basta un singolo errore per far scattare un cambio di stato. Questo evita le notifiche inutili e riduce il rumore.

Quando lo stato di salute cambia, ExeWatch invia notifiche via email e, se configurato, via Discord attraverso webhook. Discord è stato aggiunto perché molti team lo usano come canale operativo e preferiscono ricevere le notifiche dove già lavorano.

Il livello di dettaglio del health monitoring dipende dal piano: il piano Hobby offre il monitoraggio base, il Pro aggiunge il monitoraggio basato sugli errori, il Business include l’analisi completa con timing e trend.

Condivisione applicazioni

Una funzionalità che non avevamo previsto ma che ci è stata chiesta da più parti: la possibilità di condividere un’applicazione in sola lettura con utenti esterni.

Lo scenario tipico: hai un cliente che vuole vedere lo stato della propria installazione senza che tu debba inviargli screenshot o report periodici. Con la condivisione read-only, gli dai accesso diretto alla dashboard della sua applicazione — log, timing, health — senza concedere permessi di modifica o accesso ad altre applicazioni dell’account.

Integrazione con DMVCFramework

Per chi sviluppa applicazioni server con DMVCFramework, abbiamo pubblicato un sample completo che mostra come integrare ExeWatch in un’applicazione web TemplatePro + HTMX.

L’integrazione sfrutta due meccanismi che DMVCFramework offre nativamente. Il primo è il callback appender di LoggerPro: tutte le LogI, LogW, LogE del framework — comprese quelle interne — vengono inoltrate automaticamente a ExeWatch.

SetDefaultLogger(
  CreateLogBuilderWithDefaultConfiguration
    .WriteToCallback
    .WithCallback(
      procedure(const ALogItem: TLogItem; const AFormattedMessage: string)
      begin
        if ExeWatchIsInitialized and (ALogItem.LogType > TLogType.Debug) then
          EW.Log(
            TEWLogLevel(Ord(ALogItem.LogType)),
            ALogItem.LogMessage,
            ALogItem.LogTag,
            ALogItem.TimeStamp,
            ALogItem.ThreadID);
      end).Done.Build);

Il secondo è il profiler integrato di DMVCFramework. Dato che il logger è già collegato a ExeWatch, il timing di ogni controller action viene tracciato automaticamente:

Profiler.ProfileLogger := Log;
Profiler.WarningThreshold := 500;           // warning se action > 500ms
Profiler.LogsOnlyIfOverThreshold := False;  // logga sempre, non solo i lenti

Con queste poche righe nel .dpr, tutta l’applicazione è monitorata senza toccare i controller. Il sample poi mostra le funzionalità avanzate dove servono davvero — ad esempio, extra data strutturati quando un batch import fallisce parzialmente:

// Ogni riga fallita viene loggata con contesto strutturato
LRowExtra := TJSONObject.Create;
LRowExtra.AddPair('row_number', TJSONNumber.Create(I + 1));
LRowExtra.AddPair('first_name', LFirstName);
LRowExtra.AddPair('last_name', LLastName);
LRowExtra.AddPair('error', LReason);
EW.Log(llWarning, Format('Import failed for row %d: %s %s (%s)',
  [I + 1, LFirstName, LLastName, LReason]), 'people', LRowExtra);

// Il summary include l'array completo delle righe fallite
LExtra := TJSONObject.Create;
LExtra.AddPair('total_rows', TJSONNumber.Create(10));
LExtra.AddPair('imported', TJSONNumber.Create(LImported));
LExtra.AddPair('failed', TJSONNumber.Create(LFailed));
LExtra.AddPair('failed_rows', LFailedRows);  // TJSONArray con il dettaglio
EW.Log(llWarning, 'Batch import: 7 imported, 3 failed', 'people', LExtra);

Aprendo il log nella dashboard ExeWatch, l’extra data è visibile in formato strutturato — non più un messaggio testuale da interpretare, ma dati navigabili.

Repository pubblico con tutti gli esempi

Abbiamo pubblicato un repository GitHub con esempi di integrazione per tutti gli SDK e per le diverse tipologie di applicazione: github.com/danieleteti/ExeWatchSamples.

Ogni esempio include un README dettagliato e può essere compilato e avviato in pochi minuti. L’API è volutamente uniforme tra gli SDK, quindi passare da un linguaggio all’altro è immediato:

// Delphi
EW.Info('User logged in', 'auth');
EW.StartTiming('db.query', 'database');
EW.AddBreadcrumb('Search: "invoice 2024"', 'search');

// C# — stessa struttura
EW.Info("User logged in", "auth");
EW.StartTiming("db.query", "database");
EW.AddBreadcrumb("Search: \"invoice 2024\"", "search");

// JavaScript — stessa struttura
ew.info("User logged in", "auth");
ew.startTiming("db.query", "database");
ew.addBreadcrumb("Search: \"invoice 2024\"", "search");

On Premise

Diverse aziende ci hanno contattato per chiedere se fosse possibile installare ExeWatch nella propria infrastruttura. Le motivazioni sono quelle prevedibili: policy aziendali che impediscono l’invio di dati telemetrici a servizi esterni, requisiti di compliance settoriale, esigenze di latenza o semplicemente la preferenza per il controllo diretto dell’infrastruttura.

Abbiamo aggiunto l’opzione On Premise alla pagina pricing. Non è un piano self-service: richiede una trattativa diretta perché ogni installazione ha esigenze diverse in termini di sizing, backup, aggiornamenti e supporto. Chi è interessato può scriverci a exewatch@bittime.it.

Webinar e ITDevCon

Il 24 marzo alle 15:00 terrò un webinar dedicato a ExeWatch e alle applicazioni Delphi VCL. Dopo il primo video di presentazione in inglese, questo sarà in italiano e pensato per chi sviluppa applicazioni desktop con Delphi. Vedremo l’integrazione passo-passo, le funzionalità avanzate e come sfruttare al meglio la dashboard. A breve seguiranno webinar in inglese e spagnolo.

Per iscriverti: Registrazione webinar ExeWatch

Alla prossima ITDevCon 2026 Spring Edition (in italiano) terrò uno speech su ExeWatch dove entrerò nel dettaglio delle integrazioni e delle funzionalità avanzate — quelle che una volta scoperte non vorrai più farne a meno.

Cosa c’è dopo

Il lavoro procede su due fronti. Sul backend stiamo migliorando l’anomaly detection per renderla più granulare. Sul fronte SDK, il prossimo candidato è Python — molte applicazioni desktop usano PyQt o Tkinter e hanno le stesse esigenze di monitoraggio.

Se usi già ExeWatch, tutte le novità della 1.8 sono già disponibili nel tuo account. Se non lo hai ancora provato, il piano Hobby è gratuito e non richiede carta di credito.

Link e Risorse

• Sito ufficiale: exewatch.com
• Changelog completo: exewatch.com/ui/changelog
• Esempi di integrazione: github.com/danieleteti/ExeWatchSamples
• Webinar 24 marzo: Registrazione
• ITDevCon 2026 Spring Edition: itdevcon.it - La conferenza Delphi europea
• Articolo precedente: ExeWatch 1.6: Updates Tracking e Usage Analytics

ExeWatch — Monitoring per applicazioni server, desktop e web. Creato da bit Time Professionals.