Archiv der Kategorie ‘Programming‘

Cast<> und OfType<> Unterschied

Montag, den 3. November 2008

LINQ bietet extra für den Umgang mit nicht generischen Collections die beiden Extensionmethoden Cast<> und OfType<>. Mit denen ist es möglich den Inhalt einer nicht generischen Collection wie zum Beispiel ArrayList umzuwandeln. Nehmen wir folgendes Beispiel:

public class Person {   
   public string Surname  { get; set; }
   public string LastName { get; set; }
}
ArrayList list = new ArrayList {  
   { new Person { Surname = "Alfons", LastName = "TheFirst" },   
   { new Person { Surname = "Alfons", LastName = "TheSecond" }
};

Wie ihr sicherlich wisst bekommt man beim iterieren durch die ArrayList wie oben aufgezeigt immer eine Referenz auf ein System.Object. Mit den beiden LINQ Operatoren Cast<> und OfType<> kann man nun die Objektreferenzen in die konkrete Klasse Person “casten” und bekommt bei einem LINQ Query immer ein IEnumerable<Person> zurück. Dies würde folgendermassen aussehen:

// Query syntax
var persons = (from p in list.Cast<Person>()
               select p where p.LastName == "TheSecond");
// Method chaining
var persons = list.Cast<Person>().
                        Where(p => p.LastName == "TheSecond");

Doch was ist nun der Unterschied zwischen den beiden Operatoren? Der Unterschied ist eigentlich schnell erklärt. Der Cast<> Operator versucht jedes Element in der Collection zum entsprechenden Typen zu Casten. Ist der Cast nicht erfolgreich so wird eine Exception geworfen und die Ausführung des Queries beendet. Mit dem OfType<> Operator wird versucht das Element zu Casten und wenn es nicht erfolgreich ist, wird einfach das Element in der Collection ausgelassen.

Dies ist vor allem nützlich, da man bei nicht generischen Collections nicht garantieren kann, dass immer die gleichen Elemente in die Colllection abgefüllt werden. So wäre es durchaus zulässig, dass jemand in der obigen Arraylist noch

list.Add("Ätschbätsch");

hinzufügt. Nähme man dann den Cast<> Operator so wurde die Ausführung des Queries scheitern. Bei OfType<> würde das Element “Ätschbätsch” einfach nicht berücksichtigt.

Mit Vollgas Richtung .NET 4.0

Samstag, den 1. November 2008

Kaum wurde .NET 3.5 SP1 veröffentlicht sind schon die ersten Community Technical Prereleases des .NET 4.0 Frameworks erhältlich. Im Netz gibt es bereits ein cooles .NET Post mit den Klassen und Namespaces des .NET 4.0 Frameworks. Seht selbst:

http://brad_abrams.members.winisp.net/Projects/PDC2008/
DotNet4Poster/DotNetFramework4PosterDeepZoom.htm

Videos zu Visual Studio 2010

Samstag, den 18. Oktober 2008

Es tut mir leid, dass in letzter Zeit so wenig Beiträge auf meinem Blog veröffentlicht werden. Leider bin ich momentan im WK und habe am Wochenende fast keine Lust irgendwelche Beiträge zu schreiben. Aber diesen wollte ich euch nicht vorenthalten:

Unten findet ihr eine Liste von Videos die sich mit dem Thema Visual Studio Team System 2010 beschäftigen. Sehr interessant!

  1. Announcing Visual Studio Team System 2010
  2. Visual Studio Team System 2010 Week on Channel 9!
  3. Cameron Skinner: Visual Studio Team System 2010 – Architecture
  4. “Top-down” design with Visual Studio Team System 2010
  5. “Bottom-up” Design with Visual Studio Team System 2010 Architect
  6. ARCast.TV – Peter Provost on what’s coming for Architects in Visual Studio Team System
  7. Team Foundation Server 2010 Setup and Administration
  8. An early look at Team Foundation Build 2010 with Jim Lamb
  9. Enterprise Team Foundation Server Management with Mario Rodriguez
  10. Update on Team Foundation Server Migration and Synchronization
  11. Microsoft Visual Studio Team System Database Edition: Overview
  12. Improving .NET Application Performance and Scalability
  13. Microsoft Visual Studio Team S…er: How We Use It at Microsoft
  14. Team Foundation Server 2010 Setup and Administration
  15. Microsoft Visual Studio Team System: Software Diagnostics and Quality for Services
  16. Architecture without Big Design Up Front
  17. Microsoft Visual Studio Team System: Leveraging Virtualization to Improve Code Quality with Team Lab
  18. Branching and Merging Visualization with Team Foundation Server 2010
  19. Brian Harry: Team Foundation Server 2010
  20. Better Software Quality with Visual Studio Team System 2010
  21. Manual Testing with Visual Studio Team System 2010
  22. Historical Debugger and Test Impact Analysis in Visual Studio Team System 2010
  23. What’s new in Visual Studio Team System 2010: Feature: Historical Debugger

http://blogs.msdn.com/charles_sterling/archive/2008/10/13/visual-studio-2010-videos.aspx

Einfacher Weg für Methodensynchronisation

Sonntag, den 7. September 2008

Manchmal (sehr oft) kann es kompliziert werden Methoden zu synchronisieren. Sollten wir aber zu der Schlussfolgerung kommen, dass nur ein Thread eine Methode einer Klasse zu einem bestimmten Zeitpunkt ansprechen/ausführen darf. So gibt es eine einfache Möglichkeit die Methode zu synchronisieren.

Mit dem MethodImplAttribute aus dem System.Runtime.CompilerServices namespace kann man das Laufzeitverhalten der CLR beeinflussen. Das MethodImplAttribute akzeptiert einen Enumerator als Paramater mit dem Namen MethodImplOptions.

MethodImplOptions hat ein Feld mit dem Namen Synchronized. Dies teilt dem Compiler mit, dass nur ein Thread die Methode ausführen darf. Dies ist wie mit der Verwendung des Keywords lock, jedoch wir die ganze Methode gelockt.

public class Demo
{
[MethodImpl(MethodImplOptions.Synchronized)]
public void MethodToSyncronize()
{
}
}

Grosses ABER:

  • Dieses Attribute bringt den ausführenden Thread dazu das Lock zu behalten bis die Methode zurückkehrt. Kann das Lock früher gelöst werden, so sollte die Monitor Klasse oder das C# lock statement genutzt werden (besser lock statement!).
  • Das Locken von Instanzen oder Typen mit dem Synchronized flag ist nicht empfohlen für öffentliche (public) Typen. Dies weil ein anderer Code oder Caller könnte selber die Locks auf den Typen oder Instanzen einholen. Dies kann zu bösen Deadlocks führen.

.NET Cheatsheets

Samstag, den 16. August 2008

Beim Surfen im Netz bin ich über eine Seite mit Cheatsheets für .NET. Darunter findet man Cheatsheets für .NET Format String Quick Reference, Visual Studio 2005 Default Keybindings, Visual Studio 2008 Default Keybindings, Microsoft .NET Framework 3.5 Commonly Uses Types and Namespaces und viele mehr.

http://john-sheehan.com/blog/index.php/net-cheat-sheets/

Ist Dependency Injection tot?

Freitag, den 11. Juli 2008

Ich bin im Netz über einen wirklich sehr interessanten Artikel gestossen. Simon Ince diskutiert auf seinem Blog die Möglichkeit die Dependency Injection über AOP zu lösen und wirft dabei die Frage auf: "Ist Dependency Injection tot?".

http://blogs.msdn.com/simonince/archive/2008/06/30/dependency-injection-is-dead.aspx

Und dann ein Ansatz in diese Richtung mittels PostSharp4Unity.

http://www.postsharp.org/blog/2008/02/first-version-of-postsharp4unity.html

Viel Spass

Rapier-Loom.NET

Samstag, den 5. Juli 2008

Leider ist es schon wieder einige Zeit her, als ich mein letzter Blogeintrag geschrieben habe. Naja manchmal hat man einfach sonst viel zu viel zu tun ;)

Was ist Rapier-Loom.net

Bei RapierLoom.NET um einen dynamischen Weber für Aspektorientierte Programmierung unter .NET. Das bedeutet, dass Verwebungsentscheidungen erst zur Laufzeit (beim Instanziieren) getroffen werden können. Es ist also möglich, erst während der Programmausführung zu bestimmen, welche Aspekte eingewoben werden sollen, beziehungsweise ob überhaupt Aspekte eingewoben werden sollen. Realisiert wird dies alles durch das Factory- und das Proxy/Decorator-Konzept.

Bei der Instanziierung einer Zielklasse (Typ, in den Aspekte eingewoben werden sollen) werden die einzuwebenden Aspekte (bzw. „Aspektklassen“) also explizit angegeben. Als nächstes verwebt der Weber Ziel- und Aspektklassen an definierten Punkten und man erhält ein Objekt der Verwebungsklasse.

Funktionsweise

In den Aspektklassen befinden sich so genannte Aspektmethoden. Diese können mit bestimmten Methoden in der Zielklasse verwoben werden und definieren Verbindungspunkte, die angeben, an welchen Zielklassen, wo dort und wie sie mit der Zielklassenmethode verwoben werden. Zielklassen müssen dabei entweder virtuell sein oder in einem Interface deklariert sein. Dabei ist anzumerken, dass wegen des Proxy-Konzeptes nur Methoden verwoben werden können. Eigenschaften** werden beim Kompilieren jedoch in Methoden umgesetzt, sodass man auch auf Objektzugriffe Aspekte anwenden kann – sofern diese über Eigenschaften realisiert sind.

Ziel- und Aspektklassen müssen dabei nicht als Quelltext vorliegen. Es ist ebenso möglich, Typen aus bereits kompilierten Assemblies als Ziel- bzw. Aspektklasse zu benutzen. Somit ist man auch nicht an eine bestimmte Programmiersprache gebunden, man kann jede beliebige .NET-Sprache benutzen. Durch das Factory-Konzept und die Verwendung von Attributen zur Deklaration von Verwebungspunkten sind auch keine Spracherweiterung oder Benutzung eines speziellen Compilers nötig.

Tutorial

http://www.mycsharp.de/wbb2/thread.php?threadid=32405

Spass mit Emit

Mittwoch, den 18. Juni 2008

In diesem Artikel möchte ich euch kurz aufzeigen, was man mit System.Reflection.Emit unter C# machen kann. Dies ist bei weitem kein komplettes Tutorial sondern nur eine kleine Übersicht über die Möglichkeiten mit Emit.

Was wollen wir tun?

Ziel ist es eine Klasse Person zu generieren die das Interface IPerson und IComparable implementiert. Die Klasse soll folgendermassen aussehen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public interface IPerson {
     string Vorname { get; set; }
}
 
public class Person : IPerson, IComparable<IPerson> {
   private string vorName;
 
   public string Vorname {
      get { return vorName; }
      set { vorName = value; }
   }
 
   public int CompareTo(IPerson other) {
      return 1;
   }
}

Sicherlich macht es nicht viel Sinn in der CompareTo Methode immer 1 zurück zu geben. Ich habe es nur so gemacht, damit das Beispiel etwas einfacher zu verstehen ist. Da das Emiten von Functioncalls auf .NET Klassen etwas schwieriger ist.

Generieren eines dynamischen Assemblies

Das untenstehende Codesegment zeigt wie man ein dynamisches Assembly erzeugt. Dazu definiert man zuerst einen AssemblyName und setzt auf dem AssemblyName das Property Name und Version entsprechend den Anforderungen (Zeile 2, 4, 6). Als nächstes holt man sich den AssemblyBuilder über die bestehende ApplicationDomain des Mainthreads (Zeile 9; dann läuft das Assembly unter der gleichen ApplicationDomain). Über den AssemblyBuilder ruft man die Methode DefineDynamicModule aus und erhält somit einen ModuleBuilder der für das Builden eines Modules zuständig ist (Zeile 11; ein Assembly kann mehrere Module enthalten).

1
2
3
4
5
6
7
8
9
10
11
// Define the new AssemblyName
AssemblyName assName = new AssemblyName();
// Specify the assembly name (without .dll)
assName.Name = "MyEmitTest";
// Define the version
assName.Version = new Version(0, 0, 0, 1);
 
// Get the AssemblyBuilder for the current application domain
AssemblyBuilder assBuilder = Thread.GetDomain().DefineDynamicAssembly(assName, AssemblyBuilderAccess.RunAndSave);
// Get the ModuleBuilder over the AssemblyBuilder
ModuleBuilder modBuilder = assBuilder.DefineDynamicModule("MyFirstEmittedModule", "MyEmitTest.dll");

Definieren der Klasse Person

Um in dem bestehenden Module eine neue Klasse zu definieren, rufen wir die Methode DefineType des ModuleBuilders auf. Die Methode gibt ein TypeBuilder zurück, den wir brauchen um die Klasse zusammenzubauen. Damit die Klasse Person die Interfaces IPerson und IComparable kennt, muss über den TypeBuilder und die Methode AddInterfaceImplementation das entsprechende Interface dem Typ bekannt gemacht werden. Achtung dadurch implementiert der Typ Person die Methoden und Properties der Interfaces nicht automatisch, die muss auch von Hand erledigt werden (mehr dazu später).

1
2
3
4
5
6
// Define Person class which is public
TypeBuilder personBuilder = modBuilder.DefineType("Person", TypeAttributes.Public);
// Add IPerson interface
personBuilder.AddInterfaceImplementation(typeof(IPerson));
// Add interface IComparable<IPerson>
personBuilder.AddInterfaceImplementation(typeof(IComparable<>).MakeGenericType(typeof(IPerson)));

Definieren des Feldes vorName

Über den TypeBuilder personBuilder und die Methode DefineField kann ein neues Feld im Typ Person definiert werden. Dazu spezifiziert man den Namen des Feldes, den darunterliegenden Typ und den Fieldmodifier (private, protected, public) über das FieldAttribute. That’s the whole magic ;)

1
2
// Vorname Field
FieldBuilder vornameFieldBuilder = personBuilder.DefineField("vorName", typeof(string), FieldAttributes.Private);

Definieren des Properties Vorname

Für das Definieren des Properties Vorname ist etwas mehr Arbeit nötig. Dies hat mit dem internen Aufbau der Klassen zu tun. Definiert man nämlich ein Property Vorname in C# mit einem get und set Accessor, so wird automatisch vom Compiler jeweils eine Methode get_Vorname und set_Vorname ausprogrammiert und verknüpft. Deshalb muss man nach der Definition des eigentlichen Properties über den TypeBuilder personBuilder und die Methode DefineProperty noch die Methoden get_Vorname und set_Vorname emitten. Doch Eins nach dem Anderen.

Die Methode DefineProperty des TypeBuilder personBuilder definiert den Namen des Properties (hier “Vorname”) und den Typ des Properties (hier string).

1
PropertyBuilder vornamePropBuilder = personBuilder.DefineProperty("Vorname", PropertyAttributes.None, typeof(string), null);

Nach der obigen Codezeile ist das Property ohne Rumpf definiert. Würde man den Typ Person bereits jetzt versuchen zur Laufzeit zu generieren, würde eine Exception geworfen, dass das Property Vorname noch nicht vollständig implementiert sei. Als erstes beginnen wir mit dem implementieren der get_Vorname Methode. Dazu ruft man auf dem TypeBuilder personBuilder die Methode DefineMethod auf und definiert die Methodenattribute (werden ver-OR-t). Da es sich bei den Methoden get_PropertyName und set_PropertyName um spezielle Methoden handelt (sogenannte Specialnames) muss das MethodAttribute SpecialName gesetzt werden!

Als nächstes holt man sich über den MethodBuilder den ILGenerator und baut über diesen die Operationen der Methode zusammen. Da dies nicht ganz trivial ist, hier ein kleiner Trick:

Der .NET Reflector von Lutze Roeder erlaubt es DLLs die mit .NET erstellt wurden einzulesen und den darunterliegenden Code zu extrahieren. Der Reflector ist erweiterbar mit einem coolen Plugin ReflectorEmitLanguage. Dieses Plugin erlaubt es den IL Code anzusehen. So kann man sich Sampleklassen mit Visual Studio bauen, diese in einer DLL speichern und schlussendlich die erzeuge DLL mit dem Reflector anzusehen. So sieht man genau wie der IL Code mit dem ILGenerator gemacht werden müsste :D . Darum gehe ich jetzt nicht weiter auf den IL Code ein.

Zum Schluss muss man noch auf der Klasse mit DefineMethodOverride dem Emitter mitteilen, dass die neue Methode die Methode des Interfaces überschreibt. Sonst gibt es eine Warnung, dass die Klasse Person das Interface IPerson nicht implementiere.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
            // Define the 'get_Vorname' method.
MethodBuilder getVornameMethod = personBuilder.DefineMethod("get_Vorname",
MethodAttributes.Public | MethodAttributes.Virtual | MethodAttributes.HideBySig | MethodAttributes.SpecialName,
               typeof(string), null);
// Generate IL code for 'get_Vorname' method.
ILGenerator methodIL = getVornameMethod.GetILGenerator();
methodIL.Emit(OpCodes.Ldarg_0);
methodIL.Emit(OpCodes.Ldfld, vornameFieldBuilder);
methodIL.Emit(OpCodes.Ret);
// Define the Set Method
vornamePropBuilder.SetGetMethod(getVornameMethod);
// Get the interface implementation
MethodInfo interfaceGetVorname = typeof(IPerson).GetMethod("get_Vorname");
// Ovveride it
personBuilder.DefineMethodOverride(getVornameMethod, interfaceGetVorname);

Fast das gleiche Prinzip gilt für die Methode set_Vorname.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// Define the 'set_Vorname' method.
Type[] methodArgs = { typeof(string) };
MethodBuilder setVornameMethod = personBuilder.DefineMethod("set_Vorname",
               MethodAttributes.Public | MethodAttributes.Virtual | MethodAttributes.HideBySig | MethodAttributes.SpecialName,
               typeof(void), methodArgs);
// Generate IL code for 'set_Vorname' method.
methodIL = setVornameMethod.GetILGenerator();
methodIL.Emit(OpCodes.Ldarg_0);
methodIL.Emit(OpCodes.Ldarg_1);
methodIL.Emit(OpCodes.Stfld, vornameFieldBuilder);
methodIL.Emit(OpCodes.Ret);
vornamePropBuilder.SetSetMethod(setVornameMethod);
MethodInfo interfaceSetVorname = typeof(IPerson).GetMethod("set_Vorname");
personBuilder.DefineMethodOverride(setVornameMethod, interfaceSetVorname);

Definieren der Methode CompareTo

CompareTo definiert die Methode des Interfaces IComparable und hat darum einen IPerson Parameter other. Dies muss ebenfalls über den MethodBuilder erstellt werden und über DefineParameter wird die Position, das Parameterattribute und der Name des Parameters festgelegt. Schlussendlich geben wir hier im Beispielcode einfach als Returnparameter eine 1 zurück, die wir über den IL Generator auf den Stack geladen haben…

1
2
3
4
5
6
7
8
9
10
// Make compareTo Method with the Person param
Type[] compareToArgs = { typeof(IPerson) };
MethodBuilder compareToMethod = personBuilder.DefineMethod("CompareTo",
MethodAttributes.Public | MethodAttributes.Virtual, typeof(int), compareToArgs);
            compareToMethod.DefineParameter(1, ParameterAttributes.None, "other");
// Generate the IL code for the compareTo Method
methodIL = compareToMethod.GetILGenerator();
methodIL.Emit(OpCodes.Ldarg_0);
methodIL.Emit(OpCodes.Ldc_I4, 1); // Pushes the value 1 (int32) to the stack
methodIL.Emit(OpCodes.Ret);

Viel Spass

Links

MSDN System.Reflection.Emit
MSDN System.Reflection.Emit.AssemblyBuilder
MSDN System.Reflection.Emit.MethodBuilder
.NET Reflector
.NET Reflector Add-Ins

Parallel LINQ

Donnerstag, den 12. Juni 2008

Auf MSDN ist ein sehr interessanter Artikel über Parallel LINQ erschienen. Bei Parallel LINQ handelt es sich um eine API Erweiterung für LINQ mit dem es möglich ist, die Queries optimiert auf mehreren Prozessoren oder Cores auszuführen. Ich kann euch diesen Artikel nur wärmstens empfehlen. Gut sind auch die Punkte im Artikel wo die Autoren klar auf Probleme und Race Conditions eingehen und wie das Exceptionhandling bei mehreren Threads behandelt wird.

http://msdn.microsoft.com/en-us/magazine/cc163329.aspx

Es gibt dann auch Webcasts zum Downloaden:

http://www.microsoft.com/germany/msdn/webcasts/serien/MSDNWCS-0806-02.mspx

FXRuby

Freitag, den 6. Juni 2008

FXRuby ist eine Library um auf verschiedenen Plattformen mittels Ruby Applikationen mit einem grafischen Benutzerinterface zu erstellen. FXRuby basiert auf der populären opensource C++ Library FOX Toolkit.

Auf dieser Seite sieht ihr einige Möglichkeiten was man mit FXRuby alles erstellen kann:

http://www.fxruby.org/doc/examples.html

Dazu gibt es einen grossen Userguide online mit dem man direkt loslegen kann. Es muss einfach zuerst über GEMs FXRuby installiert werden!

http://www.fxruby.org/doc/book.html

Mehr zu FXRuby unter:

http://www.fxruby.org