Singletons und ihre Nebeneffekte

Singletons sind leider ein heutzutage viel zu viel genutzter Weg, um einfach überall an die Instanz einer Klasse heranzukommen. Bei der Suche in diversen Suchmaschinen für C#-Implementierungen dieser Konstrukte findet man oft ähnliche Umsetzungen wie diese hier:

public sealed class SomeSingleton
{
    private static SomeSingleton _instance; 

    private SomeSingleton()
    { }

    public static SomeSingleton GetInstance()
    {
        if (_instance == null) 
            _instance = new SomeSingleton();

        return _instance;
    } 
}

Sieht zwar erstmal nicht sonderlich böse aus, aber es gibt da so einige Punkte, in dem diese alles andere als freundlich zum Entwickler sind. Was ist nun, wenn in Zukunft mehr als nur eine Instanz dieser Klasse nötig ist? Wie soll das sauber getestet werden, wenn die Reihenfolge von Tests nicht vorherbestimmt werden kann? Ist es immer Transparent wo diese Klasse verwendet werden kann?  Weiterlesen

Tools und Programme

Wie auch bereits auf dem xp-development Blog von Jan Schubert möchte ich an dieser Stelle einmal einige – aus meiner Sicht – sinnvollen Tools, Programme und andere Dinge erläutern. Den Beitrag vom xp-development Blog findet Ihr hier: xp-development – Die kleinen und großen Helferlein.

Entwicklungsprogramme: 
Visual Studio 2012, 2010 sowie 2008 für die C#, C++, VB, WPF, ASP Entwicklung
Mono für Cross-Platform .NET
UltraEdit und Notepad++ für andere Texte, sowie PHP JS Entwicklung etc.

Plugins:
ReSharper 7.1+ für refactoring und allgemeine Hilfe
NCrunch, NUnit, TypeMock und TestDriven.NET für UnitTests
NuGET für die Paket- und Referenzverwaltung
.NET Demon für automatisierte Rebuilds
VisualSVN, VisualHg für Zugriff auf SVN / Mercurial aus dem Studio

Tools: 
LinqPAD für schnelle Tests und „C#-Scripte“
ILSpy und Reflector zum disassemblen
NDepend für Code Analysen
dotTrace und Ants Profiler für Benchmarks sowie Leistungstests
Araxis Merge für das Mergen und Vergleichen von Texten
CCTray zum Überwachen des Buildservers
TortoiseHg, TortoiseSVN und TortoiseGit für Sourcecodeverwaltungsnutzung

Librarys: 
log4net für das Logging in .NET Projekten
Spring für die Objektinizialisierung durch XML
Knockout für die Nutzung von sehr guten Erweiterungen unter ASP.NET
SignalR für die Asynchronen Themen im ASP Bereich

Anderes: 
MSDN als Hilfe für alle .NET Themen
mycsharp.de als C# Community und Forum
spieleprogrammierer.de für die Programmierung im Bereich der Videospiele
Redmine als Projektverwaltungs-Oberfläche
MercurialSVN und Git (meist Mercurial) als Sourcecodeverwaltung
CruiseControl.NET als Buildserver

Ich denke damit sollte der Großteil abgedeckt sein. Zusätzlich werden natürlich auch Sachen wie Microsoft SQL Server 2008 R2, MySQL, MongoDB, NuSOAP, usw. verwendet, allerdings sind diese nicht ständig im Einsatz und daher nicht in der obigen Liste aufgeführt. Neben den ganzen Programmen sollten natürlich auch die Lizenzen, sowie ein ausreichend starker PC vorhanden sein. Aus privaten Erfahrungen heraus kann ich auch das Entwickeln über 3 WQHD Monitore empfehlen, da dies doch um einiges angenehmer ist. Außerdem würde ich Windows 8+ zum Entwickeln empfehlen, da andernfalls nicht alle Funktionen vom VS2012 genutzt werden können.

Ein eigener Datentyp (Teil 2)

Im letzten Teil (siehe: Ein eigener Datentyp (Teil1)) haben wir uns mit dem Grundgerüst unseres Datentypen zufrieden gegeben. Diesmal sollen die Operatoren implementiert werden. Der wohl wichtigste Operator hierfür dürfte der „implicit“-Operator oder auch Zuweisungsoperator sein. Auch hier werden wir wieder zwischen einem normalen Integer-Wert und einem Byte-Array unterscheiden und zwei Implementierungen vornehmen. Trotz der enormen Wichtigkeit dieses Operators ist dieser dennoch sehr simpel zu implementieren.

public static implicit operator Int24(int value)
{
    return new Int24(value);
}

public static implicit operator Int24(byte[] value)
{
    return new Int24(value);
}

Wie im Sourcecode zu sehen wird nur eine neue Instanz eines 24-Bit Integers erzeugt und zurück gegeben. Da wir bereits die nötigen Konstruktoren implementiert haben, haben wir keinen Aufwand mehr mit dieser Methode.  Weiterlesen

Dynamisches Mappen zwischen Typen

Manchmal kommt es vor, dass ein anderer Typ als der gegebene notwendig ist und das, obwohl dieser die gleichen Eigenschaften besitzt. Und mit diesem Satz möchte ich den nächsten Beitrag einleiten, denn diesmal geht es darum Typen zu Mappen. Dies kann erforderlich sein, wenn von einem SOAP-Service Datentypen vorgegeben werden, diese aber in eigene verpackt werden müssen, um diese mit speziellen Eigenschaften zu versehen und anschließend in der Oberfläche, im ViewModel oder im Model verwenden zu können. Im Prinzip bietet C# seit Version 2.0 dafür schon etwas passendes an, nämlich die generics. Aber um den Blogbeitrag sinnvoller zu gestalten, benötigen wir noch etwas – ein eigenes Attribut. Beginnen wir also mit diesem.

[AttributeUsage(AttributeTargets.Property, AllowMultiple = true)]
public class IgnoreOnMapAttribute : Attribute 
{ }

Relativ simpel gehalten, soll uns dieses Attribut lediglich die Möglichkeit schaffen bestimmte Eigenschaften beim Mapping zu überspringen. Es muss lediglich existieren.  Weiterlesen

Ein eigener Datentyp (Teil 1)

Ein eigener Datentyp kann dann sinnvoll sein, wenn es Voraussetzung ist, Daten in ein Gerät zu schreiben bei denen der Speicherplatz begrenzt ist oder wenn es notwendig ist einen Typen mit einer ganz speziellen Interaktion zu besitzen. Aber wie kann man einen eigenen Datentyp mit sämtlichen Funktionalitäten wie z.B. die eines Integers erzeugen? Nun eigentlich ist das gar nicht so schwer wie man vielleicht denkt, denn .NET bietet dafür bereits einige Schnittstellen an und der andere Teil sind überwiegend die korrekten Operator-Überladungen. In Rahmen dieser Mini-Serie möchte ich einen eigenen 24-Bit großen Integer erstellen, wie man ihn z.B. bei einigen Feldgeräten benötigt. Am Ende des letzten Teils werde ich anschließend den Quellcode sowohl für die Signed, als auch für die Unsigned Variante dieses Typen anhängen. Aber beginnen wir nun mit den Int24-Typen.

Zunächst einmal muss klar sein, was der Unterschied zwischen einer Struktur und einer Klasse ist,  dies wird hier allerdings vorausgesetzt. Und das ist auch eigentlich schon alles was notwendig ist, um den Typen zu erstellen. Wir werden ebenfalls die selben Attribute sowie Interfaces wie ein Int32 verwenden, um die Kompatibilität zu maximieren.  Weiterlesen

Simpler SplashScreen in WPF/C#

Um unter WPF/C# einen simplen SplashScreen anzuzeigen, benötigt es keinerlei Zusätze, außer einer Grafik die angezeigt werden soll. Es ist nicht einmal erforderlich ein eigenes Fenster zu erstellen – insofern keine komplexen Sachen wie Fortschrittsanzeige etc. gewünscht sind (hierfür kann folgendes verwendet werden: http://www.codeproject.com/Articles/38291/Implement-Splash-Screen-with-WPF). Für eine einfache Anzeige hingegen benötigt es nur eine Referenz auf den „System.Windows“ Namespace und schon kann in der „OnStartup“-Methode der App.xaml.cs ein SplashScreen angezeigt werden.

SplashScreen splash = new SplashScreen("SplashScreenImagePath.Type");
splash.Show(true);

Dies genügt bereits, um den SplashScreen anzeigen zu können. Das „true“ in der „Show“-Methode sorgt hierbei für ein Auto-Close, sobald das Hauptfenster angezeigt wird, andernfalls kann mittels „Close“-Methode das schließen ausgelöst werden.

WPF Lokalisierung

Eine häufige Anforderung im Berufsalltag ist es eine Anwendung in mehreren Sprachen anzufertigen. Während C# / VB hierfür sehr simpel auf RESX-Dateien zugreifen kann, ist vielen nicht klar, dass WPF dies ebenfalls beherrscht. Wie das ganze in C# funktioniert, kann älteren Blog-Beiträgen zur SmallMVVM-Reihe entnommen werden, da dies dort bereits Anwendung gefunden hat. Die RESX-Dateien werden hierfür genauso angelegt wie bereits unter C#, d.h. „Resources.de-DE.resx“ für z.B. Deutsch und „Resources.resx“ für die Standardwerte. Sollte der Eintrag in der speziellen Sprache nicht vorhanden sein, wird standardmäßig der aus der normalen Ressource verwendet, also aus der Standard-Datei.

Um das ganze nun in WPF nutzen zu können, muss zunächst ein „xmlns“, ein WPF-Using, angelegt werden. Dieser sieht wie folgt aus:

xmlns:resx="clr-namespace:<DefaultNamespaceOfProject>.Properties"

Anschließend können die Controls ein normales Binding auf Werten aus der genannten Resourcedatei durchführen. Hier sollte beachtet werden, dass dies nur String-Texte sind – Lokalisierungen eben. Das Ganze ist nicht für Einstellungen zu verwenden, dafür gibt es eigene Mechanismen.

<Label Content="{x:Static resx:Resources.<NameOfYourResource>}" />

Auf Administratorrechte prüfen

Hin und wieder ist es erforderlich, dass eine Anwendung oder Teile einer Anwendung mit Administratorrechten ausgeführt werden. Hierfür gibt es in .NET die Möglichkeit eine Überprüfung auszuführen und ggf. die Anwendung mit entsprechenden Rechten neuzustarten. Fälschlicherweise wird bei diesen Methoden oft angenommen, dass hiermit die Administratorrechte des Benutzers geprüft werden, dem ist aber nicht so – wozu auch. Es werden die Rechte geprüft mit welcher die Anwendung derzeit ausgeführt wird, nicht mehr und nicht weniger. Und natürlich kann man das so genannte UAC-Token (User Account Control) welches Windows zum Rechte setzen verwendet auch beim Start der Anwendung anfordern.

Aber zunächst einmal der einfache Teil; das Auslesen der aktuellen Rechte welche die Anwendung besitzt. Hierfür können wir uns eine Methode schreiben, welche sich lediglich dem „System.Security.Princial“-Namespace bedienen muss. Diese Methode würde wie folgt aussehen:

static bool RunAsAdmin()
{
    WindowsIdentity identity = WindowsIdentity.GetCurrent();
    if (identity != null)
    {
        WindowsPrincipal principal = new WindowsPrincipal(identity); 
        return principal.IsInRole(WindowsBuiltInRole.Administrator);
    }

    return false;
}

Nun da wir die Möglichkeit haben zu bestimmen ob wir die ausreichenden Rechte haben, wäre es hilfreich ggf. die Anwendung mit Administratorrechten erneut ausführen zu können. Weiterlesen

Async und Await in .NET 4.0

Vielen dürften inzwischen die geliebten Schlüsselwörter „async“ und „await“ ein Begriff sein. Diese haben die asynchrone Programmierung unter .NET sehr stark vereinfacht sind jedoch leider erst im neusten Framework standardmäßig verfügbar – dem .NET 4.5. Seit Mitte April gibt es aber hierfür nun eine Abhilfe, welche es immerhin ermöglicht diese Funktionalität unter .NET 4.0 bereits zu verwenden. Denn das größte Problem des .NET 4.5 ist, die nicht vorhandene Kompatibilität zu dem immer noch stark verbreitetem Windows XP.

Wie das Ganze zu nutzen ist, kann eigentlich der NuGET Galerie entnommen werden. Denn nach der Installation funktioniert dies wie bereits unter .NET 4.5. Der Link zum entsprechenden NuGET Galerie Eintrag ist am Ende des Posts zu finden. Es ist jedoch eigentlich nichts weiter nötig als das Package „Microsoft.Bcl.Async“ zu installieren, welches über die NuGET Paketverwaltung oder über die Paket-Manager-Konsole mit folgendem Befehl erfolgt:

Install-Package Microsoft.Bcl.Async

Weiterlesen

Zeichenketten Verschlüsselt im Arbeitsspeicher

Wer sieht schon gerne seine Daten als Klartext im Speicher, so dass diese von jedem Programm genutzt werden können? Seit .NET 2.0 gibt es für Zeichenketten eine Abhilfe, denn die Klasse „SecureString“ sorgt genau dafür, dass die Daten mithilfe der DPAPI (Data Protection API) verschlüsselt im Speicher laden. Diese API sorgt dafür, dass die Daten erst beim erneuten Zugriff durch das ablegende Programm entschlüsselt werden. Um dies zu erzielen, kann eine einfache Methode implementiert werden, welche aus einem String ein SecureString Object erzeugt.

Zunächst einmal benötigen wir zwei Using-Directives, um die nötigen Methoden zur Verfügung gestellt zu bekommen. Diese wären Folgende:

using System.Security; 
using System.Runtime.InteropServices;

Anschließend können wir nun die Methode implementieren. Bevor wir dies jedoch tun, sollten wir in unserem Projekt die Verwendung von unsicherem Code zulassen, dies geschieht über die Projekteigenschaften. Weiterlesen