In questi giorni di vacanza mi sono ritrovato a leggere alcuni articoli che riguardavano i vari metodi per implementare l'hiding e l'override dei metodi di una classe in C#.

La questione personalmente mi è sempre sembrata pedante e assolutamente poco interessate, ma da contraltare spesso mi sono accorto che questa parte nasconde diverse insidie: per tale motivo ho pensato di scriverne un post sopratutto per averne un memento.

Inizierà il post espondendo alcune note iniziali al fine di inquadrare meglio il problema.

La questione in analisi riguarda la situazione in cui si scrive un metodo in una classe base, e in una classe da questa derivata, si riscrive un metodo con stessa firma (cioè con stesso, lista parametri e valore di ritorno).

Oss.: Qui si parlerà di metodi, ma tutto quanto esposto vale anche per le proprietà esposte dalla classe.

Occorre dire che in situazione "normali" il metodo implementato all'interno della classe derivata “sovrascrive” il metodo della classe base: detto in altri termini se instanzia la classe derivata il metodo sovrasrcitto della classe base verrà ignorato, e verrà eseguito, come ci si aspetta (?) , il codice implementato all'interno del metodo della classe derivata.

Per quanto ci si impegni a farcire il nostro software di report statistiche, estrazioni dati, analisi aggregate, è matematico che a un certo punto salta sempre fuori il rompiscatole (ehm... volevo dire l'esperto) di turno che ci farà la solita lanconica richiesta: avere un'estrazione automatica di alcuni dati.

Ovviamente detta analisi deve avvenire periodicamente e inviare il risultato finale via excel, per poter eseguire poi delle post-elaborazioni.

Siccome questa statistica è importantississimissssssssssssssima deve giungere tassativamente entro la mattina, e pertanto l'elaborazione deve avvenire la notte precedente.

Sono certo che chi fa il lavoro di (tentativo di) programmatore si sarà sentito rivolgere questa richiesta centinaia di volte, magari con declinazioni e variazioni varie, ma con la medesima sostanza.

Siccome il cliente committente ha sempre ragione, sopratutto se paga, occorre trovare il modo di soddisfare detta richiesta.

Il primo problema classico che occorre risolvere è che generalmente sul server dove deve avvenire l'elaborazione NON è installato office, per cui non possiamo usare l'office automation (Microsft Office Object Library).

Attenzione: Esiste un'ampia letteratura in merito. Installare office o altri software desktop-centrici sul server è cattiva prassi, e deve essere evitato.

Pertanto non ci si può rivolgere a office: come fare ?!

Esistono alcune soluzioni.

1) Creare il file in formato csv, che può essere importato da excel e per la cui generazione non è necessario alcun ausilio particolare.

2) Usare una qualche libreria per creare file excel o formati compatibili che non necessitino della presenza di excel.

3) Convincere il cliente che non ha bisogno di alcun estrazione.

Ampiamente previsto dagli specialisti è arrivata la variante di WannaCry: il suo nome è Petya, ma per alcuni è WannaCry v2 o anche WannaCry v3.

Anche in questo caso si tratta di un ramsonware che cripta i file sul pc oggetto, e li rende inutilzzaibili sino a quando non si paga un riscatto.

Purtroppo le sue caratteristiche lo rendono più aggressivo del suo predecessore: questo è anche dovuto al fatto che mentre i computer che per primi sono stati infettati da WannaCry, e che successivamente hanno creato l'effetto valanga che ha interessato tutto il mondo, erano poche centinaia di unità, nel caso di Petya sembra che il ceppo iniziale sia stato depositato su milioni di computer, grazie all'hacking di un famoso sito ucraino che distribuisce anche aggiornamenti software.

Il metodo è quello già conosciuto: quando il ramsonware infetta un pc cripta tutti i file ivi contenuti, e successivamente lo stesso pc infetta tutti gli altri pc presenti nella stessa LAN.

Mentre WannaCry usava come metodo di propagazione il vecchio SMB v1, Petya usa anche WMIC,Windows Management Instrumentation Commandline.

Oss.: SMB è il protocollo che viene usato dai computer Windows per rendere file e cartelle via share di rete. Di questo protocollo ne esistono diverse versioni, e in modo silente quando due computer vogliono scambiarsi file si accordano su quale versione usare. La versione 1 del protocollo, vecchia di 30 anni, è ancora utilizzata in molti ambiti: per esempio se uno dei pc coinvolti è XP, oppure se insistono in rete vecchissime versione di Linux.

Oss.: WMIC è un pezzo di WMI Windows Management Instrumentation, che in pratica permette di interrogare un pc remoto ottenendo da questo alcune le sue caratteristiche ed eventualmente modificarne altre.

Avete un fantastico software che viene eseguito in console mode ??

Avete necessità di dotarlo di una progress bar per farlo sembrare "più figo" ??

Per quanto possa essere figa una Console App ovviamente......

Allora questo post fa per Voi !

Recentemente mi trovavo in una situazione simile, e dopo aver ricercato in rete ho trovato la seguente soluzione, elegante ed efficace, che desidero condividere con Voi.

Infatti è inutile inventarsi soluzioni esotiche e/o personalizzate: affidatevi senza timore al pacchetto NuGet ShellProgressBar: è semplice, gratuito (MIT License) e funziona perfettamente.

Vi assicuro di non centrare assolutamente nulla con l'autore del software oggetto di questo scritto (tra l'altro gratuito): semplicemente è un buona soluzione che intendo condividere.

Sono certo che in giro si trovano altre soluzione molto più articolate, ma questa che presente è realmente semplice e ritengo più che soddisfacente per la maggior parte degli usi.