Exam 70-536 Application Development Foundation

[70-536] GZipStream class, DeflateStream class and Isolated Storage

Andrea Angella — Tue, 18 Nov 2008 15:07:17 GMT

Area di riferimento

- Implementing serialization and input/output functionality in a .NET Framework application (18 percent)
   - Compress or decompress stream information in a .NET Framework application and improve the security of application data by using isolated storage
      - May include but is not limited to: IsolatedStorageFile class, IsolatedStorageFileStream class;
      - DeflateStream class; GZipStream class

GZipStream and DeflateStream classes

La classi GZipStream e DeflateStream permettono di comprimere dati utilizzando il famoso algoritmo di compressione Gzip. Conviene utilizzare la classe GZipStream nel caso in cui si intenda distribuire i file in modo che questi possano essere decompressi utilizzando l'ampiamente diffuso tool gzip.

Queste classi si trovano nel namespace System.IO.Compression e il loro utilizzo è molto semplice.

    class Program
    {
        static void Main(string[] args)
        {
            File.WriteAllText("source.txt", "Il contenuto di questo file verra' compresso.");

            // File compression
            using (FileStream sourceFile = File.Open("source.txt", FileMode.Open))
            {
                using (FileStream destinationFile = File.Open("destination.dat", FileMode.Create))
                {
                    using (GZipStream comp = new GZipStream(destinationFile, CompressionMode.Compress))
                    {
                        int b;
                        while ((b = sourceFile.ReadByte()) != -1)
                        {
                            comp.WriteByte((byte)b);
                        }
                    }
                }
            }  
         
            // File decompression
            using (FileStream sourceFile = File.Open("destination.dat", FileMode.Open))
            {
                using (FileStream destinationFile = File.Open("new-source.txt", FileMode.Create))
                {
                    using (GZipStream decomp = new GZipStream(sourceFile, CompressionMode.Decompress))
                    {
                        int b;
                        while ((b = decomp.ReadByte()) != -1)
                        {
                            destinationFile.WriteByte((byte)b);
                        }
                    }
                }
            }

            Console.WriteLine(File.ReadAllText("new-source.txt"));
            Console.ReadKey();
        }
    }

Isolated Storage

L'Isolated Storage è un repository all'interno del quale è possibile leggere e scrivere dati in maniera sicura indipendentemente dai privilegi di cui disponde il codice.

La prima cosa da fare quando si lavora con l'isolated storage è scegliere l'ambito in cui saranno memorizzati i dati:

Assembly/Machine : Si utilizza questo ambito per persistere dati a livello di applicazione.
Assembly/User : Si utilizza questo ambito per persistere dati a livello di utente. Ogni utente della macchina avrà le sue impostazioni specifiche.
...

L'utilizzo dell'Isolated Storage ruota intorno alle classi IsolatedStorageFile e IsolatedStorageFileStream. E' inoltre possibile utilizzare l'attributo IsolatedStorageFilePermission per specificare il permesso di accedere all'Isolated Storage e impostare altri parametri come ad esempio la quota massima di spazio da associare a ciascun utente.

    [IsolatedStorageFilePermission(SecurityAction.Demand, UserQuota=256)]
    class Program
    {
        static void Main(string[] args)
        {
            // Assembly/Machine Scope - Writing data

            IsolatedStorageFile applicationStorage = IsolatedStorageFile.GetMachineStoreForAssembly();

            IsolatedStorageFileStream applicationStream = 
                new IsolatedStorageFileStream("application-settings.dat", FileMode.Create, applicationStorage);

            using (StreamWriter writer = new StreamWriter(applicationStream))
            {
                writer.Write("Informazioni a livello applicazione");
            }

            // User/Machine Scope - Writing data

            IsolatedStorageFile userStorage = IsolatedStorageFile.GetUserStoreForAssembly();

            IsolatedStorageFileStream userStream =
                new IsolatedStorageFileStream("user-settings.dat", FileMode.Create, userStorage);

            using (StreamWriter writer = new StreamWriter(userStream))
            {
                writer.Write("Informazioni a livello utente in user-settings.dat");
            }

            userStorage.CreateDirectory("folder");

            userStream = new IsolatedStorageFileStream(@"folder\user-settings.dat", FileMode.Create, userStorage);

            using (StreamWriter writer = new StreamWriter(userStream))
            {
                writer.Write("Informazioni a livello utente in folder\\user-settings.dat");
            }

            // Reading data

            Console.WriteLine("Directories :");
            foreach (string directory in userStorage.GetDirectoryNames("*"))
            {
                Console.WriteLine(directory);
            }

            Console.WriteLine("Files *.dat :");
            foreach (string file in userStorage.GetFileNames("*.dat"))
            {
                Console.WriteLine(file);
            }

            Console.ReadKey();
        }
    }

[70-536] - File System classes and Streams

Andrea Angella — Tue, 18 Nov 2008 14:51:37 GMT

Area di riferimento

- Implementing serialization and input/output functionality in a .NET Framework application (18 percent)
   - Access files and folders by using the File System classes
      - May include but is not limited to: File class and FileInfo class; Directory class and DirectoryInfo class;
      - DriveInfo class and DriveType enumeration; FileSystemInfo class and FileSystemWatcher class; Path class;
      - ErrorEventArgs class and ErrorEventHandler delegate; RenamedEventArgs class and RenamedEventHandler delegate
   - Manage byte streams by using Stream classes
      - May include but is not limited to: FileStream class; Stream class; MemoryStream; BufferedStream class
   - Manage .NET Framework application data by using Reader and Writer classes
      - May include but is not limited to: StringReader class and StringWriter class; TextReader class and TextWriter class;
      - StreamReader class and Stream Writer class; BinaryReader class and BinaryWriter class

File System classes

Il framework .NET offre numerose classi che permettono l'accesso al file system.

La classe DriveInfo permette di ottenere informazioni relative ai drive presenti sulla macchina. La classe File permette di effettuare alcune tipiche operazioni sui file come la copia, la creazione e la cancellazione. Le classi FileInfo e DirectoryInfo derivano da FileSystemInfo e consentono di accedere a diverse informazioni relative a file e directory. Utilizzando queste classi inoltre è estremamente semplice navigare attraverso il file system ottenendo l'elenco dei file presenti all'interno di una directory e l'elenco di directory presenti all'interno di un'altra directory. La classe Path fornisce un valido supporto per estrapolare informazioni relative ad un path e soprattutto offre una comoda funzione per combinare due path fra loro.

Grazie all'interessantissima classe FileSystemWatcher è inoltre possibile monitorare in tempo reale le modifiche che vengono compiute all'interno di una particolare cartella semplicemente gestendo opportuni eventi.

Di seguito riporto un pò di codice che utilizza tutte queste classi. Il loro utilizzo è molto intuitivo per questo non ritengo necessaria alcuna ulteriore spiegazione.

  1     class Program
  2     {
  3         static void Main(string[] args)
  4         {
  5             Console.WriteLine("Drive\n");
  6 
  7             DriveInfo driveInfo = new DriveInfo("C");
  8             Console.WriteLine("Name: {0}", driveInfo.Name);
  9             Console.WriteLine("TotalSize: {0} bytes", driveInfo.TotalSize);
 10             Console.WriteLine("TotalFreeSpace: {0} bytes", driveInfo.TotalFreeSpace);
 11             Console.WriteLine("AvailableFreeSpace: {0} bytes", driveInfo.AvailableFreeSpace);
 12             Console.WriteLine("DriveFormat: {0}", driveInfo.DriveFormat);
 13             Console.WriteLine("DriveType: {0}", driveInfo.DriveType);
 14             Console.WriteLine("VolumeLabel: {0}", driveInfo.VolumeLabel);
 15 
 16             Console.WriteLine("\nFile:\n");
 17 
 18             File.AppendAllText("file1.txt", "Ciao a tutti da Andrea", Encoding.ASCII);
 19             File.Copy("file1.txt", "file2.txt", true);
 20 
 21             FileInfo file2Info = new FileInfo("file2.txt");
 22             Console.WriteLine("CreationTime: {0}", file2Info.CreationTime);
 23             Console.WriteLine("LastWriteTime: {0}", file2Info.LastWriteTime);
 24             Console.WriteLine("DirectoryName: {0}", file2Info.DirectoryName);
 25             Console.WriteLine("Exists: {0}", file2Info.Exists);
 26             Console.WriteLine("Extension: {0}", file2Info.Extension);
 27             Console.WriteLine("FullName: {0}", file2Info.FullName);
 28             Console.WriteLine("Name: {0}", file2Info.Name);
 29             Console.WriteLine("IsReadOnly: {0}", file2Info.IsReadOnly);
 30             Console.WriteLine("Length: {0}", file2Info.Length);
 31 
 32             Console.WriteLine("\nDirectory:\n");
 33 
 34             DirectoryInfo dir2Info = file2Info.Directory;
 35             Console.WriteLine("CreationTime: {0}", dir2Info.CreationTime);
 36             Console.WriteLine("FullTime: {0}", dir2Info.FullName);
 37             Console.WriteLine("Exists: {0}", dir2Info.Exists);
 38             Console.WriteLine("LastAccessTime: {0}", dir2Info.LastAccessTime);
 39             Console.WriteLine("LastWriteTime: {0}", dir2Info.LastWriteTime);
 40 
 41             dir2Info.CreateSubdirectory("folder1");
 42             dir2Info.CreateSubdirectory("folder2");
 43             dir2Info.CreateSubdirectory("folder3");
 44 
 45             Console.WriteLine("Files in folder: ");
 46             foreach (FileInfo fileInfo in dir2Info.GetFiles())
 47             {
 48                 Console.WriteLine("\t{0}", file2Info.Name);
 49             }
 50 
 51             Console.WriteLine("Directory in folder: ");
 52             foreach (DirectoryInfo dirInfo in dir2Info.GetDirectories())
 53             {
 54                 Console.WriteLine("\t{0}", dirInfo.Name);
 55             }
 56 
 57             if (Directory.Exists("folder1"))
 58             {
 59                 Directory.Delete("folder1");
 60             }
 61             Directory.Delete("folder2");
 62             new DirectoryInfo("folder3").Delete();
 63             file2Info.Delete();
 64 
 65             Console.WriteLine("\nPath: c:\\prova\\file.txt \n");
 66             Console.WriteLine("GetDirectoryName: {0}", Path.GetDirectoryName(@"c:\prova\file.txt"));
 67             Console.WriteLine("GetExtension: {0}", Path.GetExtension(@"c:\prova\file.txt"));
 68             Console.WriteLine("GetFileName: {0}", Path.GetFileName(@"c:\prova\file.txt"));
 69             Console.WriteLine("GetFileNameWithoutExtension: {0}", Path.GetFileNameWithoutExtension(@"c:\prova\file.txt"));
 70             Console.WriteLine("GetFullPath: {0}", Path.GetFullPath(@"c:\prova\file.txt"));
 71             Console.WriteLine("GetPathRoot: {0}", Path.GetPathRoot(@"c:\prova\file.txt"));
 72             Console.WriteLine("GetRandomFileName: {0}", Path.GetRandomFileName());
 73             Console.WriteLine("GetTempPath: {0}", Path.GetTempPath());
 74             Console.WriteLine("GetTempFileName: {0}", Path.GetTempFileName());
 75        
 76             Console.WriteLine("Combine: {0}", Path.Combine("c:\\prova1", "prova2\\file.txt"));
 77             
 78             Console.WriteLine("\nFileSystemWatcher: \n");
 79 
 80             Directory.CreateDirectory("folder");
 81             FileSystemWatcher fsWatcher = new FileSystemWatcher("folder");
 82             fsWatcher.Created += new FileSystemEventHandler(fsWatcher_Created);
 83             fsWatcher.Deleted += new FileSystemEventHandler(fsWatcher_Deleted);
 84             fsWatcher.Changed += new FileSystemEventHandler(fsWatcher_Changed);
 85             fsWatcher.Renamed += new RenamedEventHandler(fsWatcher_Renamed);
 86             fsWatcher.Error += new ErrorEventHandler(fsWatcher_Error);
 87 
 88             fsWatcher.EnableRaisingEvents = true;
 89 
 90             Console.ReadKey();
 91         }
 92 
 93         static void fsWatcher_Error(object sender, ErrorEventArgs e)
 94         {
 95             Console.WriteLine("FileSystemWatcher Error\n");
 96         }
 97 
 98         static void fsWatcher_Changed(object sender, FileSystemEventArgs e)
 99         {
100             Console.WriteLine("ChangeType: {0}", e.ChangeType);
101             Console.WriteLine("FullPath: {0}", e.FullPath);
102             Console.WriteLine("Name: {0}\n", e.Name);
103         }
104 
105         static void fsWatcher_Renamed(object sender, RenamedEventArgs e)
106         {
107             Console.WriteLine("ChangeType: {0}", e.ChangeType);
108             Console.WriteLine("FullPath: {0}", e.FullPath);
109             Console.WriteLine("Name: {0}", e.Name);
110             Console.WriteLine("OldFullPath: {0}", e.OldFullPath);
111             Console.WriteLine("OldName: {0}\n", e.OldName);
112         }
113 
114         static void fsWatcher_Deleted(object sender, FileSystemEventArgs e)
115         {
116             Console.WriteLine("ChangeType: {0}", e.ChangeType);
117             Console.WriteLine("FullPath: {0}", e.FullPath);
118             Console.WriteLine("Name: {0}\n", e.Name);
119         }
120 
121         static void fsWatcher_Created(object sender, FileSystemEventArgs e)
122         {
123             Console.WriteLine("ChangeType: {0}", e.ChangeType);
124             Console.WriteLine("FullPath: {0}", e.FullPath);
125             Console.WriteLine("Name: {0}\n", e.Name);
126         }
127     }

Streams

Gli stream realizzano un meccanismo unificato per gestire l'accesso sequenziale e random ai dati. La classe astratta Stream fornisce l'interfaccia di base e l'implementazione per tutti gli strem all'interno del Framework. Quando si apre un file viene restituito un oggetto di tipo FileStream che offre una interfaccia di basso livello per l'accesso al file. Le classi StreamReader e StreamWriter facilitano la lettura e la scrittura di file di testo. Le classi BinaryReader e BinaryWriter invece permettono la lettura e la scrittura di dati binari in modo più semplice del dover lavorare direttamente su vettori di byte.

Quando si lavora con piccoli file di testo è possibile utilizzare le funzioni File.WriteAllText e File.ReadAllText rispettivamente per scrivere un file di testo a partire da una stringa e per ottenere il contenuto di un file di testo all'interno di una stringa.

La classe MemoryStream fornisce le funzionalità per creare stream in memoria. Le classi StringReader e StringWriter invece svolgono le stesse funzionalità delle classi StreamReader e StreamWriter solo che la sorgente dati associata è una stringa al contrario di un file ( le classi astratte da cui derivano sono TextReader e TextWriter che implementano le funzionalità di base per la lettura e scrittura di testo).

Ecco un pò di codice dimostrativo:

 1     class Program
 2     {
 3         static void Main(string[] args)
 4         {
 5             Console.WriteLine("*** Text Streams: ***\n");
 6 
 7             FileStream fs = File.Open("file.txt", FileMode.Create);
 8 
 9             byte[] bytesTitolo = new ASCIIEncoding().GetBytes("Titolo del file\r\n\r\n");
10             fs.Write(bytesTitolo, 0, bytesTitolo.Length);
11 
12             using (StreamWriter sw = new StreamWriter(fs))
13             {
14                 sw.WriteLine("Ciao a tutti");
15                 sw.WriteLine("il mio nome Ã¨ Andrea");
16             }
17 
18             using (StreamReader sr = File.OpenText("file.txt"))
19             {
20                 while (!sr.EndOfStream)
21                 {
22                     Console.WriteLine(sr.ReadLine());
23                 }
24             }
25 
26             Console.WriteLine();
27 
28             File.WriteAllText("file2.txt", "Prima riga del file2\r\nSeconda riga del file2");
29             Console.WriteLine(File.ReadAllText("file2.txt"));
30 
31             Console.WriteLine("\n*** Binary Streams: ***\n");
32 
33             fs = File.Open("file3.dat", FileMode.Create);
34             using (BinaryWriter bw = new BinaryWriter(fs))
35             {
36                 bw.Write('A');
37                 bw.Write(true);
38                 bw.Write(12.45);
39                 bw.Write("Ciao");
40             }
41             fs = File.Open("file3.dat", FileMode.Open);
42             using (BinaryReader br = new BinaryReader(fs))
43             {
44                 Console.WriteLine(br.ReadChar());
45                 Console.WriteLine(br.ReadBoolean());
46                 Console.WriteLine(br.ReadDouble());
47                 Console.WriteLine(br.ReadString());
48             }
49 
50             Console.WriteLine("\n*** Memory Streams: ***\n");
51 
52             MemoryStream ms = new MemoryStream();
53             using (StreamWriter sw = new StreamWriter(ms))
54             {
55                 sw.WriteLine("Scrivo su uno stream in memoria.");
56                 sw.Flush();
57 
58                 using (fs = File.Open("file.txt", FileMode.Append))
59                 {
60                     ms.WriteTo(fs);
61                 }
62             }
63 
64             Console.ReadKey();
65         }
66     }

Infine è importante citare la classe BufferedStream che permette di migliorare le performance implementando un meccanismo di lettura e scrittura bufferizzato.

[70-536] - Serialization and Deserialization

Andrea Angella — Sun, 02 Nov 2008 00:59:23 GMT

Area di riferimento

- Implementing serialization and input/output functionality in a .NET Framework application (18 percent)
    - Serialize or deserialize an object or an object graph by using runtime serialization techniques.
        - May include but is not limited to: Serialization interfaces; Serialization attributes; SerializationEntry structure and SerializationInfo class;
        - ObjectManager class; Formatter class, FormatterConverter class, and FormatterServices class; StreamingContext structure
   - Control the serialization of an object into XML format by using the System.Xml.Serialization namespace.
       - May include but is not limited to: Serialize and deserialize objects into XML format by using the XmlSerializer class; Control serialization by using serialization attributes;
       - Implement XML serialization interfaces to provide custom formatting for XML serialization; Delegates and event handlers provided by the System.Xml.Serialization namespace
   - Implement custom serialization formatting by using the Serialization Formatter classes.
       - May include but is not limited to: SoapFormatter; BinaryFormatter class

Serialization and Deserialization

La serializzazione consiste nel trasformare un oggetto in una sequenza di byte che può essere memorizzata o trasferita tra diverse applicazioni.

Affinchè un tipo possa essere serializzato è necessario decorarlo con l'attributo [Serializable]. Se non non si vuole serializzare un particolare membro allora si utilizza l'attributo [NonSerialized]. Nel caso fosse necessario eseguire del codice dopo l'operazione di deserializzazione (per esempio per impostare membri calcolati che non sono stati serializzati) si può implementare l'interfaccia IDeserializationCallback come mostrato nell'esempio.

 1         [Serializable]
 2         class Student : IDeserializationCallback
 3         {
 4             public Student(string name, string surname, DateTime birthDate)
 5             {
 6                 Name = name;
 7                 Surname = surname;
 8                 BirthDate = birthDate;
 9                 calculateAge();
10             }
11 
12             public string Name { get; set; }
13             public string Surname { get; set; }
14             public DateTime BirthDate { get; set; }
15 
16             [NonSerialized]
17             [SoapIgnore]
18             private int age;
19 
20             public int Age
21             {
22                 get
23                 {
24                     return age;
25                 }
26                 set
27                 {
28                     age = value;
29                 }
30             }
31 
32             public override string ToString()
33             {
34                 return Name + ", " + Surname + ", " + BirthDate.ToShortDateString() + ", " + age;
35             }
36 
37             private void calculateAge()
38             {
39                 Age = DateTime.Now.Year - BirthDate.Year;
40             }
41 
42             public void OnDeserialization(object sender)
43             {
44                 calculateAge();
45             }
46         }

Con la classe BinaryFormatter è possibile serializzare in modo efficiente l'oggetto ma questo sarà accessibile solo da parte di altre applicazioni .NET:

        static void Main(string[] args)
        {
            Student student = new Student("Andrea", "Angella", new DateTime(1984, 7, 14));

            // Binary Serialization
            using (FileStream fs = new FileStream("file.dat", FileMode.Create))
            {
                BinaryFormatter bf = new BinaryFormatter();
                bf.Serialize(fs, student);
            }

            // Binary Deserialization
            using (FileStream fs = new FileStream("file.dat", FileMode.Open))
            {
                BinaryFormatter bf = new BinaryFormatter();
                student = (Student)bf.Deserialize(fs);
            }

            Console.Write(student);
            Console.ReadKey();
        }

La classe SoapFormatter (assembly System.Runtime.Serialization.Formatters.Soap) permette di serializzare un oggetto come un SOAP Envelop adatto per essere condiviso anche con applicazioni non appartenenti al mondo .NET. Il suo utilizzo è analogo a quello della classe BinaryFormatter. E' possibile controllare la formattazione utilizzando opportuni attributi come [SoapAttribute], [SoapElement], [SoapEnum], [SoapIgnore] e [SoapInclude].

E' possibile serializzare un oggetto in uno specifico formato XML attraverso la classe XmlSerializer. Questa modalità ovviamente porta con se i vantaggi del linguaggio XML e cioè forte interoperabilità, amministrazione user-friendly e migliore compatibilità all'indietro. La serializzazione XML può serializzare solamente membri pubblici (al contrario di quella binaria) e non possono essere serializzati grafi di oggetti. E' richiesto un costruttore di default. Anche in questo caso è possibile personalizzare il markup xml che sarà generato utilizzando opportuni attributi come [XmlAttribute], [XmlElement], [XmlIgnore], [XmlEnum] ecc.

E' interessante la possibiiltà di generare classi con attributi xml a partire da un file XML Schema Definition. Lo strumento da utilizzare è il tool a linea di comando xsd.

Se si vuole avere un controllo maggiore sul processo di serializzazione e deserializzazione è possibile implementare l'interfaccia ISerializable. Tramite il metodo GetObjectData si specificano i membri che si vogliono serializzare. All'interno di un particolare costruttore (chiamato dopo la fase di deserializzazione) sarà possibile accedere a questi valori e ripristinare il contenuto dell'oggetto. E' possibile intervenire prima e dopo la fase di serializzazione e deserializzazione inserendo opportuni metodi decorati con gli attributi [OnSerializing], [OnSerialized], [OnDeserializing], [OnDeserialized]. La classe StreamingContext è utile se si vuole serializzare un oggetto in modo differente in base alla destinazione (stesso processo, processi su macchine differenti, ecc. ).

    [Serializable]
    public class Student : ISerializable
    {
        public string Name { get; set; }
        public string Surname { get; set; }
        public DateTime BirthDate { get; set; }
        public int Age { get; set; }

        // Costruttore standard
        public Student(string name, string surname, DateTime birthDate)
        {
            Name = name;
            Surname = surname;
            BirthDate = birthDate;
            calculateAge();
        }

        // Costruttore per la deserializzazione
        public Student(SerializationInfo info, StreamingContext context)
        {
            Name = info.GetString("Name");
            Surname = info.GetString("Surname");
            BirthDate = info.GetDateTime("BirthDate");
        }
        
        [OnSerializing]
        void BeforeSerialization(StreamingContext context)
        {
            // ...
        }

        [OnSerialized]
        void AfterSerialization(StreamingContext context)
        {
            // ...
        }

        [OnDeserializing]
        void BeforeDeserialization(StreamingContext context)
        {
            // ...
        }
        
        [OnDeserialized]
        void AfterDeserialization(StreamingContext context)
        {
            calculateAge();
        }

        public override string ToString()
        {
            return Name + ", " + Surname + ", " + BirthDate.ToShortDateString() + ", " + Age;
        }

        private void calculateAge()
        {
            Age = DateTime.Now.Year - BirthDate.Year;
        }

        #region ISerializable Members

        // Metodo chiamato durante la fase di serializzazione
        public void GetObjectData(SerializationInfo info, StreamingContext context)
        {
            info.AddValue("Name", Name);
            info.AddValue("Surname", Surname);
            info.AddValue("BirthDate", BirthDate);
        }

        #endregion
    }

Anche se è raramente necessario è bene sapere che è offerta anche la possibilità di realizzare dei formatter personalizzati. Invece di utilizzare ad esempio la classe BinaryFormatter è possibile costruire il proprio formatter implementando l'interfaccia IFormatter o IGenericFormatter.

[70-536] - .NET Mail API

Andrea Angella — Sat, 10 May 2008 17:32:53 GMT

Area di riferimento

- Implementing interoperability, reflection, and mailing functionality in a .NET Framework application
    - Send electronic mail to a Simple Mail Transfer Protocol (SMTP) server for delivery from a .NET Framework application.
        - May include but is not limited to:
            - MailMessage class; MailAddress class and MailAddressCollection class;
            - SmtpClient class, SmtpPermission class, and SmtpPermissionAttribute class;
            - Attachment class, AttachmentBase class, and AttachmentCollection class;
            - SmtpException class, SmtpFailedReceipientException class, and SmtpFailedReceipientsException class;
            - SendCompletedEventHandler delegate; LinkedResource class and LinkedResourceCollection class;
            - AlternateView class and AlternateViewCollection class

.NET Mail API

L'utilizzo delle API per l'invio di messaggi di posta elettronica è molto semplice.
Potete scaricare una semplice soluzione di esempio al seguente indirizzo: http://www.angellaa.it/lab/dettagli-soluzione.aspx?id=14

I passi da seguire sono i seguenti:

Costruire un' istanza della classe MailMessage che rappresenta un messaggio specificando indirizzo sorgente, indirizzi destinatari, oggetto, corpo, priorità ed eventuali file allegati.
Costruire un'istanza della classe SmtpClient specificando, se necessario, le credenziali di accesso al server di posta
Chiamare il metodo Send o SendAsync della classe SmtpClient rispettivamente per inviare il messaggio in modo sincrono o in modo asincrono
Gestire opportunamente gli errori gestendo le eccezioni SmtpException, SmtpFailedReceipientException e SmtpFailedReceipientsException.

[70-536] - Application Domain and Reflection

Andrea Angella — Wed, 09 Apr 2008 15:15:58 GMT

Area di riferimento

- Implementing service processes, threading, and application domains in a .NET Framework application
   - Create a unit of isolation for common language runtime in a .NET Framework application by using application domains
      - Create an application domain
      - Unload an application domain
      - Configure an application domain
      - Retrieve setup information from an application domain
      - Load assemblies into an application domain
- Implementing interoperability, reflection, and mailing functionality in a .NET Framework application
    - Implement reflection functionality in a .NET Framework application, and create metadata, Microsoft Intermediate language (MSIL), and a PE file by using System.Reflection.Emit namespace
      - Assembly class

Application Domain

Gli Application Domain, brevemente AppDomains,permettono al codice di terze parti (e quindi non sicuro) di eseguire all'interno di un processo esistente con la garanzia che le strutture dati, il codice e il contesto di sicurezza non sarà compromesso. Permettono quindi di realizzare una importate caratteristica: l'isolamento.

Quando il CLR viene inizializzato, automaticamente viene creato un AppDomain chiamato Default AppDomain che sarà distrutto solamente quando il processo di Windows che lo ospita termininerà.

Le caratteristiche offerte da un AppDomain sono:

Il codice di un AppDomain non può essere acceduto da un altro AppDomain se non utilizzando la semantica marshal-by-reference o marshal-by-value scatenando controlli di Code Access Security (CAS)
Gli AppDomains possono essere scaricati (unload)
Tramite la CAS è possibile definire in modo estremamente dettagliato il contesto di sicurezza in cui esegue uno specifico AppDomain
Ciascun AppDomain può essere configurato in modo autonomo

E' possibile ottenere un riferimento all' AppDomain in cui sta eseguendo il thread chiamante in questo modo:

AppDomain app = Thread.GetDomain();

E' possibile creare un AppDomain utilizzando il metodo CreateDomain della classe AppDomain che accetta come primo argomento il nome e come altri argomenti un oggetto Evidence e un oggetto AppDomainSetup. L'oggetto Evidence permette di specificare le opzioni relative al contesto di sicurezza (scriverò in seguito post specifici sulla CAS) mentre l'oggetto AppDomainSetup permette di configurare l'AppDomain.
Tramite il metodo Unload della classe AppDomain è invece possibile scaricare un AppDomain quando non è più necessario.

La semantica marshal-by-reference consiste nell'ottenere un oggetto di tipo MarshalByRefObject che rappresenta un Proxy verso un oggetto presente in un altro AppDomain. In questo modo è possibile invocare tutti i metodi di quell'oggetto come se potessimo accedervi direttamente, in realtà sotto sotto il CLR fa transire il thread chiamante dall'AppDomain corrente al nuovo AppDomain garantendo quindi isolamento e sicurezza. I metodi per ottenere un proxy sono CreateInstanceAndUnwrap, CreateInstanceFromAndUnwrap e simili.

La semantica marshal-by-value consiste invece nell'ottenere un oggetto che è una perfetta copia dell'oggetto presente nell'altro AppDomain e totalmente indipendente. E' fondamentale in questo caso che l'oggetto che si vuole far transitare sia decorato con l'attributo [Serializable]. I metodi per ottenere un comportamento di questo tipo sono gli stessi della semantica marshal-by-reference, ciò che cambia infatti è il modo in cui sono definiti i tipi nell'AppDomain e come vegono trattati i risultati.

Un esempio pratico

Mi rendo conto che questo argomento non è dei più semplici. Per questo motivo ho deciso di creare una semplice ma significativa applicazione che sfrutta i vantaggi offerti dagli AppDomain.
Questa applicazione permette semplicemente di effettuare delle operazioni a partire da due numeri interi. La cosa particolare è che l'applicazione stessa può essere estesa tramite altre operazioni presenti in apposite dll (comunemente chiamate AddIn o PlugIn). Vediamo quindi come realizzare una semplice applicazione estensibile con AddIn.

Il problema principale di questo tipo di applicazioni è che non è possibile fidarsi del codice prodotto da terze parti, quindi è necessario, anzi direi obbligatorio, sfruttare l'isolamento offerto dagli AppDomain per garantire robustezza e sicurezza all'applicazione. L'applicazioni può essere scaricata al seguente indirizzo: http://www.angellaa.it/lab/dettagli-soluzione.aspx?id=12

Generalmente si procede nel seguente modo:

Si crea un assembly "Contratto" che definisce una interfaccia / classe-base i cui metodi sono usati dal meccanismo di comunicazione tra l'applicazione host e gli add-in. Si dovrebbe anche dare all'assembly uno strong name ma nell'esempio per semplicità non l'ho fatto
Gli sviluppatori degli add-in fanno riferimento all'assembly "Contratto" per costruire i loro assembly
Si costruisce l'applicazione "Host" che ovviamente anch'essa farà riferimento al "Contratto" e in più sarà presente una cartella in cui incollare i vari add-in. Al caricamento o al verificarsi di particolari eventi, l'applicazione cercherà in questa cartella gli add-in che definiscono le funzionalità aggiuntive

Partiamo dal contratto rappresentato dall'assembly DemoAddInApplicationApi:

namespace DemoAddInApplicationApi
{
    public interface DemoAddInApplicationInterface
    {
        int elabora(int a, int b);
    }

    public abstract class DemoAddInApplicationBase : MarshalByRefObject, DemoAddInApplicationInterface
    {
        public abstract int elabora(int a, int b);
    }

}

La classe astratta DemoAddInApplicationBase sarà quella da cui dovranno ereditare le classi specifiche create dagli sviluppatori degli Add-In. Ho introdotto questa classe per il semplice motivo che affinchè sia possibile sfruttare la semantica mashal-by-reference è necessario che l'oggetto scambiato sia un MarshalByRefObject. In questo modo evito che gli sviluppatori degli add-in si preoccupino di questi dettagli, lasciamo a loro il solo compito di definire un'implementazione specifica dell'operazione.

Ecco una parte del codice che ha scritto lo sviluppatore dell'add-in DemoAddInApplication1:

namespace DemoAddInApplication1
{
    public class DemoAddInApplicationDifferenza : DemoAddInApplicationBase
    {
        public override int elabora(int a, int b)
        {
            return a - b;
        }
    }

    public class DemoAddInApplicationProdotto : DemoAddInApplicationBase
    {
        public override int elabora(int a, int b)
        {
            return a * b;
        }
    }

    ...
}

Andiamo quindi a vedere come è stata realizzata l'applicazione host.
Il seguente codice carica in una combo box l'elenco degli add-in presenti nella cartella add-in:

// Funzione che scandisce la cartella Add-in per rilevare la presenza di eventuali
// nuovi Add-In. Visualizza quindi i loro nomi nella Combo-Box per la scelta.
private void ricaricaAddIn()
{
    string[] files = Directory.GetFiles("Add-in", "*.dll");

    cbAddIn.Items.Clear();
    cbOperazioni.Items.Clear();
    btnCalcola.Enabled = false;

    foreach (string file in files)
    {
        cbAddIn.Items.Add( file );
    }
}

Nel momento in cui viene selezionato l'add-in che si desidera utilizzare, inizia la ricerca delle possibili operazioni offerte all'interno di quello specifico add-in:

private void cbAddIn_SelectedIndexChanged(object sender, EventArgs e)
{
    object item = cbAddIn.Items[cbAddIn.SelectedIndex];
    Assembly a = Assembly.LoadFrom( item.ToString() );

    cbOperazioni.Items.Clear();
    foreach (Type t in a.GetExportedTypes())
    {
        if (t.IsClass && typeof(DemoAddInApplicationBase).IsAssignableFrom(t))
        {
            cbOperazioni.Items.Add(t);
        }
    }
}

Il metodo LoadFrom permette di caricare un assembly. Il metodo GetExportedTypes restituisce tutti i tipi pubblici esposti da quell'assembly. Tramite la proprietà isClass è possibile determinare se il tipo è una classe e tramite il metodo IsAssignableFrom è possibile determinare se t è di tipo DemoAddInApplicationBase.

Il gestore dell'evento click del pulsante Calcola è il cuore del nostro discorso. Viene infatti creato un AppDomain a partire dal nome del file che individua l'add-in, dopodichè viene costruito un oggetto proxy che fa riferimento all'oggetto specifico che implementa l'operazione. Quindi eseguiamo l'operazione all'interno dell'AppDomain creato, visualizziamo il risultato e scarichiamo l'AppDomain.

private void btnCalcola_Click(object sender, EventArgs e)
{
    // recupero il tipo dell'operazione selezionata
    Type t = (Type)cbOperazioni.Items[cbOperazioni.SelectedIndex];
    string addInPath = cbAddIn.Items[cbAddIn.SelectedIndex].ToString();

    // Costruisco un AppDomain in cui eseguire il codice dell'Add-in
    AppDomain appDomain = AppDomain.CreateDomain("Add-in", null, null);

    DemoAddInApplicationBase addIn =
        (DemoAddInApplicationBase)appDomain.CreateInstanceFromAndUnwrap(addInPath, t.FullName);

    // Recupero gli operandi
    int a = Int32.Parse(txtA.Text);
    int b = Int32.Parse(txtB.Text);

    // Eseguo il metodo (Nota addIn è un Proxy)
    int ris = addIn.elabora(a, b);

    // Visualizzo i risultati
    txtRisultato.Text = ris.ToString();

    AppDomain.Unload(appDomain);
}

Ovviamente come avrete sicuramente notato, non ho gestito le possibili eccezioni che potrebbero verificarsi e nemmeno ho impostato l'oggetto Evidence per definire i permessi di esecuzione del codice degli add-in. Tornerò su questo ultimo punto nei post dedicati all'importante argomento della sicurezza applicativa.

[70-536] - AutoResetEvent e ManualResetEvent

Andrea Angella — Sun, 30 Mar 2008 15:21:24 GMT

Area di riferimento

- Implementing service processes, threading, and application domains in a .NET Framework application
   - Develop multithreaded .NET Framework applications
      - AutoResetEvent class and ManualResetEvent class
      - EventWaitHandle class, RegisterWaitHandle class, SendOrPostCallback delegate and IOCompletionCallback delegate

EventWaitHandle

L'oggetto EventWaitHandle ( e gli oggetti derivati AutoResetEvent e ManualResetEvent ) permette di gestire attraverso segnali la sincronizzazione tra diversi thread.

I metodi principali sono:

Set() che imposta lo stato dell'evento a segnalato, permettendo a uno o più dei thread in attesa di procedere
Reset() che imposta lo stato dell'evento a non segnalato, che causerà il blocco dei thread
WaitOne() che blocca il thread corrente se l'evento non è segnalato altrimenti concede l'accesso.

La differenza tra un AutoResetEvent e un ManualResetEvent è semplicemente che dopo la WaitOne() nel primo caso viene effettuato il Reset() in automatico mentre nel secondo caso bisognerà gestire manualmente il reset dell'evento.

Per vedere in azione questa classe consideriamo un esempio. Supponiamo di avere un unico thread produttore e diversi thread consumatori. Il dato prodotto dal produttore è un numero intero. Si vuole fare in modo che una volta prodotto il dato il produttore si metta in attesa che venga consumato da qualche consumatore e che ciascun consumatore si metta in attesa che un dato venga prodotto ( non ho realizzato un meccanismo bufferizzato per semplicità ).

class Program
{
    private const int N_COMSUMATORI = 5;           // numero totale dei consumatori
    private const int N_LETTURE = 3;               // numero totale di letture per consumatore

    private static EventWaitHandle datoPronto;     // segnalato quando il dato è pronto
    private static EventWaitHandle datoLetto;      // segnalato quando il dato è stato letto

    private static int cont = 1;
    private static int dato = 0;                   // zona di memoria condivisa per la memorizzazione del dato

    public static void Main(string[] args)
    {
        Thread[] threadConsumatori;
        Thread threadProduttore;

        // Costruisco gli oggetti EventWaitHandle impostati opportunamente
        datoPronto = new EventWaitHandle(false, EventResetMode.AutoReset);
        datoLetto = new EventWaitHandle(true, EventResetMode.AutoReset);

        threadConsumatori = new Thread[N_COMSUMATORI];

        // Faccio partire i thread consumatori
        for (int i = 0; i < N_COMSUMATORI; i++)
        {
            threadConsumatori[i] = new Thread(new ParameterizedThreadStart(consumatore));
            threadConsumatori[i].Start(i);
        }

        // Faccio partire il thread produttore
        threadProduttore = new Thread(produttore);
        threadProduttore.Start();

        // Attendo che tutti i consumatori abbiano finito
        for (int i = 0; i < N_COMSUMATORI; i++)
        {
            threadConsumatori[i].Join();
        }

        // termino il processo produttore
        threadProduttore.Abort();

        Console.Write("Fine");
        Console.ReadKey();
    }

    public static void consumatore(object info)
    {
        int id = (int)info;

        for(int i=0; i<N_LETTURE; i++)
        {
            // Attendo che un dato sia pronto
            datoPronto.WaitOne();

            // Utilizzo il dato
            Console.WriteLine("Consumatore {0}: letto {1}", id, dato);
            Thread.Sleep(1000);

           // Segnalo che il dato è stato letto
            datoLetto.Set();
        }

        Console.WriteLine("Consumatore {0} ha terminato", id);
    }


    public static void produttore(object info)
    {
        while ( true )
        {
            // attende che l'ultimo dato scritto venga consumato
            datoLetto.WaitOne();

           // produce un nuovo dato
            dato = cont++;
            Thread.Sleep(1000);
            Console.WriteLine("Produttore: ho prodotto {0}", dato);

            // segnala che un nuovo dato è pronto per essere consumato
            datoPronto.Set();
        }

        Console.WriteLine("Il produttore ha terminato");
    }

}

Ecco come si presenta l'output di una possibile esecuzione di questo codice:

Produttore: ho prodotto 1
Consumatore 3: letto 1
Produttore: ho prodotto 2
Consumatore 3: letto 2
Produttore: ho prodotto 3
Consumatore 3: letto 3
Consumatore 3 ha terminato
Produttore: ho prodotto 4
Consumatore 0: letto 4
Produttore: ho prodotto 5
Consumatore 0: letto 5
Produttore: ho prodotto 6
Consumatore 0: letto 6
Consumatore 0 ha terminato
Produttore: ho prodotto 7
Consumatore 1: letto 7
Produttore: ho prodotto 8
Consumatore 1: letto 8
Produttore: ho prodotto 9
Consumatore 4: letto 9
Produttore: ho prodotto 10
Consumatore 4: letto 10
Produttore: ho prodotto 11
Consumatore 1: letto 11
Consumatore 1 ha terminato
Produttore: ho prodotto 12
Consumatore 2: letto 12
Produttore: ho prodotto 13
Consumatore 2: letto 13
Produttore: ho prodotto 14
Consumatore 2: letto 14
Consumatore 2 ha terminato
Produttore: ho prodotto 15
Consumatore 4: letto 15
Consumatore 4 ha terminato
Fine

In particolare nell'esempio vengono utilizzati due oggetti EventWaitHandle uno datoPronto viene utilizzato dal produttore per segnalare quando un nuovo dato è disponibile mentre l'altro datoLetto viene utilizzo dal consumatore per segnalare al produttore che il dato appena prodotto è stato correttamente consumato.

E' importante notare che l'oggetto EventWaitHandle costruito utilizzando il valore EventResetMode.AutoReset corrisponde all'oggetto AutoResetEvent. L'oggetto EventWaitHandle costruito utilizzando il valore ManualResetMode.ManualReset corrisponde invece all'oggetto ManualResetEvent.

La classe RegisterWaitHandle e in particolare il suo metodo RegisterWaitForSingleObject() viene invece utilizzata per eseguire un metodo di callback quando uno specifico wait handle viene segnalato.
Per maggiori dettagli guardare l'esempio su msdn al seguente indirizzo http://msdn2.microsoft.com/en-us/library/system.threading.registeredwaithandle.aspx

[70-536] - ReaderWriterLock

Andrea Angella — Sun, 30 Mar 2008 11:37:26 GMT

Area di riferimento

- Implementing service processes, threading, and application domains in a .NET Framework application
- Develop multithreaded .NET Framework applications
- ReaderWriterLock class

ReaderWriterLock

La classe ReaderWriterLock permette di risolvere il classico problema dei lettori e scrittori su una risorsa. In particolare questo oggetto è pensato per gestire al meglio le situazioni in cui esistono tanti lettori e pochi scrittori quindi è opportuno utilizzarlo soltanto se la risorsa che viene gestita debba essere modificata poco frequentemente.

E' possibile trovare un esempio completo su msdn al seguente indirizzo: http://msdn2.microsoft.com/en-us/library/system.threading.readerwriterlock.aspx

In particolare supponendo di avere una istanza dell'oggetto ReaderWriterLock di nome rwl ( con molta fantasia direi :D ) ecco come si dovrebbe procedere per tentare un accesso in lettura alla risorsa.

try
{
   rwl.AcquireReaderLock(timeOut);
   try
   {
       // Qui è possibile effettuare una lettura della risorsa
   }
   finally
   {
       // E' importante assicurarsi di rilasciare il lock in lettura
       rwl.ReleaseReaderLock();
   }
}
catch (ApplicationException)
{
   // La richiesta di accesso in lettura è andata in time-out
}

Un codice analogo si dovrebbe scrivere per effettuare un accesso in scrittura con la sola differenza di utilizzare i metodi AcquireWriterLock(timeOut) e ReleaseWriterLock().

All'interno di un blocco in lettura è possibile effettuare una richiesta di upgrade in modo tale da poter effettuare ahce una operazione di scrittura. Il metodo UpgradeToWriterLock(timeOut) viene utilizzato proprio per questo scopo e restituisce un oggetto LockCookie che dopo aver effettuato le opportune operazioni di scrittura deve essere passato al metodo DowngradeFromWriterLock() per tornare al solo permesso in lettura.

Ecco uno spezzone di codice che mostra quello che ho appena detto:

try
{
    LockCookie lc = rwl.UpgradeToWriterLock(timeOut);
    try
    {
        // Qui è possibile sia leggere che scrivere
    }
    finally
    {
        // E' importante ricordarsi di effettuare il downgrade
        rwl.DowngradeFromWriterLock(ref lc);
    }
}
catch (ApplicationException)
{
   // La richiesta di upgrade è andata in time-out
    Interlocked.Increment(ref writerTimeouts);
}

Altri metodi che possono essere utilizzati sono ReleaseLock() e RestoreLock(ref lc) per rilasciare temporaneamente il lock il lettura e poi riprenderlo. In questo caso è importante controllare se nel frattempo si è verificato almeno un accesso in scrittura utilizzando il metodo AnyWritersSince(lastWriter) che accetta come parametro il numero di sequenza dell'ultimo scrittore che deve essere letto prima di rilasciare il lock mediante la proprietà WriterSeqNum. Ciò è necessario per confermare la validità o meno dei dati locali letti in precedenza al rilascio.

// Salva il numero di sequenza dello scrittore corrente
lastWriter = rwl.WriterSeqNum;

// Rilascia il lock
LockCookie lc = rwl.ReleaseLock();

// Riottiene il lock
rwl.RestoreLock(ref lc);

if (rwl.AnyWritersSince(lastWriter))
{
// la risorsa è cambiata, i dati locali potrebbero essere non validi
}
else
{
// la risorsa non è stata cambiata, i dati locali sono corretti
}

[70-536] - Thread Synchronization: Interlocked and Monitor classes

Andrea Angella — Wed, 27 Feb 2008 17:13:02 GMT

Area di riferimento

- Implementing service processes, threading, and application domains in a .NET Framework application
   - Develop multithreaded .NET Framework applications
      - Interlocked class
      - Monitor class

Thread Synchronization

Tutti i thread all'interno del sistema possono avere accesso a risorse condivise come le porte seriali, i file, le finestre ecc. Se un thread richiede l'accesso esclusivo a una risorsa tutti gli altri thread che hanno bisogno della stessa risorsa non potranno continuare il proprio lavoro. Per prevenire che una risorsa condivisa venga corrotta da più thread i programmatori devono utilizzare opportuni costrutti per la gestione della sincronizzazione. Microsoft Windows e il Common Language Runtime offrono molti costrutti. La maggior parte dei costrutti di sincronizzazione fra thread nel CLR sono giusto delle classi wrapper su costrutti di sincronizzazione di Win32. Infatti i threads del CLR non sono altro che dei thread di Windows e quindi questo significa che è Windows a schedulare e controllare la sincronizzazione tra i threads.

Il modo più veloce e più semplice per manipolare dati in modo thread-safe è utilizzare la famiglia di metodi interlocked. La classe Interlocked definisce un certo insieme di metodi statici che posso in modo atomico modificare una variabile.

Vediamo la dichiarazione della classe Interlocked:

public static class Interlocked
{
    // Esegue in modo atomico location++
    public static extern int Increment(ref int location);
    public static extern long Increment(ref long location);
    // Esegue in modo atomico location--
    public static extern int Decrement(ref int location);
    public static extern long Decrement(ref long location);

    // Esegue in modo atomico location1 += value
    public static int Add(ref int location1, int value);
    public static long Add(ref long location1, long value);

    // Esegue in modo atomico: if ( location1 == comparand ) location1 = value;
    public static extern int CompareExchange(ref int location1, int value, int comparand);
    public static T CompareExchange<T>(ref T location1, T value, T comparand) where T: class;
    public static extern double CompareExchange(ref double location1, double value, double comparand);
    public static extern long CompareExchange(ref long location1, long value, long comparand);
    public static extern IntPtr CompareExchange(ref IntPtr location1, IntPtr value, IntPtr comparand);
    public static extern object CompareExchange(ref object location1, object value, object comparand);
    public static extern float CompareExchange(ref float location1, float value, float comparand);

    // Esegue in modo atomico: location1 = value
    public static extern double Exchange(ref double location1, double value);
    public static extern int Exchange(ref int location1, int value);
    public static extern long Exchange(ref long location1, long value);
    public static extern IntPtr Exchange(ref IntPtr location1, IntPtr value);
    public static extern object Exchange(ref object location1, object value);
    public static extern float Exchange(ref float location1, float value);
    public static T Exchange<T>(ref T location1, T value) where T: class;
}

Il principale problema della classe Interlocked è che permette di lavorare solo su un piccolo insieme di tipi .NET.

La classe Monitor permette di gestire l'accesso in mutua esclusione a una risorsa che rappresenta la forma più comune di sincronizzazione tra thread. L'utilizzo della classe Monitor è molto semplice basta infatti racchiure il codice che rappresenta la sezione critica all'interno delle chiamate ai metodi Enter ed Exit. Il linguaggio C# offre una sintassi speciale equivalente che utilizza la parola chiave lock. I seguenti due metodi sono equivalenti:

private void Metodo()
{
    Object temp = this;
    Monitor.Enter(temp);
    try
    {
        // Sezione critica
    }
    finally
    {
       Monitor.Exit(temp);
    }
}
private void Metodo()
{
    lock (this)
    {
       // Sezione critica
    }
}

Utilizzando la classe Monitor è estremamente importante gestire le eccezioni per assicurare che il lock venga sempre rilasciato in modo da evitare una probabile situazione di deadlock. Utilizzare lo statment lock semplifica molto le cose in quanto sarà il compilatore a scrivere questo codice difensivo per noi.

L'oggetto passato ai metodi Enter ed Exit rappresenta l'oggetto utilizzato per la gestione della sincronizzazione. Ciascun reference-type ha una struttura associata ad esso chiamata sync block index che contiene un intero che rappresenta un indice all'interno di un array di sync blocks gestito dal CLR. Un sync block è un pezzo di memoria che può essere associato ad un oggetto. Quando un oggetto è costruito, il synch block index è inizializzato con un numero negativo per indicare che non "punta" a nessun sync block. Poi, quando si esegue il metodo Enter il CLR trova un sync block libero nell'array e setta il sync block index in modo che punti al sync block selezionato. Quando tutti i thread hanno rilasciato un sync block il sycn block index dell'oggetto è resettato a un valore negativo e il sycn block è considerato libero per essere associato in futuro ad un altro oggetto.

La migliore soluzione per risolver il problema della sincronizzazione e per evitare spiacevoli situazioni di deadlock è istanziare un oggetto privato all'interno della classe con il solo scopo di essere utilizzato come parametro per lo statment lock. In questo modo nessuno potrà accedere a tale campo e la gestione della sincronizzazione è demandata esclusivamente allo sviluppatore della classe stessa.

[70-536] - The Asynchronous Programming Model (APM)

Andrea Angella — Tue, 26 Feb 2008 21:50:20 GMT

Area di riferimento

- Implementing service processes, threading, and application domains in a .NET Framework application
- Develop multithreaded .NET Framework applications
- IAsyncResult interface (Refer System namespace)

The Asynchronous Programming Model (APM)

Eseguire operazioni in modo asincrono è la chiave per la costruzione di applicazioni scalabili e con alte performance. Il team di Microsoft del CLR ha progettato un pattern che rende semplice allo sviluppatore l'utilizzo della programmazione asincrona. Molte classi del framework supportano l'APM fornedo metodi del tipo BeginXXX e EndXXX. Ad esempio la classe FileStream ha un metodo Read che legge i dati dallo stream e fornisce i metodi BeginRead ed EndRead in modo da poter eseguire la stessa operazione in modo asincrono.

Eseguire operazioni di I/O in modo sincrono è molto inefficiente perchè il tempo necessario per effettuare l'operazione non è prevedibile e il thread chiamante viene sospeso e quindi diventa incapace di continuare il suo lavoro sprecando risorse. Il metodo BeginRead invece accoda una richiesta al driver del dispositivo di I/O che comunicherà direttamente all'hardware l'operazione da svolgere in modo da rendere libero il thread chiamante di continuare il suo lavoro.

Il modello APM supporta tre tecniche di rendezvous: wait-until-done, polling e method callback.

Wait-Until-Done

Per iniziare una operazione asincrona basta chiamare il metodo BeginXXX. Tutti questi metodi accodano l'operazione desiderata e ritornano un oggetto IAsyncResult che identifica la richiesta pendente. Per ottenere il risultato dell'operazione è possibile semplicemente chiamare il corrispondente metodo EndXXX passando come parametro l'oggetto IAsyncResult. Se l'operazione asincrona è stata completata quando viene chiamato il metodo EndXXX questo ritornerà immediatamente altrimenti il thread chiamante viene sospeso fino a quando l'operazione non sarà completata.

Ecco un esempio che mostra l'utilizzo di questa tecnica:

// Apro il file specificando che si desidera effettuare I/O in modo asincrono
FileStream fs = new FileStream(@"dati.dat", FileMode.Open, FileAccess.Read,
FileShare.Read, 1024, FileOptions.Asynchronous);
Byte[] buffer = new Byte[100];
// Inizia l'operazione di lettura asincrona
IAsyncResult ar = fs.BeginRead(buffer, 0, buffer.Length, null, null);
// Effettua qualche altra operazione...
// Sospende questo thread fino al completamento dell'operazione e ottiene i risultati
Int32 byteLetti = fs.EndRead(ar);
// Non ci sono altre operazioni quindi si chiude il file.
fs.Close();
// Visualizzazione dei risultati
Console.WriteLine("Numero di byte letti: {0}", byteLetti);
Console.WriteLine(BitConverter.ToString(buffer, 0, byteLetti));

Polling

L'interfaccia IAsyncResult è così definita:

[ComVisible(true)]
public interface IAsyncResult
{
    // Properties
    object AsyncState { get; }
    WaitHandle AsyncWaitHandle { get; }
    bool CompletedSynchronously { get; }
    bool IsCompleted { get; }
}

La proprietà IsCompleted può essere utilizzata dallo sviluppatore utilizzando la tecnica del polling. Questa proprietà permette allo sviluppatore di sapere se l'operazione asincrona è stata completata ma senza bloccare il thread chiamante. Vediamo un esempio di utilizzo:

// Apro il file specificando che si desidera effettuare I/O in modo asincrono
FileStream fs = new FileStream(@"dati.dat", FileMode.Open, FileAccess.Read,
FileShare.Read, 1024, FileOptions.Asynchronous);
Byte[] buffer = new Byte[100];
// Inizia l'operazione di lettura asincrona
IAsyncResult ar = fs.BeginRead(buffer, 0, buffer.Length, null, null);
while (!ar.IsCompleted)
{
// Effettua qualche altra operazione...
}
// Ottiene i risultati dell'operazione asincrona (non è bloccante!)
Int32 byteLetti = fs.EndRead(ar);
// Non ci sono altre operazioni quindi si chiude il file.
fs.Close();
// Visualizzazione dei risultati
Console.WriteLine("Numero di byte letti: {0}", byteLetti);
Console.WriteLine(BitConverter.ToString(buffer, 0, byteLetti));

Method Callback

Questa è la tecnica migliore quando si progetta una applicazione per performance e scalabilità. Il motivo è che questa tecnica non causa mai la sospensione del thread chiamante (al contrario della tecnica wait-until-done) e perchè questa tecnica non spreca mai tempo di CPU per controllare periodicamente se l'operazione asincrona è stata completata ( al contrario della tecnica del polling ).

Per prima cosa la richiesta di I/O asincrona viene accodata e il thread continua a svolgere il proprio lavoro. Quando la richiesta di I/O termina, Windows accoda un work item all'interno del thread pool del CLR. Un thread del pool preleverà il work item e chiamerà un metodo che lo sviluppatore ha scritto; questo è il modo in cui si viene a conoscenza che l'operazione richiesta è stata completata. A questo punto all'interno del metodo di callback è possibile chiamare il metodo EndXXX per ottenere il risultato dell'operazione in modo che possa essere elaborato secondo la logica applicativa. Quando il metodo ritorna, il thread del pool diventa libero di servire ulteriori richieste.

Vediamo un esempio di codice che utilizza questa tecnica:

// Il buffer è statico così che possa essere acceduto dal Main e dal metodo ReadDone
private static Byte[] buffer = new Byte[100];
static void Main(string[] args)
{
    // Apro il file specificando che si desidera effettuare I/O in modo asincrono
    FileStream fs = new FileStream(@"dati.dat", FileMode.Open, FileAccess.Read,
                                                FileShare.Read, 1024, FileOptions.Asynchronous);
    // Inizia l'operazione di lettura asincrona
    IAsyncResult ar = fs.BeginRead(buffer, 0, buffer.Length, fineLettura, fs);
    // Altre operazioni...
    Console.ReadKey();
}
static void fineLettura(IAsyncResult ar)
{
    // Estrae il FileStream (lo stato) dell'oggetto IAsyncResult
    FileStream fs = ar.AsyncState as FileStream;
    // Ottiene il risultato dell'operazione
    Int32 byteLetti = fs.EndRead(ar);
    // Non ci sono altre operazioni quindi si chiude il file.
    fs.Close();
    // Visualizzazione dei risultati
    Console.WriteLine("Numero di byte letti: {0}", byteLetti);
    Console.WriteLine(BitConverter.ToString(buffer, 0, byteLetti));
}

Affinchè all'interno del Main e del metodo ReadDone sia possibile accedere al contenuto del buffer nell'esempio si è utilizzato un buffer statico. Questa scelta in pratica non dovrebbe essere fatta in quanto non permette estensioni future. E' più corretto procedere alla costruzione di una classe che contiene il buffer e il campo FileStream in modo da poter passare un riferimento ad una sua istanza come ultimo parametro del metodo BeginRead. Questo riferimento è infatti accessibile nel metodo di callback accedendo alla proprietà AsyncState dell'oggetto IAsyncResult. In particolare questa proprietà permette di ottenere un riferimento all'oggetto sul quale è stato eseguito il metodo BeginRead in modo da poter chiamare correttamente il metodo EndRead.

E' estremamente importante chiamare sempre il metodo EndXXX all'interno del metodo di callback per evitare uno spreco di risorse ma soprattutto per sapere se l'operazione richiesta è stata completata correttamente o meno. Nel caso in cui si sia verificato un errore la chiamata al metodo EndXXX solleverà una eccezione che andrà opportunamente gestita.

Note

Alcuni metodi BeginXXX potrebbero ritornare un oggetto che implementa l'interfaccia IAsyncResult e che offre qualche tipo di metodo cancel. In questo caso significa che il thread corrente può cancellare l'operazione asincrona richiesta.

In Windows, una finestra è sempre creata da un thread e questo thread deve essere utilizzato per processare tutte le azioni per la finestra stessa (WM_MOVE, WM_PAINT, ecc.).
In quanto le Windows Forms sono costruite al di sopra di Windows, ad un thread non è permesso di accedere direttamente agli oggetti definiti nella form o in generale a una classe derivata da Control. Per questo motivo i controlli offrono tre metodi (Invoke, BeginInvoke e EndInvoke) in modo che possa essere effettuato il marshal di una operazione dal thread chiamante al thread che ha creato la finestra.

[70-536] - Timer

Andrea Angella — Thu, 03 Jan 2008 23:47:54 GMT

Area di riferimento

- Implementing service processes, threading, and application domains in a .NET Framework application
- Develop multithreaded .NET Framework applications
- Timer class, TimerCallback delegate

Timer

L'oggetto Timer del namespace System.Threading è il miglior timer da usare quando si vogliono eseguire in background dei task periodici.

Quando si costruisce una istanza di un oggetto Timer si specificano le seguenti informazioni:

Metodo da richiamare periodicamente (deve rispettare la firma del delegate TimerCallback )
Informazioni da passare al metodo di callback
Tempo di attesa prima di invocare per la prima volta il metodo di callback
Periodo di tempo tra due chiamate consecutive del metodo di callback

Ecco un esempio di utilizzo:

class Program
{
    static void Main(string[] args)
    {
        // Costruisco un nuovo timer
        Timer timer = new Timer(timer_callback, "Ciao a tutti", 1000, 2000);

        Console.WriteLine("{0}: {1}", DateTime.Now.ToLongTimeString(), "Creazione Timer");

        Console.ReadKey();

        // Rilascia le risorse allocate al Timer.
        // (necessario per evitare che il garbage collector distrugga l'oggetto timer non più referenziato)
        timer.Dispose();
    }

    // Metodo che sarà eseguito periodicamente
    static void timer_callback(object state)
    {
        string messaggio = state as string;
        Console.WriteLine("{0}: {1}", DateTime.Now.ToLongTimeString(), messaggio);
    }
}

Output del programma:

22.43.27: Creazione Timer
22.43.28: Ciao a tutti
22.43.30: Ciao a tutti
22.43.32: Ciao a tutti
22.43.34: Ciao a tutti
22.43.36: Ciao a tutti