octoate

Zugriff auf Internal Methoden / Variablen aus anderen Assemblies

Jan 232015

Beim Schreiben von Unittests bin ich mal wieder darüber gestolpert, dass jemand speziell für die Unittests Getter und Setter angelegt hat, da er auf die privaten Variablen der Klasse nicht zugreifen konnte. Im Prinzip hat er damit für seinen Unittest die internen Variablen dann über den Zugriffsmodifizierer public dann doch wieder sichtbar gemacht, wenn auch nur indirekt. Das ist so natürlich nicht gewollt, denn sonst hätte man gleich den Zugriff auf die internen Variablen erlauben können. Vielleicht noch kurz zur Erklärung: unsere Unittests sind immer in eigenständige Assemblies ausgelagert, sodass wir von Außen auf die zu testenden Klassen zugreifen müssen. Das macht auch Sinn, da die Unittests in dem Kompilat nicht enthalten sein sollen. Wie kann man das Problem also lösen?

Das .NET Framework bietet dafür das Attribut InternalsVisibleTo aus dem Namespace System.Runtime.CompilerServices an. Um nun die internal Methoden, Variablen und Properties freizugeben, wird das Attribut in die AssemblyInfo.cs des zu testenden Projekts eingefügt.

[assembly:InternalsVisibleTo("UnittestAssemblyName")]

1	[assembly:InternalsVisibleTo("UnittestAssemblyName")]

Danach kann man mit dem im InternalsVisibleTo-Attribut angegeben Assembly seine Unittests auf den Klassen durchführen ohne alles Zugriffsmodifizierer auf public zu setzen.

Solltet ihr eure Assemblies signieren, muss das einzufügende Attribut um den Public Key des zugreifenden Assemblies erweitert werden. Zusätzlich muss außerdem das zugreifende Assembly signiert werden. Der Eintrag in der AssemblyInfo.cs sieht dann so aus:

[assembly: InternalsVisibleTo("UnittestAssemblyName, PublicKey=002500000590000095" + 
                              "0000000703000000240000525351310005000" +
                              "002000100bf8c42fcd44838d89e245ab35bf7" +
                              "3bf2616707feea296709559b4de903fe95aa3" +
                              "3d3729977c3184aa7d7b84c7557cd87e435d5" +
                              "6bef8621bcb63b59c00c89bd83aa63c4fced4" +
                              "722da73eec2543dc00f9529c3a1bbb4103382" +
                              "f1d894d5f44e9f0203c474dce9f5b457a5dfe" +
                              "fd9f920d8682ed6dfce0a81e97bd9b176526a" +
                              "27e1b3")]

[assembly: InternalsVisibleTo("UnittestAssemblyName, PublicKey=002500000590000095" +

"0000000703000000240000525351310005000" +

"002000100bf8c42fcd44838d89e245ab35bf7" +

"3bf2616707feea296709559b4de903fe95aa3" +

"3d3729977c3184aa7d7b84c7557cd87e435d5" +

"6bef8621bcb63b59c00c89bd83aa63c4fced4" +

"722da73eec2543dc00f9529c3a1bbb4103382" +

"f1d894d5f44e9f0203c474dce9f5b457a5dfe" +

"fd9f920d8682ed6dfce0a81e97bd9b176526a" +

"27e1b3")]

Das ist natürlich nur eine Herangehensweise, aber – wie ich finde – eine doch recht elegante. Wie macht ihr das in euren Unittests? Habt ihr eine ähnliche Vorgehensweise oder schreibt ihr einfach gar keine ;-)?

Clean Code – ja, nein, vielleicht!?

Allgemein, Programmierung No Responses »

Dez 222014

Was soll man eigentlich viel über Clean Code schreiben? Es ist ja eigentlich offensichtlich, dass man im Sinne der Wartbarkeit, Einheitlichkeit und Verständlichkeit seinen Quellcode formatieren sollte. Dennoch wird es nicht auf Anhieb gelingen 100%ig sauberen Code zu entwickeln, aber dafür gibt es ja Tools wie bspw. StyleCop, die in den Buildprozess eingebunden werden und den geschriebenen Code analysieren und entsprechend Warnungen oder Fehlermeldungen ausgeben. Ich selbst habe mich bspw. beim Schreiben meines Codes immer an den Klassen des .NET Frameworks gehalten und auch versucht bei unseren Frameworks die angebotenen Methoden daran zu orientieren. Das fällt nicht immer leicht, ist aber notwendig, um den Anwender einen schnellen Einstieg zu ermöglichen. Selbst in privaten Projekten habe ich mittlerweile begonnen, mich an diverse Regeln zu halten, brav Unittests zu schreiben und StyleCop in den Buildprozess zu integrieren. Das kann zwar nervig sein, da man so nicht mal eben schnell ein kleines Tool entwickelt, das man gerade braucht, aber irgendwie habe ich mich daran gewöhnt so zu arbeiten und fühle mich dabei besser. Auf der anderen Seite habe ich mir dadurch aber auch schon einige Zeit gespart, die sonst bei der Fehlersuche verloren gegangen wäre.
Dennoch brandete bei einem Vortrag vor kurzem die Diskussion auf, ob Clean Code überhaupt notwendig sei. Schliesslich komme es nur auf Variablenbenennung und Methodennamen an, den Code kann man dann schon lesen. Tools wie StyleCop würden „Fingerpointing“ betreiben und die Entwickler an den Pranger stellen, wenn die Warnings oder Fehler im Buildprozess auftauchen. Man solle also den Entwicklern lieber ihre Freiheiten lassen.
Ich frage mich, ob es wirklich so ist, dass Entwickler nicht kritikfähig sind und es nicht vertragen, wenn man gewisse Vorgaben und Regeln bei der Implementierung einhalten soll. Das kann ich mir eigentlich gar nicht vorstellen. Sucht man selbst nicht permanent nach Möglichkeiten, den eigenen Code zu verbessern und effizienter zu arbeiten? Ich verstehe, dass man nicht auf einen Schlag den bisher geschriebenen Code Refaktorisieren und auch nur schwer argumentieren kann, dass bereits funktionierender Code noch einmal angepasst werden soll – er funktioniert ja und macht nachher letztendlich das Gleiche. Leider wird es bei dieser Argumentation von gewichtiger Stelle dann aber auch sehr schwierig, diese Methodik einzuführen.
Wie sieht es bei euch aus? Dürft ihr die Clean Code Prinzipien anwenden? Wie konntet ihr Clean Code einführen oder gab es auch Vorbehalte gegen Clean Code?

Fehlendes ExpectedException Attribut

CSharp, Programmierung No Responses »

Dez 082014

Bei der Entwicklung von Unittests für mein privates Windows Store und Windows Phone Projekt bin ich bei der Konvertierung der alten Unittests für die Portable Class Library (PCL), die in dem Projekt verwendet wird, darüber gestolpert, dass auf einmal das „ExpectedException“ Attribut nicht mehr gefunden wird. Dieses Attribut verwendete man in den Unittests, um Tests zu kennzeichnen, die eine Exception werfen müssen. So richtig sauber war das allerdings irgendwie noch nie, da man eigentlich die einzelnen Bedingungen mittels „Assert“ geprüft hat. Es ist also nur konsequent, dass das Attribut mittlerweile entfernt wurde und durch eine entsprechende Methode in der Assert-Klasse ersetzt wurde. Folgendes kleines Beispiel zeigt die Verwendung der Methode „ThrowsException“:

Assert.ThrowsException<InvalidResponseException>(()=>{
	//your exception code here
});

Assert.ThrowsException<InvalidResponseException>(()=>{

//your exception code here

});

Simpel, oder? Hat mich allerdings trotzdem etwas Zeit gekostet, da ich mit dieser Änderung erst mal nicht gerechnet habe.

Assemblies aus einem Verzeichnis automatisch nachladen

CSharp, Programmierung No Responses »

Nov 242014

Habt ihr schon einmal das Problem gehabt, dass ihr im laufenden Programm Assemblies eines anderen Programmes nachladen wollt? Evtl. eine API, die bereits vorher in einem anderen Verzeichnis installiert wurde? Es gibt dafür drei Möglichkeiten:

Kopieren der benötigten Assemblies in der Zielordner der Anwendung
Installation der Assemblies in den GAC (Global Assembly Cache)
Einbinden eines eigenen ResourceEventHandler, der die Assemblies aus einem entsprechenden Verzeichnis lädt

Hier soll es um die letzte Möglichkeit gehen. In der Klasse AppDomain kann man über das statische Property CurrentDomain die aktuelle Application Domain des laufenden Programmes abfragen. In diesem Objekt kann man dann einen ResolveEventHandler unter AssemblyResolve registrieren, der dann das Laden der Assemblies übernimmt. Hört sich kompliziert an, ist es aber letztendlich nicht. Nachfolgendes Beispiel zeigt, wie man einen ResolveEventHandler registriert und wie der EventHandler aufgebaut ist. Dabei wird beim Registrieren der Pfad aus der Registry ausgelesen:

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Reflection;
using System.Text;
using Microsoft.Win32;

namespace ResourceEventLoader
{
    public class ResourceLoader
    {
        public string Folder { get; private set; }

        public ResourceLoader()
        {
        }

        public void RegisterResourceEventHandler()
        {
            //retrieve folder from registry
            var folder = Registry.GetValue(@"REGISTRY_KEY_OF_YOUR_PATH", null, null);
            if (folder is string)
            {
                Folder = (string) folder;
            }

            AppDomain currentDomain = AppDomain.CurrentDomain;
            currentDomain.AssemblyResolve += MyResolveEventHandler;
        }

        public void DeregisterResourceEventHandler()
        {
            AppDomain currentDomain = AppDomain.CurrentDomain;
            currentDomain.AssemblyResolve -= MyResolveEventHandler;
        }

        private Assembly MyResolveEventHandler(object sender, ResolveEventArgs args)
        {
            string assemblyPath = Path.Combine(Folder, new AssemblyName(args.Name).Name + ".dll");
            if (File.Exists(assemblyPath) == false) return null;
            Assembly assembly = Assembly.LoadFrom(assemblyPath);
            return assembly;
        }
    }
}

using System;

using System.Collections.Generic;

using System.IO;

using System.Linq;

using System.Reflection;

using System.Text;

using Microsoft.Win32;

namespace ResourceEventLoader

{

public class ResourceLoader

{

public string Folder { get; private set; }

public ResourceLoader()

{

}

public void RegisterResourceEventHandler()

{

//retrieve folder from registry

var folder = Registry.GetValue(@"REGISTRY_KEY_OF_YOUR_PATH", null, null);

if (folder is string)

{

Folder = (string) folder;

}

AppDomain currentDomain = AppDomain.CurrentDomain;

currentDomain.AssemblyResolve += MyResolveEventHandler;

}

public void DeregisterResourceEventHandler()

{

AppDomain currentDomain = AppDomain.CurrentDomain;

currentDomain.AssemblyResolve -= MyResolveEventHandler;

}

private Assembly MyResolveEventHandler(object sender, ResolveEventArgs args)

{

string assemblyPath = Path.Combine(Folder, new AssemblyName(args.Name).Name + ".dll");

if (File.Exists(assemblyPath) == false) return null;

Assembly assembly = Assembly.LoadFrom(assemblyPath);

return assembly;

}

Microsofts .NET wird Open Source

CSharp, Programmierung No Responses »

Nov 132014

Ja! Richtig gelesen: Microsoft hat sich dazu entschlossen das.NET zukuünftig als Open Source Software zur Verfügung zu stellen und das nicht unter irgendeiner dubiosen Lizenz, sondern unter der sehr freizügigen MIT-Lizenz. Der Quellcode wird außerdem auf GitHub verwaltet und Pull-Requests werden auch ermöglicht. Jeder kann also in Zukunft am .NET Kern mitarbeiten. Dieser Schritt hat sich bereits schon länger abgezeichnet. Man hat die .NET Foundation gegründet, die sich in Zukunft mit der Weiterentwicklung von .NET befassen wird, die neue Compiler Plattform „Roslyn“ wurde direkt als Open Source freigegeben, F# ist Open Source und der Sourcecode des .NET Frameworks ist unter http://referencesource.microsoft.com auch schon länger einsehbar.
Neben der Open Source Strategie sieht man, dass .NET auf immer mehr Plattformen läuft. Dank Xamarins Mono ist .NET nämlich fast überall zu Hause – sei es iOS, Android, Linux, Mac OS X, den Raspberry Pi, die Nintendo Wii, die Playstation, die Xbox sowieso – um nur mal einige zu nennen. Mittlerweile wird auch der Cross-Platform Ansatz auch innerhalb Visual Studio immer besser unterstützt, d.h. die Entwicklung für Android, iOS, Windows Phone und Desktop Apps wird immer einfacher.
Für mich steht seit einiger Zeit schon fest, dass .NET irgendwie zum neuen Java geworden ist. Zwar gilt der alte Leitspruch von Java ,“Write once, run everywhere“, nicht in .NET, da man immer noch plattformabhängige Teile implementieren muss, aber man kann große Teile der Business Logik bereits auslagern und muss nur noch wenig neu implementieren und, was meiner Meinung nach viel wichtiger ist, warten. Die Sprache ist immer noch lebendig, d.h. sie wird fortwährend weiterentwickelt und hat sich dadurch bereits einen Vorsprung gegenüber dem langsamen Java Community Process erarbeiten können (man denke mal an die lange Hängepartie mit den Lambda-Ausdrücken :-/).
Ich freue mich jedenfalls über die neue Offenheit von Microsoft und bin gespannt, wie es weiter geht. Vielleicht wird es ja irgendwann mal ein Open Source Windows geben ;-)?

Older Entries Newer Entries