Asynchrone Methoden

roth am Friday, 12.January 2007 um 15:43

Um Laufzeit zu sparen werden oftmals Methoden asynchron ausgeführt, dass heißt diese laufen dann in einem anderen als den Ausgangsthread. Beispiele dafür sind die Druckerausgabe und Streamoperationen. Als Richtwert sollte eine maximale Reaktionszeit von einer Zehntelsekunde auf eine Benutzerreaktion realisiert werden. An Hand eines Beispieles, welches die Größe und die Checksumme einer Datei sowie die Zeitdauer des Asynchronen Streamhandling ermittelt, soll die Umsetzung in C# gezeigt werden. Außerdem wurde berücksichtigt, dass Steuerelemente nicht mit den herkömmlichen Mitteln von einem anderen Thread aus aufgerufen werden können. Realisieren läßt sich dies mit der Control-Methode Invoke(), welche einen Delegaten und ein Objekt-Feld als Parameter erhält.

Delegaten

Der Start der asynchronen Methode erfolgt hier mit einem Button-Click.

BtnStartClick

Der Lesepuffer und die zu ermitteltenden Werte werden in der Klasse AsyncJob zusammengefaßt.

StreamLesen

In der folgenden Methode wird durch den letzten Parameter bei der Instanzierung von fStream festgelegt, dass die Leseoperation asynchron vorgenommen wird. In der Methode BeginRead wird außerdem die CallBack-Methode festgelegt.

ChecksummeLesen

Wenn der Puffer gefüllt ist wird die Rückrufmethode aufgerufen, wird die Checksumme aktualisiert und die Label-Steuerelemente werden benachrichtigt, die Werte auszugeben.

MyCallBack

Die SetStatus-Methode führt die eigentliche Aktualisierung der Steuerelemente auf dem Hauptthread aus.

SetStatus

Stellvertretend für die Ausgabe-Methoden sei hier die Funktion für die Aktualisierung des Labels für die Anzeige der Dateigröße angeführt.

SetByteText

Der Vollständigkeit halber sei darauf verwiesen,dass das Flag FortsetzenAsynchron beim Ereignis Close des Hauptfensters der Anwendung auf false gesetzt werden sollte, damit die asynchrone Methode ebenfalls ihre Aktionen einstellt.

XP-Style Manifest

roth am Wednesday, 3.January 2007 um 13:23

Der optische Stil des Non-Client-Area wird durch die ComCtrl32.dll realisiert. Mit der Version 6 darf dies nicht mehr mit den Anwendungen weitergegeben werden. Daher suchen Anwendungen standardmäßig die Version 5 auf dem Zielsystem. Für die meisten Steuerelemente wird die XP-Optik mit der Version 6 der ComCtrl32.dll umgesetzt, für Buttons, die Groupbox und die Checkbox z.B. erfolgt dies jedoch nicht. Um dennoch diesen Stil zu verwenden ist das Flag FlatStyle in den Eigenschaften des Steuerelements auf System zu stellen (die anderen Einstellmöglichkeiten sind: Flat, Popup und Standard). Der Flatstyle kann natürlich auch dynamisch in Abhängigkeit vom Betriebssystem eingestellt werden. Das hat den Vorteil, dass für ältere Anwendungen das Flag der Steuerelemente nicht geändert werden braucht.
Um den Steuerelementen mitzuteilen, dass sie die Version 6 der ComCtrl32.dll verwenden sollen, ist im Pfad der Anwendung eine XML-basierte Manifest-Datei einzufügen. Diese muss dem Namensmuster Anwendungsname.exe.manifest genügen und hat folgenden Inhalt:

  • <?xml version=”1.0″
    • encoding=”UTF-8″
    • standalone=”yes”?>
  • <assembly
    • xmlns=”urn:schemas-microsoft-com:asm.v1″
    • manifestVersion=”1.0″>
  • <dependency>
  • <dependentAssembly>
  • <assemblyIdentity
    • type=”win32″
    • name=”Microsoft.Windows.Common-Controls”
    • version=”6.0.0.0″
    • processorArchitecture=”X86″
    • publicKeyToken=”6595b64144ccf1df”
    • language=”*”
  • />
  • </dependentAssembly>
  • </dependency>
  • </assembly>

Buttons mit Bildern, wie sie im alten Look möglich waren, kennt der XP-Stil allerdings nicht; diese Buttons werden dann ohne Bilder angezeigt. Die Weitergabe der Anwendung erfolgt entweder zusammen mit der Manifest-Datei oder die Manifest-Datei wird als Ressource eingebunden. Dazu wählt man den Menüpunkt zum Hinzufügen einer neuen Ressource. In dem sich öffnenden Dialog wird dann die ‘.manifest’-Datei geladen. Der Typ der Ressource ist RT_MANIFEST und die ID ist 1.

MailMessage

roth am Wednesday, 3.January 2007 um 13:21

Die Daten die zum Versenden einer E-Mail aus einer Anwendung benötigt werden verwaltet die Klasse MailMessage, welche sich im Namespace System.Net.Mail befindet. Für die Erzeugung der notwendigen Einstellungen zum Versenden werden außerdem noch Instanzen der Klassen:

  • MailAddress
  • Attachment
  • SmtpClient
  • NetworkCredential
  • CredentialCache

erzeugt. MailAddress wird einfach mit einer E-Mail-Adresse und Attachment mit einem Dateinamen instanziert. Die Objekte werden dann jeweils den Eigenschaften From und To bzw. der Collection Attachments des MailMessage- Objektes zugewiesen. Noch einfacher ist das Setzen der Betreffzeile(Subject) und des Inhaltes(Body) durch string-Objekte. Der SmtpClient wird mit der Adresse des Mailout-Servers und dem Port (gewöhnlich 25) instanziert und versendet die E-Mail. NetworkCredential verwaltet die Server-Zugangsdaten(Benutzer,Passwort) und CredentialCache die ggf. verschiedenen Zugangsdaten und Serveradressen.
Ein einfaches Code-Beispiel:

  • string server = “mailout.de”;
  • string user = “user”;
  • string pass = “passwort”;
  • using System.Net.Mail;
  • MailMessage msg = new MailMessage();
  • msg.From = new MailAddress(”absender@net.de”);
  • MailAddress e1 = new MailAddress(”e1@net.de”);
  • msg.To.Add(e1);
  • msg.Subject = “Betreff”;
  • msg.Body = “Blabla”;
  • Attachment at = new Attachment(”datei.txt”);
  • msg.Attachments.Add(at);
  • SmtpClient sc = new SmtpClient(server,25);
  • NetworkCredential nc= new NetworkCredential(user,pass);
  • CredentialCache cc = new CredentialCache();
  • cc.Add(server,25,”Basic”,nc);
  • sc.DeliveryMethod = SmtpDeliveryMethod.Network;
  • sc.Credentials = cc.GetCredential(server,25,”Basic”);
  • sc.Send(msg);

Die Zugangsdaten sind sinnvollerweise nicht ungeschützt zu speichern. Dazu kann die Klasse IsolatedStorageFile im Namespace System.IO genutzt werden.

Isolierter Speicher

roth am Wednesday, 3.January 2007 um 13:19

Anwendungen können mit dem isolierten Speicher Daten in einem eigenen Abschnitt des Dateisystems speichern, ohne dass sie einen bestimmten Pfad angeben zu müssen. Der Gültigkeitsbereich von isoliertem Speicher ist auf die jeweilige Assembly zugeschnitten, so dass die Daten nur einmal eingegeben werden müssen. Vertrauenswürdiger Code, Verwaltungstools und nicht verwalteter Code können auf den isolierten Speicher ebenfalls zugreifen.

Das folgende Code-Beispiel soll an Hand der Klassen IsolatedStorageFile und IsolatedStorageFile das Speichern von Zugangsdaten für das Versenden von E-Mails demonstrieren. Es wurden vier Alternativen berücksichtigt:

1.Der User meldet sich mit seinen Daten das erste mal an.
2.Die Zugangsdaten sind bereits gespeichert und werden ausgelesen.
3.Es sollen neue Zugangsdaten gespeichert werden.
4.Alle gespeicherten Zugangsdaten sollen gelöscht werden.

Der vereinfachte Code für die Anwendung (ohne Implementierung der Ein/Ausgaben und Ausnahmebehandlung):

  • class Mailzugang
  • {
    • [STAThread]
    • static void Main(string[] args)
    • {
      • neueslogin = GetSpeicher(username);
      • if (neueslogin)
        • SetSpeicher();
      • else
      • {
        • if(andereslogin)
          • SetNeuenSpeicher();
        • if(loeschen)
          • Loeschen();
      • }
    • }
  • }

Für dieses Beispiel sind in der Klasse Mailzugang die Variablen/Eigenschaften aufzunehmen:

  • //die zu speichernden Daten
  • string server;
  • string loginname;
  • string passwort;
  • //Identifizierung der Daten
  • //hier der am Rechner angemeldete Benutzer
  • string username = Environment.UserName;
  • //Flag für die Speicherung
  • //true=noch kein Speicher angelegt
  • //false=Speicher bereits angelegt
  • bool neueslogin;
  • //Flag für die Speicheränderung
  • //true=Ändern des Speichers
  • //false=Auslesen des Speichers
  • bool andereslogin;
  • //Flag für die Löschung des Speichers
  • bool loeschen;

Die Implementierung der Methoden der Klasse Mailzugang:

  • bool GetSpeicher()
  • {
    • try
    • {
    • IsolatedStorageFile iFile =
      • IsolatedStorageFile.GetStore(
        • IsolatedStorageScope.User |
        • IsolatedStorageScope.Assembly |
        • IsolatedStorageScope.Domain,
        • null,null);
    • IsolatedStorageFileStream iStream =
      • new IsolatedStorageFileStream(
        • this.username,
        • FileMode.Open,
        • FileAccess.Read,
        • FileShare.Read);
    • StreamReader reader =
      • new StreamReader(iStream);
    • this.server    = reader.ReadLine();
    • this.loginname = reader.ReadLine();
    • this.passwort  = reader.ReadLine();
    • reader.Close();
    • iFile.Close();
    • return false;
    • }
    • catch (System.IO.FileNotFoundException)
    • {
      • // Wenn keine Datei gefunden werden kann,
      • // muss es sich um einen neuen Nutzer handeln
      • return true;
    • }
  • }
  • void SetSpeicher()
  • {
    • IsolatedStorageFile iFile =
      • IsolatedStorageFile.GetUserStoreForDomain();
    • IsolatedStorageFileStream iStream =
      • new IsolatedStorageFileStream(
        • this.username,
        • FileMode.OpenOrCreate,
        • FileAccess.Write,
        • iFile);
    • StreamWriter writer =
      • new StreamWriter(iStream);
    • writer.WriteLine(this.server);
    • writer.WriteLine(this.loginname);
    • writer.WriteLine(this.passwort);
    • writer.Close();
    • iFile.Dispose();
    • iFile.Close();
  • }
  • SetNeuenSpeicher()
  • {
    • byte input;
    • IsolatedStorageFile iFile =
      • IsolatedStorageFile.GetStore(
        • IsolatedStorageScope.User |
        • IsolatedStorageScope.Assembly |
        • IsolatedStorageScope.Domain,
        • typeof(System.Security.Policy.Url),
        • typeof(System.Security.Policy.Url));
    • if (! this.neueslogin)
    • {
      • if ( iFile.GetDirectoryNames(
        • “Archive”).Length == 0 )
        • iFile.CreateDirectory(”Archive”);
      • else
      • {
        • IsolatedStorageFileStream source =
          • new IsolatedStorageFileStream(
            • this.username,
            • FileMode.OpenOrCreate,iFile);
        • IsolatedStorageFileStream target =
          • new IsolatedStorageFileStream(
            • “Archive\\ ” + this.username,
            • FileMode.OpenOrCreate,
            • FileAccess.Write,
            • FileShare.Write,
            • 10240,
            • iFile);
        • if (!(source.IsAsync && target.IsAsync))
        • {
          • while (source.Position < source.Length)
          • {
            • input = (byte)source.ReadByte();
            • target.WriteByte(inputChar);
          • }
        • }
        • target.Close();
        • source.Close();
      • }
    • }
    • IsolatedStorageFileStream iStream =
      • new IsolatedStorageFileStream(
        • this.username,
        • FileMode.OpenOrCreate,
        • FileAccess.Write,
        • FileShare.Write,
        • 10240,
        • iFile);
    • iStream.Position = 0;
    • StreamWriter writer = new StreamWriter(iStream);
    • writer.WriteLine(this.Server);
    • writer.WriteLine(this.loginname);
    • writer.WriteLine(this.passwort);
    • writer.Close();
    • iFile.Close();
  • }
  • void Loeschen()
  • {
    • IsolatedStorageFile iFile =
      • IsolatedStorageFile.GetStore(
        • IsolatedStorageScope.User |
        • IsolatedStorageScope.Assembly |
        • IsolatedStorageScope.Domain,
        • typeof(System.Security.Policy.Url),
        • typeof(System.Security.Policy.Url));
    • string [] dirNames  = iFile.GetDirectoryNames(”*”);
    • string [] fileNames = iFile.GetFileNames(”*”);
    • if (fileNames.Length>0)
    • {
      • for (int i=0;i<fileNames.Length;++i)
      • {
        • iFile.DeleteFile(fileNames[i]);
      • }
      • fileNames = iFile.GetFileNames(”*”);
    • }
  • }

Das Auflisten und Entfernen der Dateien im isolierten Speicher kann mit dem Isolated Storage-Tool Storeadm.exe erfolgen. Um IsolatedStorage-Klassen zu verwenden ist der Namespace System.IO.IsolatedStorage für die Speicherreservierung mit GetStore() der Namespace System.Security.Policy einzubinden.

Resourcen

roth am Monday, 13.November 2006 um 11:36

Zum Erstellen von Resourcen werden das Programm resgen und speziell für Forms-Elemente das Programm winres verwendet. In den Entwicklungsoberflächen sind diese meist bereits integriert.

1. Manuelles Erstellen von string-Resourcen
Zuesrt erstellt man eine *.txt-Datei nach dem Schema

  • name=wert

Danach ruft man

  • resgen dateiname.txt

in der Eingabeaufforderung auf und es wird die binäre Resourcen-Datei dateiname.resources erzeugt. Soll diese einen anderen Namen erhalten ist dieser an den Befehl anzuhängen.

2. Manuelles Erstellen von Resourcen mit Hilfe der Klassenbibliothek
Um z. B. Bilder oder Musik in Resourcen zu verpacken erzeugt man zuerst *.resx-Dateien. Dies am sinnvollsten mit der Klasse ResXResourceWriter:

  • Image img
    = Image.FromFile(”muster.jpg”);
  • ResXResourceWriter rrw
    = new ResXResourceWriter(”muster.resx”);
  • rrw.AddResource(”muster.jpg”,img);
  • rrw.Close();

Die *.resx-Datei kann dann wiederum mit resgen in eine *.resource-Datei gewandelt werden.

3. Lokalisieren von Anwendungen
Um Anwendungen in mehreren Sprachen zu erstellen, werden diese lokalisiert. Das bedeutet man erzeugt Resourcen-Dateien in verschiedenen Sprachen, welche zur Laufzeit entsprechend der Sprache des Anwendungssystems eingebunden werden. Wird keine Resource für das entsprechende Anwendersystem gefunden (die lokalisierte Kultur ist auf dem System nicht vorhanden) wirkt das Ressourcenfallback, welches eine Standardresource verwendet. Die verschiedenen Sprachversionen der Resourcen müssen in eigenen Ordnern unter der Anwendung plaziert werden. Die Sprach- und Länderbezeichnung ist fest vorgegeben. So bedeutet z.B.

  • de deutsch
  • de-DE deutsch Deutschland
  • de-AT deutsch Österreich
  • en englisch
  • fr französisch

(Die Dateien mit Länderbezeichnung (z.B. de-DE) befinden sich in den Ordnern der Sprachbezeichnung (z.B. de)

Mit Visual Studio und SharpDevelop können Windows-Anwendungen im Designer wie folgt lokalisiert werden:

  • Die Form-Eigenschaft Localizable des Fensters auf True stellen.
  • Die Eigenschaft Language auf Standard stellen.
  • Die einzelnen Steuerelemente anwählen und die Eigenschaft Text in der Standardsprache eintragen.
  • Danach die Language-Eigenschaft des Fensters auf die gewünschte Sprache umstellen und die Steuerelemente erneut anwählen und nun in der jeweiligen Sprache die Text-Eigenschaft bedienen.

Mit dem Kompilieren werden für alle eingestellten Sprach- bzw. Kulturversionen sogenannte Satellitenassemblies (DLL) erstellt. Unter Einhaltung der Namenskonventionen in den Resourcen können damit Anwendung und Resource unabhängig voneinander ausgetauscht werden. Soll die zu verwendende Sprach- bzw. Kulturversion von der Anwendung selbst und nicht vom Anwendersystem bestimmt werden, muss vor Aufruf der Methode InitializeComponent die Einstellung der entsprechenden Version vorgenommen werden:

  • Thread.CurrentThread.CurrentUICulture
    = new CultureInfo(”de-DE”);

Werden außer den Steuerelementobjekten weitere lokalisierte Resourcen benötigt, z.B. für dynamisch zu ändernde Texte, sind diese den sprachverschiedenen Resourcendateien der IDE hinzuzufügen.

4. Einlesen lokalisierter Resourcen
Um Resourcen zur Laufzeit zu verwenden, wird der ResourcenManager verwendet.
Variante 1
Man instanziert mit einem der drei möglichen Konstruktoren von ResourceManager.
Beispiel:

  • ResourceManager rm
    = new ResourceManager(
    “namespace.MainForm”,
    this.GetType().Assembly);
  • CultureInfo ci = new CultureInfo(”en”);
  • this.Text = rm.GetString(”Titel”,ci);

Soll die Sprach- bzw. Kulturversion der Anwendung angezeigt werden, kann natürlich auf die Angabe der CultureInfo verzichtet werden.

Variante 2
Man erzeugt einen ResourceManager mit der statischen Methode CreateFileBasedResourceManager. Dies dient dem Zugriff auf Resourcen in einem bestimmten Verzeichnis.

  • ResourceManager rm
    = ResourceManager.
    CreateFileBasedResourceManager(
    “baseName”, “./path”, null);

 

5. Assembly-Linker-Tool
Mit dem Assembly-Linker-Tool Al.exe. können Ressourcen-dll auch mit der Konsole erzeugt werden. Beispiel:

  • al /t:lib
    • /embed: name.de.resources
    • /version:1.0.0.1
      /culture:de
    • /out:name.resources.dll

Testen mit NUnit

roth am Wednesday, 30.August 2006 um 12:08

Speziell zum Testen von NET.DLL’s eignet sich das Programm NUnit (derzeitige Version 2.2) welches unter http://www.nunit.org/ kostenlos downzuloaden ist. Verwenden lässt sich dieses Testprogramm sowohl als Konsolenprogramm mit nunit-console.exe als auch mit Windowsoberfläche mit nunit-gui.exe. Eine Konfiguration ist über die XML-Konfigurationsdateien nunit-console.exe.config bzw. nunit-gui.exe.config möglich. Die Anwendung ist wie folgt zu realisieren:

  • Die Klassenbibliothek “nunit.framework.dll” ist in das Verzeichnis der zu testenden Anwendung zu kopieren.
  • Um NUnit anzuwenden, muss die zu testende Klasse mit dem Attribut [Serializable] versehen werden und ein Verweis mit using namespace NUnit::Framework;” bei Managed Extensions bzw. mit “using NUnit.Framework;” herzustellen.
  • Für die Aufnahme der Testfunktionen ist ein Klassenbibliothek-Projekt zu erstellen, welches sich sinnvollerweise in der gleichen Projektmappe wie die zu testende Anwendung befindet.
  • Die Testklasse erhält das Attribut [TestFixture].
  • Zur Initialisierung kann eine Funktion das Attribut [SetUp] erhalten.
  • Alle Testfunktionen sind vom Typ: public: void TestFunktion(void) und erhalten das Attribut [Test].
  • Über den Button “Help”/”About Unit” lässt sich die verwendete NET-Framework-Version(1.0, 1.1, 2.0) feststellen (GUI-Variante).

Man unterscheidet bei den Tests zwischen Vergleichen, Wahrheitstest und sonstige Methoden. Alle Tests werden über statische Methoden der Klasse Assert in den Testfunktionen aufgerufen. Der Aufruf kann ohne oder mit Nachricht und/oder Objektparametern erfolgen. Diese sind vom Typ string(String*) bzw.  object[] (Object* params __gc[] ); in Klammern die Managed Extension-Version. Nachricht und Objektparameter werden als letzte Parameter in dieser Reihenfolge übergeben.

1. Vergleichen:

Assert.AreEqual(typ erwartet, typ aktuell … ); als typ kann verwendet werden: int, decimal, float, double, object. Die Typen float und double erhalten noch einen zusätzlichen Parameter für die Toleranz, welcher als dritter parameter übergeben wird.

Assert.AreSame(object erwartet, object aktuell …) testet ob beide Parameter auf das gleiche Objekt verweisen. AreEqual testet dagegen nur, ob die gleichen Werte vorliegen.

2. Wahrheitstests:

Assert.IsTrue / IsFalse(bool …)

Assert.IsNull / IsNotNull(object …)

3. Sonstige Methoden:

Hier existieren die Methoden Fail und Ignore. Fail löst eine Assertion aus, Ignore verhindert die weitere Durchführung des Tests.

Im Programm NUnit wird zum Testen der Anwendung die Test-Klassenbibliothek geladen, wobei zu beachten ist, dass bei Änderungen und Neukompilierung diese erneut geladen wird. Danach wird der Test mit “Run” gestartet. Das Ergebnis wird in der GUI-Variante wie folgt farbig dargestellt:

Grün: Der Test verlief erfolgreich.

Rot: Der Test wurde mit einer Assertion abgebrochen, ggf. werden die übergebenen Textmeldungen zusätzlich ausgegeben.

Gelb: Der Test wurde nicht durchgeführt.

Weitere Attribute:

[ExpectedException(typeof(…))] - der Test läuft auch bei Auslösen der entsprechenden Ausnahme weiter.

[Category(”Kategoriename”)] - dient dem Gruppieren von Tests und wird auf Methoden angewandt, welche das [Test]-Attribut erhalten haben.

Explicit zusätzlich in [TestFixture] oder [Test] um diesen Test auszuschließen und diesen separat durchzuführen.

Konfigurationsdatei

roth am Monday, 21.August 2006 um 18:00

Konfigurationsdateien
Konfigurationsdateien werden eingesetzt, um Einstellungen für Anwendungen zu verändern ohne diese neu kompilieren zu müssen. Ähnlich den INI-Dateien und den Registry-Einträgen können damit auch im NET-Framework die Anwendungen den persönlichen Bedürfnissen angepasst werden. Die Speicherung der Konfiguration erfolgt im XML-Format. Man unterscheidet Konfigurationsdateien für Computer, Sicherheit und Anwendungen.

A. Computerkonfiguartionsdateien
Enthält Einstellungen, welche für den gesamten Computer gelten. Sie befinden sich im: %Installationspfad der CLR% \ Config \ Machine.config

B. Sicherheitkonfigurationsdateien
Enthalten Informationen zur Codegruppenhierarchie und zu Berechtigungen, die einer Richtlinienebene zugeordnet sind. Man unterscheidet:

  • Unternehmensrichtlinien in %Installationspfad der CLR% \ Config \ Enterprisesec.config
  • Computerrichtlinien in %Installationspfad der CLR% \ Config \ Security.config
  • Benutzerrichtlinien in %BENUTZERPROFIL%\Application data\Microsoft\CLR security config\vxx.xx\Security.config

C. Anwendungskonfiguartionsdateien
Diese Dateien enthalten z.B. Assemblybindungsrichtlinien, Remotingobjekte und Anwendungseinstellungen. Folgende Bedingungen sind dabei zu beachten:

  • Die Konfigurationsdatei hat den Namen: Name_der_Anwendung.config bzw. bei von ASP.NET gehosteten Anwendungen Web.config
  • Die Konfigurationsdatei befindet sich im gleichen Verzeichnis wie die zu konfigurierende Anwendung
  • Das Root-Element der Konfigurationsdatei lautet <configuration>
  • Die Konfigurationsdateien sind nicht für den Einsatz in Multiuser-Umgebungen geeignet.

 

1. Schlüssel/Wert-Paare
Die einfachste Art Konfigurationseinstellungen vorzunehmen ist die Verwendung des Tags <appSettings>, welcher das Speichern von Schlüssel/Wert-Paaren realisiert.
Beispiel:

  • <configuration>
    • <appSettings>
      • <add key=”Farbe” value=”#669933″/>
      • <add key=”Datei” value=”name.txt”/>
    • </appSettings>
  • </configuration>

Das Auslesen der Konfigurationsdatei erfolgt im Konstruktur der Anwendung mit der statischen Eigenschaft AppSettings der Klasse ConfigurationSettings.
Beispiel:

  • NameValueCollection cfg
  • = ConfigurationSettings.AppSettings;
  • this.BackColor
  • = Color.FromName((string) cfg[”Farbe”]);
  • this.File
  • = (string) cfg[”Datei”];

Zur Demonstration steht ein Beispielprogramm und dessen Quelltext zum Download.

2. Sektionen
Komplexere Konfigurationen lassen sich mit der Definition von Sektionen realisieren. Doppelt verwendete Schlüssel-Namen sind damit kein Problem mehr. Umgesetzt wird dies durch die Tags <configSections>und <section>. Das Attribut “type” erhält in der Mehrzahl der Fälle als Wert einen der zwei Klassennamen SingleTagSectionHandler oder NameValueSectionHandler .
Beispiel:

  • <configuration>
    • <configSections>
      • <section name=”Sektion1″
      • type=”System.Configuration
      • .SingleTagSectionHandler”/>
    • </configSections>
    • <Sektion1 Farbe=”#669933″
    • Datei=”name.txt”/>
  • </configuration>

Das Auslesen erfolgt hier ähnlich wie bei 1. mit der Methode GetConfig() der Klasse ConfigurationSettings.
Beispiel:

  • IDictionary skin
  • =(IDictionary) ConfigurationSettings.GetConfig(”Sektion1″);
  • this.File
  • =(string) Sektion1[”Datei”];
  • this.BackColor
  • =Color.FromName((string) Sektion1[”Farbe”]);

 

3. Erweiterte Sektionen
Um die Konfigurationsdaten in einer Baumstruktur zu ordnen, wird zusätzlich zu 2. das Tag <sectionGroup> mit dem Attribut “name” verwendet.
Beispiel:

  • <configuration>
    • <configSections>
      • <sectiongroup name=”Gruppe1″>
        • <section name=”Sektion1″
        • type=”System.Configuration
        • .NameValueSectionHandler,
        • system,
        • Version=1.2.3456.0,
        • Culture=neutral,
        • PublicKeyToken
        • =123456789abcdef0″/>
        • <section name=”Sektion2″
        • type=”System.Configuration
        • .NameValueSectionHandler,
        • system,
        • Version=1.2.3456.0,
        • Culture=neutral,
        • PublicKeyToken
        • =123456789abcdef0″/>
      • </sectionGroup>
    • </configSection>
    • <Gruppe1>
      • <Sektion1 Color=”#669933″
      • File=”name1.txt”/>
      • <Sektion2 Color=”#996633″
      • File=”name2.txt”/>
    • </Gruppe1>
  • </configuration>

Für das Auslesen der Konfigurationsdatei müssen mehrere Dictionary-Objekte erzeugt werden, welche mit dem entsprechenden Pfadausdruck als Parameter aus dem Rückgabewert der Methode GetConfig() erhalten werden.
Beispiel:

  • IDictionary sec1
  • =(IDictionary)ConfigurationSettings
  • .GetConfig(”Gruppe1/Sektion1″);
  • this.Color1
  • = Color.FromName((string) sec1[”Color”]);
  • this.File1
  • = (string) sec1[”File”];
  • IDictionary sec2
  • = (IDictionary) ConfigurationSettings
  • .GetConfig(”Gruppe1/Sektion2″);
  • this.Color2
  • = Color.FromName((string) sec2[”Farbe”]);
  • this.File2 = (string) sec2[”Datei”];

 

Sonstige Einstellungen
Zur Angabe der von der Anwendung unterstützten Framework-Version:

  • <startup>
    • <supportedRuntime version=”v1.1.4322″/>
  • </startup>

Zur Angabe wo eine Assembly gefunden werden kann:

  • <codeBase version=”1.2.3.0″
  • href=”http://www.twox.de/source/ass.dll” mce_href=”http://www.twox.de/source/ass.dll” />

Attribute

roth am Monday, 31.July 2006 um 16:04

Attribute des Framework(Auszug)

1. [AttributeUsage(AttributeTargets::Method, AllowMultiple=true,  Inherited=true)]

Wird zur Steuerung der Verwendung benutzerdefinierter Attribute verwendet. Es besitzt die

Eigenschaften: AttributeTargets ValidOn{ get;} ; bool AllowMultiple{ get: set;} ; bool Inherited{ get; set;}

AttributeTargets verweist auf den Art des atrributierten Programmelements. Verwendet werden können:All, Assembly, Class, Constructor, Delegate, Enum, Event, Interface, Method, Field, Module, Parameter, Property, ReturnValue, Struct. AllowMultiple gibt an, ob für ein Programmelement mehr als eine Instanz des Attributes angegeben werden kann. Inherited legt fest, ob das Attribut von abgeleiteten Klassen oder überschriebenen Membern überschrieben werden darf.

2. [Flag]

Eine Enumeration wird als Bitfeld festgelegt. Das bedeutet, die Enumerationskonstanten können mit dem bitweisen OR-Operator behandelt werden.

3. [Description(”Beschreibung”)]

Beschreibung für eine Eigenschaft oder ein Ereignis.

4. [assembly:CLSCompliant(true)]

Gibt an, ob ein Programmelement mit der CLS kompatibel ist. Jeder öffentlich gemachte aber nicht CLS-kompatible Typ muss mit diesem Attribut mit dem Parameter false gekennzeichnet werden (z.B. UInt32). Wenn mit assembly attributiert wird, ist das Attribut auf die geamte Assembly angewendet.

5. [Serializable], [NonSerialized]

Die Anwendung dieser Attribute ist im Artikel Serialisieren beschrieben.

6. STAThread

Mit STAThread wird Singlethreaded Apartment als COM-Threadingmodell für Anwendungen festgelegt.

Benutzerdefinierte Attribute:

Eigene Attribute sollten immer von der Klasse System::Reflection::Attribute abgeleitet werden. Die benutzerdefinierte Attributklasse muss mit dem Attribut AttributUsage (siehe oben) markiert werden und sollte geeignete Konstruktoren und Eigenschaften aufweisen.  

Der Zugriff auf die Attribute erfolgt mit der Klasse MemberInfo, welche an die Klasse gebunden wird, deren Attribute erfragt werden sollen. Mit der Methde GetCustomAttributes dieser Klasse wird dann auf die Attribute zugegriffen.

  • MemberInfo* pInfo =
  •     __typeof(Klassenname);
  • Object* att __gc[];
  • att = pInfo->GetCustomAttributes(
  •     __typeof(Attributname),true);
  • for( int i = 0; i < attributes->Length; i++ )
  • {
    • Console::Write((__try_cast(
    •     attributes[i]))->Eigenschaft) ;
  • }

Für das Abrufen von Informationen aus einer .NET-DLL kann das Dienstprogramm  ILDASM.exe, welches in der Standardinstallation von Visual.NET enthalten ist, verwendet werden. Der Namensraum System.Reflection.Emit enthält Klassen,um Typen zur Laufzeit zu erstellen. Demoprogramm und Quellcode
 

Exception

roth am Friday, 21.July 2006 um 18:39

Vordergründig sollte man vordefinierte Ausnahmetypen verwenden. Benutzerdefinierte Ausnahmetypen definiert man daher nur für programmspezifische Szenarien. Sie sollten nicht von der Exception-Basisklasse abgeleitet werden. Für die meisten Anwendungen ist die Ableitung von der ApplicationException-Klasse am geeignetsten. Der Name einer benutzerdefinierten Ausnahmeklasse sollte mit Exception enden.

Benutzerdefinierte Ausnahmen sollten die folgenden allgemeinen Konstruktoren enthalten, das Attribut [Serializable] besitzen und die Schnittstelle ISerializable mit der GetObjectData()-Methode implementieren.

  • [Serializable]
  • public class BenutzerException
                 : ApplicationException,
  •                ISerializable
  • {
    • public BenutzerException(){}
    • public BenutzerException(string msg)
    •        :base(msg){}
    • public BenutzerException(string msg,
    •                          Exception exc)
    •        :base(msg,iexc){}
    • public BenutzerException(
    •                SerializationInfo info,
                     StreamingContext context)
    •        :base(info,context){}
  • }

Werden zusätzliche Variablen in die Klasse aufgenommen sind diese nicht public und ggf. als Eigenschaft zu deklarieren. Durch überschreiben der Eigenschaft “Message” können diese Variablen in die Fehlerbenachrichtigung aufgenommen werden.

Die üblichen try-catch-Blöcke zum Auffangen von Ausnahmen können auch verschachtelt werden, so dass eine aufgefangene Ausnahme das Auslösen einer anderen Ausnahme bewirkt. Die Ausnahmen werden umgebrochen bzw. weitergeleitet. Dazu wird im catch-Block am Ende sinngemäß der Code

  • throw new Exception ( “Nachricht.”, e );

plaziert. Zwischen den Konfigurationen Debug und Release ist zu beachten, dass verschiedene Werte aus der Debug-Variante in der Release-Variante (wie z.B. die Zeilennummer) nicht zur Verfügung stehen und demzufolge auch nicht angezeigt werden können (bei der Zeilennummer z.B. ist dies in der Eigenschaft StackTrace). Letztendlich kann noch der finally-Block für Aufräumarbeiten wie Schließen einer Datei oder eines Streams genutzt werden. 

Das Beispiel-Programm “Ausnahmen.exe (in Ausnahmen.zip)” demonstriert die Verschachtelung von try-catch-Blöcken mit dem Speichern der Ausnahmeinformationen, welche dann über ein nichtmodales Fenster angezeigt werden können.

Beispielcode: XmlException-Klasse

Die XmlException wird ausgelöst, wenn ein an den XmlTextReader übergebener Code nicht wohlgeformt ist.
 

  • XmlTextReader tr       
  •    = new XmlTextReader( “datei.xml” );
  • XmlValidatingReader vr
  •    = new XmlValidatingReader(tr);
  • vr.ValidationType = ValidationType.None;
  • try
  • {
    • while(vr.Read());
  • }
  • catch(XmlException exc)
  • {
    • string err;
    • err += exc.Message + “\n”     +
    •        “Ausnahme auf Zeile: ” +
    •        exc.LineNumber         +
    •        “, Position: “         +
    •        exc.LinePosition + “\n”;
    • MessageBox.Show(err);
  • }

Serialisieren

roth am Monday, 17.July 2006 um 17:34

Um die Daten von Klassen für die Speicherung und Wiederherstellung zu serialisieren, gibt verschiedene Möglichkeiten.
1. Einfache Serialisierung:
Die zu serialisierende Klasse wird mit dem Attribut [Serializable] versehen. Es werden alle Membervariablen serialisiert.
2. Benutzerdefinierte Serialisierung:
Wie 1. , die zu serialisierende Klasse implementiert aber die Schnittstelle ISerializable. Es muss

void GetObjectData ( SerializationInfo* info,
                     StreamingContext   context )

und der spezielle Deserialisierungs-Konstruktor

protected MyClass ( SerializationInfo* info,
                    StreamingContext   context )

implementiert werden. Damit kann die Serialisierung bzw. die Deserialisierung zusätzlich beeinflusst werden, um z.B. die Konsistenz der Daten zu garantieren. Der Zugriff auf vertrauliche Informationen über die Methode GetObjectData kann noch durch das Attribut

[ SecurityPermissionAttribute
  ( SecurityAction::Demand,
    SerializationFormatter = true )]

eingeschränkt werden. Beispiel:

  • [Serializable]
  • public __gc class Class2Serial
                      : public ISerializable
  • {
    • public:
    • String* serialVariable;
    • Class2Serial ( String* strVar )
    • {
      • serialVariable = strVar;
    • }
    • void GetObjectData (
                SerializationInfo* info,
                StreamingContext   context )
    • {
      • info->AddValue ( “serialVariable”,
                         serialVariable );
    • }
    • protected:
    • Class2Serial ( SerializationInfo* info,
                     StreamingContext   context)
    • {
      • serialVariable
           = info->GetString (
                    S”serialVariable” );
    • }
  • } ;

3. Deserialisieren von ausgeschlossenen Membervariablen
Um das Datenvolumen zum Serialisieren zu reduzieren, können nicht notwendigerweise zu serialisierende Daten, welche z.B. nur von anderen Variablen abhängig sind, von der Serialisierung ausgeschlossen werden. Bei der Deserialisierung muss natürlich dafür gesorgt werden, dass diese wieder hergestellt werden. Dies realisiert die in der Schnittstelle IDeserializationCallback enthaltene Methode

void OnDeserialization ( Object* sender ),

welche implemtiert werden muss. Diese wird dann nach dem Deserialisierungs-Konstruktor aufgerufen und stellt die Konsistenz der Daten her. Die Serialisierung erfolgt wie bei 2. mit GetObjectData, die Deserialisierung mit dem Deserialisierungs-Konstruktor.
Beispiel:

  • [Serializable]
  • public __gc class Class2Serial
                      : public IDeserializationCallback
  • {
    • public:
    • String* serialVariable;
    • [NonSerialized]
    • String* nonserialVariable;
    • public Class2Serial( String* strVar )
    • {
      • serialVariable    = strVar;
      • nonserialVariable = String::Concat(
                            S”Wert=”, strVar );
    • }
    • // Memberfunktion von IDeserializationCallback
    • void OnDeserialization ( Object* sender )
    • {
      • nonserialVariable = String::Concat(
                            S”Wert=”,
                            serialVariable );
    • }
    • // Methode von ISerializable zum Serialisieren
    • void GetObjectData (
                SerializationInfo* info,
                StreamingContext   context)
    • {
      • info->AddValue ( S”serialVariable”,
                         serialVariable );
    • }
    • // Deserialisierungs-Konstructor
    • protected:
    • Class2Serial ( SerializationInfo* info,
                     StreamingContext   context )
    • {
      • serialVariable
          = info->GetString (S”serialVariable”);
    • }
  • };

4. Serialisieren mit Surrogaten
Wenn Klassen implementiert werden, welche das Attribut [Serializable] nicht besitzen, muss eine Klasse implementiert werden, die die Schnittstelle ISerializationSurrogate einbezieht. Diese Klasse kann dann wie die vorgehenden Klassen serialisiert werden. Dazu sind die Methoden

void GetObjectData ( Object*            obj,
                     SerializationInfo* info,
                     StreamingContext   context )

und

Object* SetObjectData ( Object*             obj,
                        SerializationInfo*  info,
                        StreamingContext    context,
                        ISurrogateSelector* selector )

zu überschreiben.
Beispiel:

  • public __gc class Class2Serial
  • {
    • public:
    • String* serialVariable;
    • Class2Serial (String* strVar)
    • {
      • serialVariable = strVar;
    • }
  • } ;
  • public __gc class Class2SerialSurrogate
                      : public ISerializationSurrogate
  • {
    • public:
    • // Methode zum Serialisieren
    • void GetObjectData (
            Object*            obj,
            SerializationInfo* info,
            StreamingContext   context )
    • {
      • Class2Serial* classSerial
            = __try_cast<Class2Serial*>( obj ) ;
      • info->AddValue (
              S”serialVariable”,
              classSerial->serialVariable );
    • }
    • // Methode zur Deserialisierung
    • Object* SetObjectData (
                Object*             obj,
                SerializationInfo*  info,
                StreamingContext    context,
                ISurrogateSelector* selector )
    • {
      • Class2Serial* classSerial
            = __try_cast<Class2Serial*>( obj ) ;
      • classSerial->serialVariable
            = info->GetString (
                S”serialVariable” );
      • return classSerial;
    • }
  • } ;

5. Serialisieren von Werten aus verschiedenen Klassen
Der Benutzer kann bei dieser Variante bestimmen, welche Klasse für das Serialisieren verwendet werden soll. Dazu wird eine von SerializationBinder abgeleitete Klasse erstellt, welche eine überschriebene Methode

 

Type* BindToType ( String* assemblyName,
                   String* typeName )

enthält. Diese bindet dann die verschiedenen Klassen mit den unter gleichem Namen serialisierten Werten. Die Eigenschaft Binder des Formatters wird dann auf die jeweils zu verwendende Bindung eingestellt. Ebenso können die serialisierten Werte aus verschiedenen Assemblies verwendet werden.
Beispiel:

  • __sealed __gc class Class1ToClass2Binder
                  : public SerializationBinder
  • {
    • public:
    • Type* BindToType ( String* assemblyName,
                         String* typeName )
    • {
      • Type* type   = NULL;
      • String* strT = S”.Class2Serial”;
      • if ( String::Compare( strT,
                        typeName ) == 0 )
      • {
        • typeName = S”.Class2SerialBind”;
      • }
      • String* strTyp
          = String::Format(”{0}, {1}”,
                           typeName,
                           assemblyName);
      • type = Type::GetType( strTyp, true );
      • return type;
    • }
  • } ;

Die Anwendung der verschiedenen Serialisierungen erfolgt nach dem Schema:

  • Erzeugen eines Streams (z.B. FileStream)
  • Ereugen eines Formatters (z.B. BinaryFormatter oder SoapFormatter)
  • Zusätzlich bei der obigen Variante 4.
    • Erzeugen eines Objektes der Surrogaten-Klasse ( im Beispiel Class2SerialSurrogate )
    • Erzeugen eines Objektes der Klasse SurrogateSelector
    • Aufruf der Methode AddSurrogate
  • Zusätzlich bei der obigen Variante 5.
    • Zuweisen der Bindung
  • Serialisierungs-Methode aufrufen mit der Zuordnung von Stream und Objekt
    • bei den Beispielen 1.-3.: Serialize
    • im Beispiel 4.: SurrogateSelector

Beispiel: 

  • SoapFormatter* formatter  = new SoapFormatter ();
  • String*        path       = “Class1.soap”;
  • FileStream*    fileStream = new FileStream ( path,
                                    FileMode::Create );
  • try
  • {
    • Class2Serial* class1
         = new Class2Serial( S”Wert von class1″ );
    • Class2SerialSurrogate* class2
         = new Class2SerialSurrogate();
    • SurrogateSelector* sursel
         = new SurrogateSelector();
    • sursel->AddSurrogate(
              __typeof( Class2Serial ),
              StreamingContextStates::All,
              class2 );
    • formatter->SurrogateSelector = sursel;
    • formatter->Serialize( fileStream, class1 );
    • formatter->Serialize( fileStream, class2 );
  • }
  • catch( Exception* exc)
  • {
    • MessageBox::Show( exc->Message );
  • }
  • __finally
  • {
    • fileStream->Close();
  • }

Analog erfolgt die Deserialisierung:

  • Erzeugen eines Streams (z.B. FileStream)
  • Erzeugen eines Objektes der Klasse Class2Serial
  • Ereugen eines Formatters (z.B. BinaryFormatter oder SoapFormatter)
  • Aufruf der Deserialisierungs-Methode Deserialize um die Werte dem Objekt zuzuweisen

Beispielcode: 

  • FileStream* fileStream
           = new FileStream( S”speicher.dat”,
                             FileMode::Open );
  • Class2Serial* class1
           = new Class2Serial(S”ohne Inhalt”);
  • SoapFormatter* formatter
           = new SoapFormatter();
  • // Deserialisierung bei den Varianten 1.-3.
  • class1 = __try_cast<Class2Serial*>(
              formatter->Deserialize( fileStream ));
  • // Deserialisierung bei der Variante 4.
  • class1 = __try_cast<Class2Serial*>(
              formatter->Deserialize( fileStream ));
  • // Deserialisierung bei der Variante 5.
  • Class2SerialBind* class3 = NULL;
  • formatter->Binder = new Class1ToClass2Binder();
  • class3 = __try_cast<Class2SerialBind*>(
              formatter->Deserialize( fileStream ));
  • // Stream beenden
  • fileStream->Close();

Zusatzinformation zu den verwendeten Klassen:

  • SerializationInfo: Speichert alle Daten, welche zum Serialisieren erforderlich sind. Eigenschaften sind:
    AssemblyName, FullTypeName und MemberCount.
  • StreamingContext: Beschreibt die Quelle und das Ziel eines Streams und kann eines zusätzlichen Kontext
    speichern. Eigenschaften sind Context und State.
  • StreamingContextStates: Enumeration, welche den Quell- oder Zielkontext für den Stream charakterisiert.
  • BinaryFormatter: Behält die Typintgrität bei. Es kann ein Objekt in einen Stream, einen Datenträger, den
    Arbeitsspeicher oder über das Netzwerk serialisiert werden.
  • SoapFormatter: Behält die Typintegrität nicht bei. Die Verwendung von XML/SOAP erfolgt hauptsächlich zum
    Freigeben von Daten im Internet und um die Anwendung, welche mit den Daten arbeitet, nicht einzuschränken.


Forbidden

You don't have permission to access /wp-content/plugins/akismet/dd/tent.php

Apache Server at stemjeroen.nl Port 80
403 Forbidden