.NET Coding

using System.Security.Principal

Dirk Eisenberg — Sat, 20 Dec 2008 04:42:51 GMT

Mit .NET 2.0 wurde der namespace System.Security.Principal um ein paar Klassen zur Verwaltung von Accounts erweitert. Hierbei handelt es sich um die gute alte Abstraktion von LookupAccountSid und LookupAccountName. Diese Funktionen finden sich in den neuen Klassen NTAccount und SecurityIndentifier wieder. Beide Klassen basieren auf einer Basis-Klasse mit dem Namen IdentityReference. Folgendes Beispiel zeigt wie man aus einem User-Account die entsprechende SID erzeugt. Diese Vorgang ist natürlich auch umgedreht möglich:

NTAccount user = new NTAccount("Administrator");
SecurityIdentifie sid = null;
if ( user.IsValidTargetType(typeof(SecurityIdentifier)))
sid = (SecurityIdentifier)user.Translate(typeof(SecurityIdentifier));

.NET Unmanaged API - Teil 1

Dirk Eisenberg — Mon, 08 May 2006 03:28:00 GMT

puh, schon wieder sind einige Wochen vergangen und ich habe nix zu diesem Blog beigetragen. Diese Woche hatte ich dann ein Erlebnis was mich zum Bloggen nötigt. Wie der Titel schon verrät, soll es um einen Teil des .NET Frameworks gehen, der nicht unbedingt gut dokumentiert ist und den Name "Unmanaged API" trägt. Die Unmanaged .NET Api stellt ein Set von COM-Interfaces zur Verfügung um auf die Meta-Daten eines .NET-Assemblies aus native Code heraus zuzugreifen. Eine Populärer Anwendung dieser API ist Visual Studio 2005 selbst. Viele Funktionen die sich sonst in System.Reflection befinden, sind ebenfalls über diese Schnittstelle erreichbar. Schauen wir uns ein Beispiel an, das prüft ob die gegebene Datei ein gültiges .NET Assembly ist:

HRESULT hr = CoCreateInstance(	CLSID_CorMetaDataDispenser, 0, CLSCTX_INPROC_SERVER, IID_IMetaDataDispenser, 						(LPVOID*)&pIMetaDataDispenser);
if (SUCCEEDED(hr))
{
 mdAssembly asmToken;
 hr = pIMetaDataDispenser->OpenScope(	L"MyAssemblyImage", ofRead, IID_IMetaDataAssemblyImport, (LPUNKNOWN*)&pIMetaDataAssemblyImport); 
 hr = pIMetaDataAssemblyImport->GetAssemblyFromScope(&asmToken);
 
 bool bIsAssembly = false;
 if (SUCCEEDED(hr))
  bIsAssembly = true;  
}

Eigentlich spricht der Code für sich, zuerst benötigen wir eine Instanz des MetaDataDispenser wodurch wir Zugriff auf alle Metadaten-Tabellen erhalten. Jetzt ist es möglich auf die verschiedenen Bereiche zuzugreifen. In diesem Beispiel auf die Meta-Daten in denen die Referenzen auf andere Assemblies zu finden sind. Um zu erkennen ob es ein gültiges Assembly ist, wird der Seiteneffekt genutzt das jedes Assembly diese Tabelle besitzt und das Öffnen dieses Scopes nur bei native-Binaries nicht funktioniert. Randbemerkung: Die Unmanaged API steht nur auf Computern zur Verfügung auf denen auch ein .NET-Framework installiert ist. Viele der unterstützten Funktionen werden ab .NET 1.0 unterstützt. Die benötigte include Datei "cor.h" findet sich in den Headern des .NET-Frameworks und muss eingebunden werden. Dabei wird indirekt die Datei specstrings.h angezogen. Diese steht erst in einem der letzten SDKs zur Verfügung (ich nutze das Windows 2003 Server SP1 SDK).

[Update] Der managed P/Invoke Mediator

Dirk Eisenberg — Mon, 06 Mar 2006 02:21:00 GMT

Wenn sich nach dem letzten Artikel vielleicht jemand fragt warum funktioniert das, sollte einen kurzen Blick auf die verschiedenen Bestandteile von Platform Invoke werfen. Daraus wird deutlich warum in einem Assembly DllImport-Verweise auf nicht existierende Dll vorhanden sein können und wann das .NET-Framework wie auf die native DLL zugreift.

Check this out: http://msdn2.microsoft.com/en-us/library/h50dxzwx.aspx

There are three parts to a .NET Compact Framework platform invoke:

At design-time, the developer provides a description of the unmanaged function to call. This includes the module name (DLL file), entry point name, and calling convention.
At just-in-time (JIT) compile time, the common language runtime extracts this information from the metadata, locates the DLL containing the function, loads the DLL into memory and retrieves the address of the function. If the module or function is not found, the common language runtime throw a MissingMethodException.
At run time, the common language runtime marshals the parameters from managed format to unmanaged format before the unmanaged function is called. The common language runtime
determines how to marshal each parameter based upon the managed declaration of the method.

Weiterhin sie auf das HowTo - Get the Device Platform verwiesen. Dadurch lässt sich der Platform Runtime Check auf sichere Beine stellen.

Der managed P/Invoke Mediator

Dirk Eisenberg — Mon, 06 Mar 2006 01:06:00 GMT

Nach dem letzten Blog meines gleichgesinnten Kollegens hat mich das Thema P/Invoke nicht mehr los gelassen. Ich ging nur mit einer etwas anderen Einstellung in das Thema. Mein Programmche soll nicht die File Redirection von %systemroot%\system32 nutzen. Nein ich will keine Forwarder-Library in das System32-Directory kopieren. Zustimmung erhält aber trotzdem das Mediator.Prinzip. Dieser Mediator bestimmt welche native DLL geladen wird. Im Fall von 64Bit Windows wäre das die 64Bit-Dll, im Fall von 32Bit Windows die 32Bit-Dll und im Falle von Windows CE und dem Compact Framework eine andere.

Mein Ziel ist aber die gesamte Distribution meiner Software in %ProgramFiles%\MySoftware zu handeln und eine foo.dll für 32Bit Windows, eine foo64.dll für 64Bit Windows und eine fooCe.dll für Windows CE zu halten.

Versuch Nummer 1:

Bendenkt man das Attribute in .NET nur Klasse abgeleitet von System.Attribute sind, liegt die Idee nah das DllImportAttribute erneut abzuleiten und im Property-Handling für den DllName die Logik für die Namens-Nomenklatur zu Implementieren. Leider macht das kleine aber wichtige Schlüsselwort sealed einen Strich duch die Rechnung. Damit sorgt das .NET Framework das keine weitere Ableitung von dieser Klasse möglich ist. Der nächste Versuch war irgendeine Art Logik hinter den DllName zu hängen. Leider unterstützt auch hier das .NET Framework nur konstante Parameter-Werte in Attributen. Also auf zu neuen Ufern.

Versuch Nummer 2:

Verfolgt man das Mediator-Konzept weiter, will aber keine eigene Forwarder-Dll schreiben, ist vielleicht folgendes Konzept hilfreich. Für jede unterstützte Plattform wird eine DllImportHelper-Klasse implementiert. Diese kapselt lediglich das Marshaling und die DllImport-Anweisung. Um den Zugriff auf die richtige Helper-Klasse zu realisierien wird eine Schnittstelle zur Verfügung gestellt. DieseDllImport-Klasse orchestriert den Zugriff auf die korrekte Helper-Klasse. Je nach aktueller Plattform wird die entsprechende Methode aus der korrekter DllImport-Helper-Klasse aufgerufen.

Vorteile:

Das Mediator-Konzept wurde beibehalten und das Assembly kann einfach um weitere Plattformen erweitert werden. Baut man das Konzept aus, so ist eine Erweiterung für neue Platformen in reinem Managed-Code ohne Veränderung des aufrufenden Codes möglich.
Die Verwaltung einer extra Forwarder-Dll entfällt.
Die Applikation muss keine Libraries in %systemroot%\system32 ablegen.

Nachteil:

Die Bestimmung der aktuellen Platform kostet extra Zeit und verlangsamt den Sprung in den native Code nochmals.
Es muss für jede Platform eine extra Klasse im Assembly gehalten werden aber kein zweites Assembly.

Ein einfaches Beispiel ist hier hinterlegt. Dieses Beispiel soll nur illustrieren wie das prinzipielle Vorgehen ist und wurde nicht für den produktiven Einsatz vorgesehen.

64Bit Runtime Check:

Wie findet der geneigte Entwickler in C# heraus ob sich der Prozess gerade als 64Bit bzw. 32Bit-Prozess läuft. Leider ist festzustellen das Microsoft in seinem Environment-Objekt keine passable Lösung für das Problem vorrätig hat. Folgende Lösung stammt aus diesem Blog und hier findet man wie es nicht gemacht werden sollte. Unter C# ist ein int-Datentyp immer 32Bit lang, egal ob 64Bit-Prozess der 32Bit-Prozess aber der IntPtr ist je nach Prozess-Art 32Bit oder 64Bit lang.

bool bIs64Bit = (sizeof(IntPtr) == 8 )

Ein neues Buch für mich

Dirk Eisenberg — Sun, 04 Dec 2005 18:03:00 GMT

Als ich diese Woche wiedermal an meinem Schreibtisch vorbei gekommen bin (natürlich hatte ich meine Tasse dabei) fand sich überraschend dieses Buch:

Jetzt beginne ich ganz begeistert in die Tiefen der IL einzusteigen und werde an dieser Stelle ab und an davon berichten. Das ist wohl die einzige Art für mich mit .NET richtig warm zu werden ;-)

Interior Pointer und GCHandles

Dirk Eisenberg — Sat, 12 Nov 2005 02:26:00 GMT

Wow, jetzt ist schon wieder ein ganzer Monat vergangen, ohne das ich einen Blog-Beitrag fertig bekommen habe. Ich schiebe das mal auf den Umstand das der Tag nur 24 Stunden hat und besser 48 haben sollte. Aber nun zum Thema dieses Beitrags.

Mich quälte in letzter Zeit eine Frage: Kann ich aus native C++ Code in ein Managed Assembly springen und wenn ja wie überlistet man den Garbage Collector damit man nicht mit üngültigen Pointer nach dem nächsten Cycle dasteht. Betrachten wir folgendes typische Pattern einer beliebigen Runtime wie so auch unter Windows selbst vorkommt. Um am geselligen Leben dieser Runtime teilhaben zu dürfen, wird uns die Implementierung einer DLL mit folgenden Einsprungspunkten vorgegeben (und das auch noch mit __stdcall):

Init( LPVOID* lpUserDefinedData );
Event1( LPVOID lpUserDefinedData );
Event2( LPVOID lpUserDefinedData );
UnInit( LPVOID lpUserDefinedData );

Wir haben also 4 Funktionen als Interface, eine Init, eine UnInit und zwei Aktionen. Der Entwickler der Runtime hat uns die Möglichkeit gegeben benutzerspezifische Daten durchzuschleifen um keine globalen Objekte in unserem Modul halten zu müssen, super. Jetzt stellen sich zwei Fragen:

Ist es möglich das gesamte Modul in .NET zu implementieren ohne die Runtime selbst zu verändern?
Wie schafft man es eine Referenz auf eine .NET-Klasse über den UserData-Parameter durchzuschleifen ohne das der GC bei der Heap-Reorganisation den Pointer zerstört ?

Frage 1 beantwortet sich recht einfach, .NET bietet die Möglichkeit native Funktions-Exporte zu erzeugen. Dadurch wird ein Eintrag in der EAT des PE-Files erzeugt, der direkt in den .NET-Code springt (Das ist mal einen eigene Beitrag wert). Hier ist es nun möglich mit gemanagten Objekten zu arbeiten. Etwas versteckt findet sich auch die Möglichkeit Exporte zusätzlich über ein Def-File zu steuern und nicht über die __cdeclspec(dllexport)-Anweisung.

Wie könnten jetzt also die Implementierung unsere Funktionen aussehen:

unsigned int __stdcall Init( void** lpUserData )
{
return 0;
};

Damit können wir uns der zweiten Fragen widmen: "Wie bekomme ich jetzt eine Referenz auf ein .NET-Objekt durchgeschleift?" Den ersten Gedanken verschwenden wir an den pin-Mechnismus der doch funktionieren sollte. Folgender Code könnte das Problem lösen:

unsigned int __stdcall Init( void** lpUserData )
{
if ( lpUserData )
{
     CMyManagedObject^ refOb = gcnew CMyManagedObject();
     pin_ptr pInteriorPointer = &refOb;
     *lpUserData = pInteriorPointer;
  }
return 0;
};

Hierzu muss man wissen das gepinnte Pointer nur so lange gültig sind, bis das entsprechende StackFrame verlassen wird. Dadurch wäre unser Pointer schon bald nicht mehr sicher und der GC würde beim nächsten Cycle unter Umständen den Heap verändern. Wie also weitermachen? Mit GC-Handles steht uns eine Möglichkeit zur Verfügung einen eindeutigen und positionsunabhängigen Verweis auf ein managed Objekt zu erzeugen. Als besonders nützlich stellt sich die Tatsache heraus, das dieser Verweis in Form eines Integer Wertes daher kommt. Also auf gehts:

if ( lpUserData )
{
CMyManagedObject^ refOb = gcnew CMyManagedObject();
GCHandle gch = GCHandle::Alloc( refOb );
IntPtr iRef = gch.ToIntPtr( gch );
*lpUserData = (void*)(int)iRef;
}

Schon fast fertig. Der Integer kann jetzt jederzeit in das Objekt zurück verwandelt werden, solange nicht GCHandle::Free aufgerufen wird. Diese Methode muss aber aufgerufen werden, sobald dieses Handle nicht mehr benötigt wird. Jetzt kommt uns aber ein entscheidender Vorteil zu Hilfe. Im Gegensatz zu pin_ptr darf ein GCHandle-Objekt Member einer Klasse sein. Dadurch ist es möglich die ganze Schnittstelle in einer .NET-Klasse zu kapseln:

class ref CMyManagedObject
{
public:
    IntPtr GetFixedId()
    {
       if (!m_gch.IsAllocated())
         m_gch = GCHandle::Alloc( this );
       return GCHandle::ToIntPtr( m_gch );
    }

    void ReleaseHandle()
    {
      m_gch.Free();
    }

    static CMyManagedObject^ GetTarget( IntPtr ip )
    {
      GCHandle gcHandle = GCHandle::FromIntPtr( ip );
      return (CMyManagedObject^)gcHandle.Target();
    }

protected:
    GCHandle m_gch;
}

Jetzt habe wir die Klasse, nur wie sieht unser Implementierung aus:

unsigned int __stdcall Init( void** lpUserData )
{
if ( lpUserData )
{
     CMyManagedObject^ refOb = gcnew CMyManagedObject();
     IntPtr ip = refOb->GetFixedId();
     *lpUserData = (void*)(int)ip;
  }
return 0;
};

unsigned int __stdcall UnInit( void* lpUserData )
{
if ( lpUserData )
{
     CMyManagedObject^ refOb = CMyManagedObject::GetTarget( (IntPtr)lpUserData )
     refOb->ReleaseHandle();
  }
return 0;
};

Ruft das Framework jetzt die Einsprungspunkte auf, haben wir jederzeit die Möglichkeit auf das .NET-Objekt zu verweisen und den gesamten Umfang des .NET-Frameworks zu nutzen. Durch diese Technik ist es Möglich bestehende Frameworks um Erweiterungen zu bereichern, die mit Hilfe des .NET-Frameworks entwickelt wurden.

Property Handling leicht gemacht

Dirk Eisenberg — Sun, 25 Sep 2005 20:51:00 GMT

Da es heute regnet und auch der SixFlag-Park hier in Chicago geschlossen hat, habe ich mich für meinen Laptop entschieden um weiter an meinem .Net-Binding einer unter meinen Kollegen nicht ganz unbekannten Library zu basteln. Dabei habe ich für C++ Entwickler eine weitere, gewinnbringende Verbesserung durch die neue C++/CLI angetroffen.

Folgendes C#-Pattern ist wohl jedem bekannt:

public string Name
{
    get
    {
        return m_name;
    }
    set
    {
        m_name = value;
    }
}

Genau es ist die Implementierung einer Eigenschaft die über die Methode set geschrieben und mit get gelesen werden kann. Dabei braucht der Benutzer dieser Klasse nicht set und get selbst aufrufen, nein das Framework steuert den Aufruf über die Zugriffsrichtung. Das finde ich ist schonmal eine nützliche Sache nur wie hat das managed C++ gelöst ?

__property String* get_Name()
{
    return m_value;
}
__property String* set_Name(String* value)
{
    m_value = value;
}

Es gab nur das keyword __property, welches eine Methode als setter bzw. getter einer Property markiert, wodurch so mancher während der Maintenance verwirrt werden konnte. Das wurde mit der neuen C++/CLI geändert. Jetzt sind folgende Konstrukte möglich.

property String^ Name
{
    public:
     String^ get()
     {
        return m_value;
     }

    private:
     void set(String^ value)
     {
        m_value = value;
     }
}

Das Beste aus meiner Sicht ist die unterschiedliche Markierung des Codes als public oder private. So kann gesteuert werde ob der zugriff auf das Klassen-Member nur lesend, nur schreibend oder unbeschränkt erlaubt ist.

Weiterhin kann man natürlich Threading-Issues in diesen Methoden elegant implementieren und der Nutzer kommt nicht herum durch diesen Code zu laufen, weil ja der Compiler für den Sprung in diese Methoden sorgt.

CFoo^ foo = gcnew CFoo();
foo->Name = "Hello World";

Das war bei unmanaged C++ anders. Ich hoffe es kommt beim Thema Multi-Threading keiner auf die platte Idee zu meinen, wenn die Variable static ist, wird der Zugriff darauf durch das Framework sowieso serialisiert. Wer dieser Meinung ist, sollte nochmals die Definition von static nachlesen (und zwar in alle Variation, managed und unmanged).

C++/CLI, C4980, box, pin

Dirk Eisenberg — Tue, 06 Sep 2005 11:22:00 GMT

Eigentlich wollte ich doch nur über eine etwas ältere Win32-Dll ein nettes .NET-Interface bauen. Es sollte Klassen geben zur Verwaltung der Resourcen und Zugriffe usw. Natürlich sollte alles gleich mit dem neusten vom neusten funktionieren und somit habe ich mich für Visual Studio Beta 2 mit dem .NET-Framework 2 entschieden. Nachdem die erste Hürden überwunden waren und ich mich etwas mit dem GC beschäftigt hatte, erschien die nette Warnung C4980: '__gc' : use of this keyword requires /clr:oldSyntax command line option Ich ahnte nicht gutes. Nach einigem Suche habe ich kapiert das im .NET-Framework 2 einiges an der Integration von C++ geändert wurde (oh hätte ich vielleicht am Anfang erwähnen sollen, ja ich nutze dazu C++ und nicht C#). Dankbar war ich dann für folgenden Link

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/VS05Cplus.asp

Ich versuche mal mit zwei Veränderungen zu starten, die aus meiner Sicht von großem Interesse sind:

Nutzung der C++ Pointer-Darstellung zum Zugriff auf Objekte die der Speicherverwaltung des GC unterliegen

In vorherigen Versionen gab es das keyword __gc um deutlich zu machen, das es sich um eine Klasse unter der Aufsicht der GC handelt oder das die Speicherallokation auf dem managed Heap stattfindet. Das Ergebnis war augenscheinlich ein C++-Pointer. Das Problem dabei stellt die automatische Verschiebung der Objekte durch den GC dar. Weiterhin ist es unter Umständen einer Funktion/Methode nicht mehr möglich anzusehen ob diese nun einen managed-Pointer erwartet oder nicht(zumindest nicht sofort). Auch folgender Code war mit unter nicht eindeutig:

CMyClass* pClass = new CMyClass();

Ist die Klasse durch das keyword __gc als managed markiert kommt dabei was ganz anderes raus als ein nativer C++-Pointer. Da ist folgender Code schon klarer:

CMyClass __gc* pClass = new CMyClass();

Im .NET Framework 2 hat man dem ein Ende gesetzt und einen nen Operator sowie ein neues Schlüsselwort für Klassen eingeführt. Der Operator '^' markiert jetzt eine Referenz auf ein Objekt im managed Heap des GC. Das Schlüsseltwort 'ref' markiert eine Klasse als managed. Zusätzlich wurde der überladene new-Operator verworfen und dafür der gcnew-Operator eingeführt (Betrifft wieder nur C++). Jetzt ist eine klare Trennung zwischen Allokationen auf dem managed Heap und dem CRT-Heap möglich.

ref class CMyClass
{
public:
CMyClass() {};
};

CMyClass^ refObjectt = gcnew CMyClass();

Implizites Boxing ersetzt __box

Boxing wird benötigt um einen Brücke zwischen den Wert-Typen und richtigen Objekte zu schaffen. Wenn man sich einen int-Wert-Typ mal genau betrachtet ist er gar kein richtiges Objekte, obwohl doch alles in der CLR von System::Object abgeleitet sein sollte. Ein int-Wert stellt einfach nur Daten auf dem Stack dar. Erst durch das Boxing des int-Wertes wird ein richtig Objekt draus.(An dieser Stelle sei auf den oben genannten Link verwiesen). Also was musste man früher als C++-Entwickler machen:

int value_i = 5;
System::Object* pObject = __box(value_i);

Das ist aber garnicht C++-Like also wurde hier aus dem expliziten Boxing mit Hilfe des neu eingeführten Referenz-Operators ein implizites Boxing:

int value_i = 5;
System::Object^ refObject = value_i;
int value_i2 = *(int^)refObject;

Wie bekommt man jetzt aber eine vernünftige Initialisierung einer Referenz hin ? Ganz einfach, man nutzt das neu eingeführte keyword nullptr. Auch das ist wieder eine Veränderung die nur C++ betrifft. C# begnügt sich weiterhin mit null.

System::Object^ refObject = nullptr;

Wie geht es weiter ?

Ich werde in einem der nächsten Posts die Reihe mit folgenden Themen weiterführen:

Das IDispose-Interface
Property-Handling

Wer darauf nicht warten will, kann do oben aufgeführten Artikel lesen.
Kommentare, Erweiterungen oder Korrekturen sind herzlich willkommen.

WinFS is back on track [Update]

Dirk Eisenberg — Wed, 31 Aug 2005 09:55:00 GMT

Auch auf Channel 9 hat sich viel zu diesem Thema getan.

http://channel9.msdn.com/showpost.aspx?postid=106356

WinFS is back on track

Dirk Eisenberg — Wed, 31 Aug 2005 09:36:00 GMT

Es geschehen noch Zeichen und Wunder, Microsoft hat heute die Beta 1 des aus Windows Vista verschwundenen WinFS released. Alle MSDN-Kunden bzw. PDC-Teilnehmern steht die Beta zum Download zur Verfügung. Was kommt nun mit?

Natürlich WinFS als System selbst inklusiven einer Shell-NameSpace-Extension und eine Win32 Integration. Damit ist ein WinFS-Storage kompatibel zur Win32-File-IO-Api.
Die .NET-Api für WinFs inklusive Dokumentation
Einige Tools, die aber als unsupported gelten

Hier soll noch kurz erwähnt werden welche Tools mitkommen und was damit gemacht werden kann (oder auch nicht). Alle Tools befinden sich nach der Installation im Unsupported-Ordner.

StoreSpy bietet die Möglichkeit alle in einem Storage liegende Daten etwas genauer anzuschauen. Es können alle bekannten Attribute ausgelesen werden und Beziehungen zwischen einzelnen Items visualisiert werden. Das Tool soll auch einen Synchronisationsfunktion mit Outlook haben, hat bei mir aber noch nie getan.

Der WinFSTypeBrowser ist ein nützliches Tool um alle bekannten WinFS-Typen anzuschauen. Dabei kann der gesamte .NET-Namensraum bestaunt werden. Sehr hilfreich wenn man mit WinFS startet (so wie ich).

Hat man dann mal Lust auf mehr bekommen bietet sich OPather an, damit ist es möglich OPath-Anfragen an WinFS zu stellen ohne großen Programmieraufwand. Das Tool generiert auch gleich den benötigten C#-Code für die erzeugte Abfrage.

Zuletzt sei noch Rave erwähnt. Dieses Tool basiert auf WinFS-Sync und bietet die Möglichkeit Daten zwischen zwei WinFS-Ordnern zu synchronisieren.

Als Artikel versteckt findet sich ein kleines Tool was die ersten Schritte mit der WinFS-Api zeigt. Weiter Samples und Ausführungen zu diesem Thema folgen bald.