Umar's Blog

estendere un’applicazione asp.net con plugin/estensioni

umarja — Mon, 27 Apr 2009 13:15:00 +0000

Un’applicazione ben scritta è un’applicazione che piace, ma un’applicazione ben scritta e che può essere migliorata, è il massimo. In questo tutorial spiegherò come creare e mettere in produzione un completo framework per la creazione di plugin o estensioni (io preferisco chiamarle estensioni) che permetterà di estendere e/o modificare il comportamento delle proprie applicazioni scrivendo una decina di righe di codice.

Prima di cimentarci nella scrittura di codice è bene chiarire due concetti: che cosa si intende per estensione e come funziona il framework.

Per estensione si intende una libreria che viene inserita nella cartella Bin dell’applicazione. Per semplicità e per maggiori performance ho preferito caricare una sola estensione da ogni assembly, quindi ogni assembly può contenere solo un’estensione.

Il framework ha un funzionamento molto semplice: All’avvio dell’applicazione (Application_Start nel Global.asax), si caricano tutti gli assebly contenente estensioni e si caricano anche queste. Dopo di ché le si inizializzano ed il gioco è fatto.

Il framework richiede che ogni estensione implementi un’interfaccia: IExtension. L’interfaccia IExtension presenta un unico metodo: Initialize; Quest’ultimo viene chiamato dall’applicazione (di solito) nell’evento Application_Start e il suo unico scopo è quello di inizializzare le proprietà e oggetti correlati.

Il punto di incontro tra un’applicazione ed il framework sono gli eventi: Nell’evento Initialize ogni estensione aggiungerà un handler ad un evento statico di un oggetto che interessa all’estensione. Questo permette di creare un’interfaccia globale delle estensioni che poi provvederanno da sole al proprio ciclo di vita. Ad esempio supponiamo di avere un Blog con un oggetto Post e che quest’ultimo abbia un evento Show statico. Ogni volta che il Blog mostrerà il post, scatenerà l’evento Show, che, richiamerà a sua volta ogni handler associato e quindi anche le estensioni che vogliono modificare il comportamento per la visualizzazione dei post. Semplice no?

Il primo passo è la definizione del Framework, quindi dell’interfaccia IExtension e di una classe che gestisca le estensioni caricate. Creiamo quindi un nuovo progetto web di nome MyApplication, e aggiungiamo un’altro progetto C# Library che chiamiamo MyApplication.Extensibility.

Poi aggiungiamo un un’interfaccia, IExtension.cs nel profetto del framework (MyApplication.Extensibility) e scriviamo il seguente codice:

    1 namespace MyApplication.Extensibility
    2 {
    3     public interface IExtension
    4     {
    5         void Initialize();
    6     }
    7 }

L’interfaccia è molto semplice: espone solo il metodo Initialize. Ora passiamo alla creazione di una classe (ExtensionsManager) che gestirà tutte le estensioni caricate:

    1 namespace MyApplication.Extensibility
    2 {
    3     public class ExtensionManager
    4     {
    5 
    6         private static ExtensionManager m_Instance;
    7         private List<IExtension> m_Extensions = new List<IExtension>();
    8 
    9         public ExtensionManager() { }
   10 
   11         public void CollectExtensions(string configurationSection)
   12         {
   13             ExtensionsConfigurationSection section = (ExtensionsConfigurationSection)WebConfigurationManager.GetSection(configurationSection);
   14 
   15             if (!section.Enabled)
   16                 return;
   17 
   18             foreach (ExtensionElement extension in section.Extensions)
   19             {
   20                 if (extension.Enabled)
   21                     m_Extensions.Add((IExtension)Activator.CreateInstance(Type.GetType(extension.TypeName)));
   22             }
   23         }
   24 
   25         public void InitializeExtensions()
   26         {
   27             foreach (IExtension extension in m_Extensions)
   28             {
   29                 extension.Initialize();
   30             }
   31         }
   32 
   33         public List<IExtension> Extensions
   34         {
   35             get { return m_Extensions; }
   36         }
   37 
   38         public static ExtensionManager Instance
   39         {
   40             get
   41             {
   42                 if (m_Instance == null)
   43                     m_Instance = new ExtensionManager();
   44 
   45                 return m_Instance;
   46             }
   47         }
   48 
   49     }
   50 }

La prima cosa da notare dopo la lettura del codice è la presenza di un field di tipo ExtensionsManager, infatti questo field permette di rendere una classe Singleton, cioé una sola istanza della classe per tutto il ciclo dei vita dell’applicazione. La seconda cosa particolare è il riferimento alla classe ExtensionsConfigurationSection. Quest’ultima non è altro che una classe che definisce una sezione personalizzata all’interno di web.config. Dato che parlare dei files di configurazione è fuori dal tema del post, rimando ad un link dell’msdn: ConfigurationSection. Per il resto è molto semplice: Si utilizza la proprietà statica Instance per accedere all’istanza della classe e si richiama il metodo CollectExtensions che non fa altro che leggere tutte le estensioni definite del file web.config e aggiungerle alla collezione interna di estensioni (Extensions). Dopo aver caricato le estensioni, le si inizializzano utilizzando il metodo InitializeExtensions. Il tutto verrà eseguito nel file Global.asax.

Nel file di codice è presente la classe ExtensionsConfigurationSection.

Ora che si è creato il framework per l’estensibilità si può passare al ritrovamento e caricamento delle estensioni definite: andiamo nel file Global.asax del progetto Web e scriviamo quanto segue

    1 void Application_Start(object sender, EventArgs e)
    2         {
    3             ExtensionManager manager = ExtensionManager.Instance;
    4             manager.CollectExtensions(“MyApplication.Extensibility”);
    5             manager.InitializeExtensions();
    6         }

Le estensioni vengono caricate all’avvio del programma, così si evita di caricarle ogni volta che se ne ha bisogno. Non dovrebbero creare troppo overhead, anzi per niente se si utilizza il metodo descritto in questo post. Il metodo CollectExtensions accetta un parametro che indica il nome della sezione del file web.config.

Ora che il framework è pronto, le estensioni vengono caricate, mancano solo due cose: le estensioni e la parte ‘Core’ del programma, cioé tutte le classi che il nostro programma vuole esporre alle estensioni.

Il Core dell’applicazione d’esempio che ho creato è molto semplice: essendo il mio applicativo un editor di codici BBCode (quella sintassi usata spesso nei forum per sostituire l’HTML, ad esempio il tag [B] sostituisce il tag dell’HTML. BBCode è stato creato semplicemente per non permettere all’utente di scrivere tag HTML, evitando code injections ecc..) ho definito una classe Document molto semplice ed una classe DocumentParser un po piu’ interessante:

    1 public delegate void DocumentEventHandler(object sender, DocumentEventArgs e);

    2

    3 public class DocumentEventArgs : EventArgs

    4 {

    5

    6     public DocumentEventArgs(string documentText)

    7     {

    8         this.DocumentText = documentText;

    9     }

   10

   11     public string DocumentText { get; set; }

   12

   13 }

   14

   15 public class Document

   16 {

   17

   18     public Document(string name, string author, string text)

   19     {

   20         Name = name;

   21         Author = author;

   22         Text = text;

   23     }

   24

   25     public string Name { get; set; }

   26

   27     public string Text { get; set; }

   28

   29     public string Author { get; set; }

   30

   31     public static void OnServing(object sender, DocumentEventArgs e)

   32     {

   33         if (Serving != null)

   34             Serving(sender, e);

   35     }

   36

   37     public static void OnParsing(object sender, DocumentEventArgs e)

   38     {

   39         if (Parsing != null)

   40             Parsing(sender, e);

   41     }

   42

   43     public static event DocumentEventHandler Serving;

   44

   45     public static event DocumentEventHandler Parsing;

   46

   47 }

classe DocumentParser:

    1 public class DocumentParser

    2 {

    3

    4     private Dictionary<string, string> BasicTags;

    5

    6     public DocumentParser()

    7     {

    8         BasicTags = new Dictionary<string, string>()

    9         {

   10             { “[B]“, “” },

   11             { “[/B]“, “” },

   12             { “[I]“, “” },

   13             { “[/I]“, “” },

   14             { “[A]“, “ },

   15             { “[/A]“, “\” >” }

   16         };

   17     }

   18

   19     public string Parse(Document document, bool raiseEvents)

   20     {

   21         string parsed = document.Text;

   22

   23         foreach (KeyValuePair<string, string> tag in BasicTags)

   24         {

   25             parsed = parsed.Replace(tag.Key, tag.Value);

   26         }

   27

   28         if (raiseEvents)

   29         {

   30             DocumentEventArgs args = new DocumentEventArgs(parsed);

   31             Document.OnParsing(this, args);

   32             parsed = args.DocumentText;

   33         }

   34

   35         return parsed;

   36     }

   37

   38     public string Show(Document document, bool raiseEvents)

   39     {

   40         string newText = document.Text;

   41

   42         newText = newText.Insert(0, “
”);

   43         newText += “
”;

   44

   45         if (raiseEvents)

   46         {

   47             DocumentEventArgs args = new DocumentEventArgs(newText);

   48             Document.OnServing(this, args);

   49             newText = args.DocumentText;

   50         }

   51

   52         return newText;

   53     }

   54

   55 }

La classe Document è molto semplice: espone le proprietà Name (Nome), Text (Corpo), Author (Autore) e due eventi, ai quali le estensioni andranno ad aggiungere un handler nel caso il documento venga mostrato (Serving) o durante la fase di parsing del BBCode (Parsing).

La classe DocumentParser non è altro che una classe che sostituisce i tag BB con quelli HTML nel metodo Parse ed aggiunge il testo tra due tag ‘pre’ nel metodo Show. Entrambi i metodi accettano un parametro boolean chiamato raiseEvents che permette di ignorare l’azione delle estensioni, in quanto gli eventi ai quali sono registrati, non vengono scatenati.

E’ meglio provare subito il codice. Quindi si crea una semplice pagina con una TextBox che contiene il testo, un pulsante ‘Transform’ che effettua il parsing e mostra il risultato in una Label. Inoltre è presente anche una CheckBox che indica se gli eventi devono essere scatenati o meno.

Come si può notare, la pagina è molto semplice. Passiamo al codice:

    1 protected void Page_Load(object sender, EventArgs e)

    2 {

    3 }

    4

    5 protected void ButtonTransform_Click(object sender, EventArgs e)

    6 {

    7     Document document = new Document(“Semplice Documento”, “Umar Jamil”, TextBoxDocument.Text);

    8     DocumentParser parser = new DocumentParser();

    9

   10     string parsed = parser.Parse(document, CheckBoxRaiseEvents.Checked);

   11     document.Text = parsed;

   12     LabelTransformed.Text = parser.Show(document, CheckBoxRaiseEvents.Checked);

   13 }

Si crea un documento, si specifica il nome, l’autore ed il contenuto. Poi si crea un’istanza della classe DocumentParser, si effettua il parsing e si mostra il risultato nella label LabelTransformed. Da notare l’uso del metodo Show della classe DocumentParser per mostrare il documento.

Proviamo a lanciare il programma scrivendo un testo che contiene tag del tipo [B], [I] e notiamo l’effetto: l’output verrà formattato usando tag HTML.

Ma l’obiettivo dell’articolo non è mica creare un editor di testo, ma è quello di creare un editor di testo estendibile. Quindi cominciamo la fase di scrittura dell’estensione: creiamo un nuovo progetto, di tipo class library e chiamiamolo ParsingExtensions, dopodiché aggiungiamo una classe DateExtension con questo codice:

    1 namespace ParsingExtensions

    2 {

    3     public class DateExtension : IExtension

    4     {

    5

    6         #region IExtension Members

    7

    8         public void Initialize()

    9         {

   10             Document.Parsing += new DocumentEventHandler(Document_Parsing);

   11             Document.Serving += new DocumentEventHandler(Document_Serving);

   12         }

   13

   14         void Document_Serving(object sender, DocumentEventArgs e)

   15         {

   16             e.DocumentText += “
Modified by Date Extension 1.0
”;

   17         }

   18

   19         void Document_Parsing(object sender, DocumentEventArgs e)

   20         {

   21             e.DocumentText = e.DocumentText.Replace(“[DATE]“, DateTime.Now.ToShortDateString());

   22         }

   23

   24         #endregion

   25

   26     }

   27 }

Ovviamente bisogna aggiungere i vari riferimenti: Business Layer, Data Layer e ovviamente al framework… cioé tutti quelli di cui l’estensione ha bisogno per funzionare.

Analizziamo l’estensione: non fa altro che aggiungere una data ogni volta che incontra il tag [DATE] e ogni volta che il documento è mostrato, aggiunge del testo finale indicando che il testo è stato modificato dall’estensione. Notiamo che nel metodo Initialize l’estensione aggiunge due handler ed il gioco è fatto. Ogni volta che un documento verrà mostrato o verrà effettuato il parsing, la nostra estensione entrerà in azione.

Non è ancora finita, in quanto l’estensione è pronta, ma l’applicazione web non la conosce. Quindi andiamo a modificare la sezione del web.config che contiene le estensioni:

    1 <MyApplication.Extensibility enabled=“true“>

    2   <extensions>

    3     <add enabled=“true“ typeName=“ParsingExtensions.DateExtension, ParsingExtensions“/>

    4   extensions>

    5 MyApplication.Extensibility>

Ora basta aggiungere l’assembly che contiene l’estensione nella cartella Bin dell’applicazione web ed il gioco è fatto. Vediamo il risultato:

Evviva! finalmente, dopo ore di lavoro a sbattere la testa, il framework funziona. Per disabilitarlo basterà impostare l’attributo ‘enabled’ a ‘false’ per la sezione delle estensioni o su ciascuna estensione da disabilitare.

Vorrei concludere dicendo che il mio è uno dei tanti metodi che è possibile utilizzare per creare estensioni, magari il mio non è neanche molto bello, però funziona. Ogni persona è libera di proporre, creare e condividere le propie invenzioni.

Ovviamente è possibile riutilizzare il mio framework senza alcuna modifica. Mi raccomando, se lo utilizzate, specificate l’autore ed il link al blog.

Ecco infine il codice che ho scritto: Download.

Ringrazio per la lettura, Umar J.

controllare il task scheduler di Windows in .NET

umarja — Wed, 08 Apr 2009 19:29:00 +0000

Il Task Scheduler (o Utilità di pianificazione, per coloro che hanno Windows in italiano), è uno strumento molto versatile ed integrato in Windows, che permette di programmare delle operazioni da eseguire in determinati momenti della giornata, della settimana, del mese o anno, a determinate condizioni e permette di associare delle azioni nel caso venga verificato l’evento.

In questo articolo descrivo brevemente come utilizzare le API esposte dal Task Scheduler in C#.

Bisogna partire creando un progetto Console o Windows Forms.

Ora bisogna aggiungere un riferimento alla libreria che contiene il set di API: taskschd.dll. Il file si trova in %WINDIR%\System32\.

Una volta aggiunto il riferimento si può notare che Visual Studio genera automaticamente un wrapper per la libreria aggiunta, dovrebbe chiamarsi TaskScheduler.

Ora finalmente si può passare al codice.

La prima cosa da sapere è che il Task Scheduler può essere anche amministrato da remoto, quindi bisogna prima connettersi ad esso passando a tutti i parametri il valore null, in quanto l’obiettivo è connettersi a quello locale:

1 TaskSchedulerClass scheduler = new TaskSchedulerClass();

2

3 scheduler.Connect(null, null, null, null);

Ora si possiede un’istanza della classe TaskSchedulerClass, questa classe permette di creare Task, gestire le cartelle ecc… La classe TaskSchedulerClass dovrebbe trovarsi nel namespace TaskScheduler (che è anche il nome del wrapper creato da Visual Studio).

Il prossimo passo è creare il Task vero e proprio, quindi si richiama il metodo NewTask della classe TaskSchedulerClass e si assegnano le varie proprietà:

1 ITaskDefinition task = scheduler.NewTask(0);

2

3 task.RegistrationInfo.Author = “Umar Jamil”;

4 task.RegistrationInfo.Date = DateTime.Now.ToString(“yyyy-MM-ddThh:mm:ss”);

5 task.RegistrationInfo.Description = “Visualizza un messaggio di promemoria”;

La prima cosa da notare è il formato della data che la libreria accetta: ANNO-MESE-GIORNO + T + ORA:MINUTI:SECONDI. Io ho impostato veramente poche proprietà. La classe task espone una proprietà Settings che permette di specificare a quali condizioni di batteria, di connessione internet ecc.. il task deve essere avviato. Provate voi a smanettare.

Ora che si ha un oggetto ITaskDefinition, bisogna specificare il trigger, cioé l’azione che scatenerà il task, che può essere un range temporale, un task che viene ripetuto ogni giorno alla stessa ora ed altro. Per fare ciò, bisogna creare il trigger ed assegnarlo ad un’istanza dell’oggetto che lo rappresenta:

1 IDailyTrigger dailyTrigger = (IDailyTrigger)task.Triggers.Create(_TASK_TRIGGER_TYPE2.TASK_TRIGGER_DAILY);

2

3 dailyTrigger.DaysInterval = 1;

4 dailyTrigger.StartBoundary = DateTime.Now.ToString(“yyyy-MM-ddThh:mm:ss”);

Bisogna inanzitutto specificare che tipo di trigger si vuole, e quindi effettuare il casting al tipo che lo rappresenta. Nel caso di IDailyTrigger, bisogna specificare a partire da quale data esso è attivo e ogni quanti gioni deve essere avviato, in questo caso ogni giorno (se fosse stato DaysInterval = 2, il task sarebbe stato avviato un giorno si ed un giorno no).

Dopo aver specificato i vari triggers, si può passare a cosa deve effettuare il task se avviato. Esistono tre tipi di azioni:

Avvio di un programma

Invio di una email

Visualizzazione di un messaggio (la classica MessageBox).

Ecco mostrati i tre casi:

1 IExecAction execAction = (IExecAction)task.Actions.Create(_TASK_ACTION_TYPE.TASK_ACTION_EXEC);

2 execAction.Arguments = “newfile.txt”;

3 execAction.Path = “notepad.exe”;

4 execAction.WorkingDirectory = @”C:\Windows\System32″;

5 execAction.Id = “Avvia internet explorer”;

1 IEmailAction emailAction = (IEmailAction)task.Actions.Create(_TASK_ACTION_TYPE.TASK_ACTION_SEND_EMAIL);

2 emailAction.Body = “qui va il testo del messaggio”;

3 emailAction.From = “XXXXXXXXXX”;

4 emailAction.To = “XXXXXXXXXX”;

5 emailAction.Subject = “Oggetto della email”;

6 emailAction.Id = “Invia una email”;

1 IShowMessageAction action = (IShowMessageAction)task.Actions.Create(_TASK_ACTION_TYPE.TASK_ACTION_SHOW_MESSAGE);

2 action.MessageBody = “Dai un’occhiata ai commenti sul blog e rispondi!”;

3 action.Title = “Urgente!”;

4 action.Id = “Mostra il messaggio”;

L’ultimo passo da effettuare è la registrazione del task in una cartella. I task sono organizzati in cartelle, ad esempio esiste la cartella Microsoft. Io utilizzerò quella di root, così che il task appaia subito all’apertura dell’utility Task Scheduler. Il processo di registrazione avviene prima di tutto ottenendo un’istanza della classe ITaskFolder e poi registrando il task dentro quest’ultima.

1 ITaskFolder mainFolder = scheduler.GetFolder(@”\”);

2 IRegisteredTask registeredTask = mainFolder.RegisterTask(

3 “TaskSchedulerDemo”, task.XmlText,

4 (int)_TASK_CREATION.TASK_CREATE_OR_UPDATE,

5 null, null, _TASK_LOGON_TYPE.TASK_LOGON_INTERACTIVE_TOKEN, null);

Il primo parametro del metodo RegisterTask è il nome che si vuole assegnare a quest’ultimo, il secondo è la definizione del task, il terzo indica il tipo di azione desiderata: Aggiunta, Sostituzione, Validare, Disabilitare. In questo caso si vuole solo aggiungere il task, e se esiste già, aggiornarlo.

Ora il task è pronto! Lo si può avviare da codice utilizzando l’istanza della classe IRegisteredTask e richiamando il metodo Run, o aspettare che Windows lo esegua quando previsto.

1 TaskSchedulerClass scheduler = new TaskSchedulerClass();

2

3 scheduler.Connect(null, null, null, null);

4

5 ITaskDefinition task = scheduler.NewTask(0);

6

7 task.RegistrationInfo.Author = “Umar Jamil”;

8 task.RegistrationInfo.Date = DateTime.Now.ToString(“yyyy-MM-ddThh:mm:ss”);

9 task.RegistrationInfo.Description = “Visualizza un messaggio di promemoria”;

10

11 // Triggers

12

13 IDailyTrigger dailyTrigger = (IDailyTrigger)task.Triggers.Create(_TASK_TRIGGER_TYPE2.TASK_TRIGGER_DAILY);

14

15 dailyTrigger.DaysInterval = 1;

16 dailyTrigger.StartBoundary = DateTime.Now.ToString(“yyyy-MM-ddThh:mm:ss”);

17

18 IShowMessageAction action = (IShowMessageAction)task.Actions.Create(_TASK_ACTION_TYPE.TASK_ACTION_SHOW_MESSAGE);

19 action.MessageBody = “Dai un’occhiata ai commenti sul blog e rispondi!”;

20 action.Title = “Urgente!”;

21 action.Id = “Mostra il messaggio”;

22

23 //IEmailAction emailAction = (IEmailAction)task.Actions.Create(_TASK_ACTION_TYPE.TASK_ACTION_SEND_EMAIL);

24 //emailAction.Body = “qui va il testo del messaggio”;

25 //emailAction.From = “XXXXXXXXXX”;

26 //emailAction.To = “XXXXXXXXXX”;

27 //emailAction.Subject = “Oggetto della email”;

28 //emailAction.Id = “Invia una email”;

29

30 //IExecAction execAction = (IExecAction)task.Actions.Create(_TASK_ACTION_TYPE.TASK_ACTION_EXEC);

31 //execAction.Arguments = “www.contoso.com”;

32 //execAction.Path = “notepad.exe”;

33 //execAction.WorkingDirectory = @”C:\Windows\System32″;

34 //execAction.Id = “Avvia internet explorer”;

35

36 ITaskFolder mainFolder = scheduler.GetFolder(@”\”);

37 IRegisteredTask registeredTask = mainFolder.RegisterTask(

38 “TaskSchedulerDemo”, task.XmlText,

39 (int)_TASK_CREATION.TASK_CREATE_OR_UPDATE,

40 null, null, _TASK_LOGON_TYPE.TASK_LOGON_INTERACTIVE_TOKEN, null);

41

42 Console.WriteLine(“Done!”);

43 Console.ReadLine();

Ecco qui il risultato finale nella finestra del Task Scheduler o Utilità di pianificazione:

E’ tutto, per i geeks che non si accontentano, rimando alla documentazione su MSDN.

Debugging efficiente parte 2: Attributi

umarja — Sun, 29 Mar 2009 18:52:00 +0000

Nella prima parte dell’articolo è stato introdotto il debugging e come fosse possibile sfruttare le classi Debug e Debugger messe a disposizione dal .NET Framework.

In questa seconda parte si parlerà di Attributi che semplificano il debugging. Gli attributi sono un metodo dichiarativo per eseguire azioni che altrimenti richiederebbero tempo e righe di codice. Inoltre, il vantaggio degli attributi è il fatto che non riempono il codice di righe inutili e sono facilmente rinuovibili nella fase di deployment.

Di seguito verranno discussi i seguenti attributi:

DebuggerBrowsableAttribute

DebuggerDisplayAttribute

DebuggerHiddenAttribute

DebuggerNonUserCodeAttribute

DebuggerStepperBoundaryAttribute

DebuggerStepThroughAttribute

DebuggerTypeProxyAttribute

DebuggerVisualizerAttribute

Prima di cominciare è meglio creare una classe che verrà utilizzata nei codici sorgenti d’esempio:

    1 Class Person

    2

    3     Private m_Name As String = String.Empty

    4     Private m_LastName As String = String.Empty

    5     Private m_Phones As String() = New String() {}

    6     Private m_Addresses As String() = New String() {}

    7     Private m_Age As Integer = 0

    8

    9     Public Property Name() As String

   10         Get

   11             Return m_Name

   12         End Get

   13         Set(ByVal value As String)

   14             m_Name = value

   15         End Set

   16     End Property

   17

   18     Public Property LastName() As String

   19         Get

   20             Return m_LastName

   21         End Get

   22         Set(ByVal value As String)

   23             m_LastName = value

   24         End Set

   25     End Property

   26

   27     Public Property Phones() As String()

   28         Get

   29             Return m_Phones

   30         End Get

   31         Set(ByVal value As String())

   32             m_Phones = value

   33         End Set

   34     End Property

   35

   36     Public Property Addresses() As String()

   37         Get

   38             Return m_Addresses

   39         End Get

   40         Set(ByVal value As String())

   41             m_Addresses = value

   42         End Set

   43     End Property

   44

   45     Public Property Age() As Integer

   46         Get

   47             Return m_Age

   48         End Get

   49         Set(ByVal value As Integer)

   50             m_Age = value

   51         End Set

   52     End Property

   53

   54 End Class

Ed ecco il codice sorgente in C#

    1 class Person

    2 {

    3

    4     private string m_Name = string.Empty;

    5     private string m_LastName = string.Empty;

    6     private string[] m_Phones = new string[] { };

    7     private string[] m_Addresses = new string[] { };

    8

    9     private int m_Age = 0;

   10

   11     public string Name {

   12         get { return m_Name; }

   13         set { m_Name = value; }

   14     }

   15

   16     public string LastName {

   17         get { return m_LastName; }

   18         set { m_LastName = value; }

   19     }

   20

   21     public string[] Phones {

   22         get { return m_Phones; }

   23         set { m_Phones = value; }

   24     }

   25

   26     public string[] Addresses {

   27         get { return m_Addresses; }

   28         set { m_Addresses = value; }

   29     }

   30

   31     public int Age {

   32         get { return m_Age; }

   33         set { m_Age = value; }

   34     }

   35

   36 }

Ora si comincia con l’esplorazione dei vari attributi, partendo da DebuggerBrowsable.

DebuggerBrowsable

L’Attributo DebuggerBrowsable permette di nascondere un membro di un oggetto dalla finestra Locals di Visual Studio. Ad esempio, nella classe Person, se non si vuole vedere i campi della classe (quelli che iniziano per ‘m_’ per intenderci) basta applicare un attributo DebuggerBrowsable e specificare come valore Never. Ecco il risultato:

Come si può notare i campi privati non sono stati mostrati, cosa che sarebbe successa se non fosse stato applicato loro l’attributo DebuggerBrowsable. L’Attributo DebuggerBrowsable accetta un’enumerazione che presenta i seguenti valori:

Collapsed Il membro viene visualizzato, ma con un ‘+’ accanto che permette di espanderlo.

Never Il membro non viene mai visualizzato

RootHidden Il membro, se facente parte di una collezione, viene visualizzato come mebro dell’oggetto che contiene la collezione. Di seguito è mostrato un esempio.

In questo caso l’attributo DebuggerBrowsable è stato applicato agli array Phones e Addresses con valore RootHidden.

DebuggerDisplay

L’attributo DebuggerDisplay indica al debugger come un oggetto deve essere mostrato.

Accetta un unico argomento che indica come deve essere formattato l’output mostrato dal debugger. Nella stringa di formattazione, qualsiasi nome contenuto tra due parentesi graffe o tonde viene valutato come campo, metodo o proprietà.

Si consideri il seguente attributo applicato alla classe Person descritta sopra:

    1 [DebuggerDisplay("Name = {Name}, LastName = {LastName}, Phones = {Phones(0)}, Age = {Age}")]

    1

L’attributo specifica che la classe, nella colonna Value della finestra Locals di Visual Studio avrà come output il Nome, il Cognome, il primo numero di telefono (Phones è un array) e l’Età della persona, come mostrato in seguito:

Un metodo per evitare di utilizzare questa classe è ereditare il metodo ToString della classe Object. Questo viene considerato come output da Visual Studio solo se all’oggetto non è applicato un attributo DebuggerDisplay. Ovviamente questa pratica è vietata in quanto il metodo ToString non serve solo in fase di debugging.

DebuggerHidden, DebuggerNonUserCode, DebuggerStepThrough

Indica che il codice o il metodo a cui è applicato l’attributo non viene mostrato dal debugger nel caso di DebuggerHidden. La stessa cosa vale anche per DebuggerNonUserCode, che indica al debugger il fatto che il codice è stato generato da un tool, o è stato già testato e quindi è inutile testarlo. Il debugger non permette quindi di inserire breakpoint o di fermare l’esecuzione del programma (usando Debugger.Break). L’attributo DebuggerStepThrough indica al debugger di saltare il metodo o il codice a cui è applicato e di andare al sucessivo codice scritto dall’utente, quindi senza l’attributo DebuggerStepThough, DebuggerHidden o DebuggerNonUserCode.

DebuggerStepperBoundary

L’attributo specifica che il codice da questo momento in poi non deve essere eseguito in step-mode, ma deve essere eseguito senza stepping. Quindi ha lo stesso effetto di premere il pulsante F5 in Visual Studio per continuare l’esecuzione del programma senza effettuare lo stepping (effettuato usando il pulsante F10).

DebuggerTypeProxy

L’attributo specifica che il contenuto dell’oggetto a cui è applicato, nella finestra Locals di Visual Studio, non deve essere mostrato, ma deve essere sostituito dal contenuto di un oggetto proxy, che viene istanziata e vengono mostrati i suoi membri pubblici. L’oggetto proxy solitamente è un oggetto annidato all’interno di quello che rappresenta e deve avere un costruttore che accetta come parametro l’oggetto che rappresenta.

Si applichi il seguente attributo alla classe Person descritta sopra e copiare il codice della classe PersonProxy mostra di seguito come classe annidata di Person.

    1 [DebuggerTypeProxy(typeof(PersonProxy))]

    1

Ed ecco il codice della classe PersonProxy

    1 class PersonProxy

    2 {

    3     public string Message = "Dovresti vedere questo messaggio e il nome invece dei membri della classe Person";

    4     public string Name = String.Empty;

    5

    6     public PersonProxy(Person person)

    7     {

    8         Name = person.Name;

    9     }

   10 }

    1 Class PersonProxy

    2

    3     Public Name As String

    4     Public Message As String = "Dovresti vedere questo messaggio e il nome invece dei membri della classe Person"

    5

    6     Public Sub New(ByVal pers As Person)

    7         Name = pers.Name

    8     End Sub

    9

   10 End Class

Si otterrà un risultato del genere

Conclusioni

Con questo articolo concludo il debugging efficiente. Spero che sia interessante e spero che abbia aiutato qualcuno, sopratutto per l’esame 70-536. Auguro buon coding a tutti.

Debugging efficiente

umarja — Thu, 26 Mar 2009 19:15:00 +0000

Il debugging è una fase fondamentale nello sviluppo di software. L’utilizzo di buone tecniche di debugging è alla base per la creazione di software efficienti e funzionanti. Ma il punto di questo articolo non è solo il come utilizzare il debugging per creare codice migliore, ma come risparmiare tempo utilizzando un po di classi offerte dal .NET Framework orientate proprio a questa fase del development life life-cycle.

Il primo passo per il testing/debugging efficiente è l’utilizzo della classe Debugger. Essa ha solo due metodi importanti: Log e Break. Il primo permette di scrivere sulla finestra del debugger (nel caso di Visual Studio si parla della Output Window). Il metodo Log permette di specificare il livello di gravità del messaggio, un messaggio ed una categoria che descriva il messaggio. Il metodo Break, invece, permette di bloccare l’esecuzione del software per passare all’interfaccia del software di debugging. Nel caso di Visual Studio, la chiamata al metodo Break ha lo stesso effetto dato dall’inserimento di un breakpoint. Il vantaggio nell’uso del metodo Break sta nel fatto che è possibile bloccare l’applicazione dopo il verificarsi di un evento o in modo condizionale, ad esempio dopo aver validato il contenuto restituito da un server remoto.

Altro strumento utile per il debugging è il logging degli eventi dell’applicazione. Per logging si intende la possibilità di scrivere in qualche luogo dei messaggi, anche piccoli per descrivere lo stato attuale delle operazioni del software, o dopo il verificarsi di determinati eventi.

La classe Debug è simile alla classe Debugger come finalità, ma molto piu’ potente. I metodi e le proprietà pricipali della classe Debug sono:

Assert Mostra un messaggio di errore se la condizione passata come argomento risulta falsa.

Close Effettua il Flush del buffer e chiude tutti i listeners associati.

Fail Mostra un messaggio di errore.

Flush Scrive il buffer in memoria sui listeners associati.

Indent Indenta il testo di output. Serve sopratutto per la fomattazione di testo.

Print Scrive un messaggio seguito da un line terminator sui vari listeners associati.

Unindent Operazione opposta al metodo Indent, quindi diminuisce l’indentazione del testo.

Write Scrive il messaggio specificato sui listeners associati

WriteIf Come il metodo Write, solo che accetta una condizione che, se valutata, richiama il metodo Write.

WriteLine Scrive il messaggio specificato seguito da un line terminator sui vari listeners associati

WriteLineIf Come il metodo WriteLine, solo che accetta una condizione che, se valutata, richiama il metodo WriteLine

Il metodo Assert è forse il metodo che più utilizzo della classe Debug, in quanto permette di mostrare un messaggio di errore se la condizione passata come argomento risulta restituisce ‘False’. Si consideri il seguente esempio

1 int myResult = PerformCalculation();

2 Debug.Assert((myResult != 1), “myResult non ha il valore atteso, cioé 1″);

Qui, se la variabile myResult ha un valore uguale a 1, l’esecuzione del programma viene interrotta e viene mostrato un messaggio di errore simile a questo:

Messaggio di erorre visualizzato dalla chiamata al metodo Assert

Il metodo fail è simile al metodo Assert, solo che non accetta condizioni ma solo un messaggio di errore da visualizzare. E’ utilizzato quando il programma raggiunge uno stato di instabilità e quindi non può proseguire con l’esecuzione.

I metodi Indent e Unindent permettono rispettivamente di indentare e rimuovere l’indentatura del testo. Sono utilizzati prevalentemente per la formattazione dei messaggi di output.

I metodi Write e WriteLine permettono di scrivere sui listeners dei messaggi, mentre i metodi WriteIf e WriteLineIf accettano una condizione e scrivono il messaggio solo se la condizione è verificata, cioé restituisce ‘True’.

Un fatto molto positivo riguardante la classe Debug e Debugger è che se il programma viene compilato con la configurazione ‘Release’ in Visual Studio, ogni singola chiamata ai metodi delle classi Debug e Debugger viene eliminato automaticamente. Questo permette di risparmiare un sacco di tempo, in quanto non bisogna stare a cancellare/commentare ogni singola riga.

I listeners non sono altro che degli oggetti associato al programma e vengono configurati per il tracing. Per maggiori informazioni sul tracing e sui trace listeners andare qui.

Per ora è tutto. In futuro parlerò degli attributi che è possibile utilizzare per migliorare la fase di debugging in Visual Studio 2008.

Collapsed	Il membro viene visualizzato, ma con un ‘+’ accanto che permette di espanderlo.
Never	Il membro non viene mai visualizzato
RootHidden	Il membro, se facente parte di una collezione, viene visualizzato come mebro dell’oggetto che contiene la collezione. Di seguito è mostrato un esempio.

Assert	Mostra un messaggio di errore se la condizione passata come argomento risulta falsa.
Close	Effettua il Flush del buffer e chiude tutti i listeners associati.
Fail	Mostra un messaggio di errore.
Flush	Scrive il buffer in memoria sui listeners associati.
Indent	Indenta il testo di output. Serve sopratutto per la fomattazione di testo.
Print	Scrive un messaggio seguito da un line terminator sui vari listeners associati.
Unindent	Operazione opposta al metodo Indent, quindi diminuisce l’indentazione del testo.
Write	Scrive il messaggio specificato sui listeners associati
WriteIf	Come il metodo Write, solo che accetta una condizione che, se valutata, richiama il metodo Write.
WriteLine	Scrive il messaggio specificato seguito da un line terminator sui vari listeners associati
WriteLineIf	Come il metodo WriteLine, solo che accetta una condizione che, se valutata, richiama il metodo WriteLine