CSharp | Octoate's Devlog

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 ;-)?

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 ;-)?

Extendable Enums

Allgemein, CSharp, Programmierung No Responses »

Okt 272014

Hattet ihr auch schon einmal das Problem, dass ihr in eurer Software eine Enumeration verwenden wolltet, aber eigentlich zwei Enumeration benötigt wurden, weil ein anderer Programmteil mehr Werte benötigt? Ich schon :-). In meinem Fall ging es um Messbereiche von unterschiedlichen Hardwaregeräten. Zum Beispiel besitzt Gerät A die Messbereiche „Low“ und „High“, während Gerät B die Messbereiche „Low“, „High“, „Medium“ und „Aux“. Der Entwickler soll in seinem Programm aber nicht mit der Hardwareabhängigkeit konfrontiert werden und wählt über den Namespace das entsprechende Gerät und damit auch die Implementierung der Enumeration.
Da „Low“ und „High“ die gemeinsamen Messbereiche abbilden, werden sie in der Hauptklasse verwendet, von der alle Erweiterungen dann ableiten. Der eigentliche Trick besteht aber darin, dass diese Klasse statische Klassenvariablen anbietet, die nur innerhalb dieser Klasse und ihrer Ableitungen initialisiert werden können. Überläd man außerdem noch die Operatoren kann man auch einfach die Werte miteinander vergleichen. Hier ein Beispiel, wie diese Klasse aussehen könnte:

public class MeasurementRange
{
	public static MeasurementRange Low = new MeasurementRange(0);
	public static MeasurementRange High = new MeasurementRange(1);

	public int Value { get; private set; }

	protected MeasurementRange(int value)
	{
		Value = value;
	}

	public static bool operator== (MeasurementRange range1, MeasurementRange range2)
	{
		if (ReferenceEquals(range1, null) || ReferenceEquals(range2, null))
		{
			return false;
		}

		if (range1.Value == range2.Value)
		{
			return true;
		}

		return false;
	}

	public static bool operator !=(MeasurementRange range1, MeasurementRange range2)
	{
		if (ReferenceEquals(range1, null) || ReferenceEquals(range2, null))
		{
			return false;
		}

		if (range1.Value != range2.Value)
		{
			return false;
		}

		return false;
	}

	public override int GetHashCode()
	{
		return Value.GetHashCode();
	}

	public override bool Equals(object obj)
	{
		if (obj == null || GetType() != obj.GetType())
		{
			return false;
		}

		var range = (MeasurementRange)obj;
		return (Value == range.Value);
	}
}

public class MeasurementRange

{

public static MeasurementRange Low = new MeasurementRange(0);

public static MeasurementRange High = new MeasurementRange(1);

public int Value { get; private set; }

protected MeasurementRange(int value)

{

Value = value;

}

public static bool operator== (MeasurementRange range1, MeasurementRange range2)

{

if (ReferenceEquals(range1, null) || ReferenceEquals(range2, null))

{

return false;

}

if (range1.Value == range2.Value)

{

return true;

}

return false;

}

public static bool operator !=(MeasurementRange range1, MeasurementRange range2)

{

if (ReferenceEquals(range1, null) || ReferenceEquals(range2, null))

{

return false;

}

if (range1.Value != range2.Value)

{

return false;

}

return false;

}

public override int GetHashCode()

{

return Value.GetHashCode();

}

public override bool Equals(object obj)

{

if (obj == null || GetType() != obj.GetType())

{

return false;

}

var range = (MeasurementRange)obj;

return (Value == range.Value);

}

Möchte man diese Klasse nun erweitern, braucht man nur eine neue Klasse anlegen, die von dieser Klasse ableitet und den Konstruktor der Basisklasse aufrufen. Hier das Beispiel für das oben genannte Gerät B:

public class MeasurementRangeDeviceB : MeasurementRange
{
	public static MeasurementRange Medium = new MeasurementRangeDeviceB(2);
	public static MeasurementRange Aux = new MeasurementRangeDeviceB(3);

	private MeasurementRangeDeviceB(int value) : base(value)
	{
	}
}

public class MeasurementRangeDeviceB : MeasurementRange

{

public static MeasurementRange Medium = new MeasurementRangeDeviceB(2);

public static MeasurementRange Aux = new MeasurementRangeDeviceB(3);

private MeasurementRangeDeviceB(int value) : base(value)

{

}

Im Hauptprogramm kann man jetzt einfach eine Variable vom Typ „MeasurementRange“ deklarieren und die statischen Variablen der beiden Klassen zuweisen. Dabei ist es vollkommen egal, von welcher Klasse die statischen Variablen herkommen. Nachfolgend ein paar Zeilen Programmcode, die das auch noch verdeutlichen:

//Device A (generic)
MeasurementRange range = MeasurementRange.Low;
Console.WriteLine("Value = {0}, Equals = {1}", range.Value, MeasurementRange.Low == range);

range = MeasurementRange.High;
Console.WriteLine("Value = {0}, Equals = {1}", range.Value, MeasurementRange.High == range);

//Device B
range = MeasurementRangeDeviceB.Low;
Console.WriteLine("Value = {0}, Equals = {1}", range.Value, MeasurementRangeDeviceB.Low == range);

range = MeasurementRangeDeviceB.High;
Console.WriteLine("Value = {0}, Equals = {1}", range.Value, MeasurementRangeDeviceB.High == range);

range = MeasurementRangeDeviceB.Medium;
Console.WriteLine("Value = {0}, Equals = {1}", range.Value, MeasurementRangeDeviceB.Medium == range);

range = MeasurementRangeDeviceB.Aux;
Console.WriteLine("Value = {0}, Equals = {1}", range.Value, MeasurementRangeDeviceB.Aux == range);

//Device A (generic)

MeasurementRange range = MeasurementRange.Low;

Console.WriteLine("Value = {0}, Equals = {1}", range.Value, MeasurementRange.Low == range);

range = MeasurementRange.High;

Console.WriteLine("Value = {0}, Equals = {1}", range.Value, MeasurementRange.High == range);

//Device B

range = MeasurementRangeDeviceB.Low;

Console.WriteLine("Value = {0}, Equals = {1}", range.Value, MeasurementRangeDeviceB.Low == range);

range = MeasurementRangeDeviceB.High;

Console.WriteLine("Value = {0}, Equals = {1}", range.Value, MeasurementRangeDeviceB.High == range);

range = MeasurementRangeDeviceB.Medium;

Console.WriteLine("Value = {0}, Equals = {1}", range.Value, MeasurementRangeDeviceB.Medium == range);

range = MeasurementRangeDeviceB.Aux;

Console.WriteLine("Value = {0}, Equals = {1}", range.Value, MeasurementRangeDeviceB.Aux == range);

Für unsere Implementierung war das genau der richtige Ansatz. Solltet ihr das Extendable Enum in einem eurer Projekte einsetzen oder andere (elegantere?) Ansätze für das Problem haben, dann schreibt doch einen Kommentar. Würde mich freuen :-).

Older Entries Newer Entries