Managed Assembly-Architektur unter .NET ermitteln

Manchmal ist es nötig zu ermitteln für welche Plattform ein Assembly konfiguriert wurde. Dies kann man dabei unkompliziert über die „GetAssemblyName“ Funktion welche sich im Namespace „System.Reflection“ befindet ermitteln:

System.Reflection.AssemblyName.GetAssemblyName(@"C:\Temp\CSCL.dll");

Aus der Ausgabe:

{CSCL, Version=1.4.1.3, Culture=neutral, PublicKeyToken=null}
    CodeBase: "file:///C:/Temp/CSCL.dll"
    ContentType: Default
    CultureInfo: {}
    CultureName: ""
    EscapedCodeBase: "file:///C:/Temp/CSCL.dll"
    Flags: PublicKey
    FullName: "CSCL, Version=1.4.1.3, Culture=neutral, PublicKeyToken=null"
    HashAlgorithm: SHA1
    KeyPair: null
    m_siInfo: null
    Name: "CSCL"
    ProcessorArchitecture: X86
    Version: {1.4.1.3}
    VersionCompatibility: SameMachine

ist dann unter „ProcessorArchitecture“ auch die entsprechende Architektur ersichtlich.

Probleme mit Chrome und lokalem Javascript

Da beginnt man den Tag mit dem gemütlichem Debuggen von Javascript Code und plötzlich bekommt man von Chrome folgende Meldung auf der Javascript-Konsole:

Cross origin requests are only supported for HTTP.

vorgesetzt. Da stellt sich natürlich die Frage was passiert ist. Die Antwort ist relativ einfach. Chrome unterbindet das die betreffende Webapplikation etwas von einem anderen Ursprung laden kann. Bei HTTP würde so etwas funktionieren. Wenn man das ganze über das „file:///“ Schema aufruft wird es etwas komplizierter. Dafür muss Chrome der Parameter „-allow-file-access-from-files“ übergeben werden, welcher das ganze dann wieder erlaubt. Unter Mac OS X könnte die Kommandozeile dann wie folgt aussehen:

open /Applications/Google\ Chrome.app/ --args -allow-file-access-from-files

Danach funktionieren die „Cross origin requests“ unter Chrome auch lokal.

Strong Name für eine .NET Applikation erzeugen

Unter .NET kann man Assemblies mit einem „Strong Name“ versehen. Dieser sorgt dafür das dass Assembly eindeutig identifiziert werden kann. Möchte man einen solchen erstellen so benötigt man zuerst ein Schlüsselpaar welches mit dem „Strong Name Utility“ angelegt wird:

sn –k keypair.snk

Das Tool befindet sich dabei im Windows SDK Ordner (z.B. C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A) wobei sich die Version des SDKs durchaus unterscheiden kann. Die erzeugte Snk-Datei wird dabei dem Projekt hinzugefügt. Anschließend stellt man in den Projekteinstellungen unter „Signing“ die entsprechende Datei ein. In diesem Tab ist es auch möglich eine neue Schlüsseldatei zu generieren, so das man für den Schritt der Erzeugung nicht auf das „Strong Name Utility“ angewiesen ist.

Die Projektoptionen im Visual Studio

Die Projektoptionen im Visual Studio

Bei der Signierung ist es wichtig darauf zu achten, das alle Bibliotheken ebenfalls mit einem Strong Name versehen sind, sonst verweigert das Studio die Signierung der Anwendung. Möchte man aus dem signierten Assembly den öffentlichen Schlüssel extrahieren, so kommt wieder das „Strong Name Utility“ zur Anwendung:

sn -e Assembly.exe public.pk

Das Schlüsselpaar welches man erzeugt hat, kann man dabei für alle eigenen Anwendungen benutzen. Es ist nicht nötig, für jede Anwendung ein eigenes Schlüsselpaar zu erzeugen, da sich der „SimpleName“ bei jedem Assembly unterscheidet.

Weitere Informationen gibt es unter:
http://msdn.microsoft.com/en-us/magazine/cc163583.aspx
http://msdn.microsoft.com/en-us/library/h4fa028b%28v=vs.80%29.aspx

Visual Basic zu C# konvertieren

Manchmal ergibt es Sinn Quellcode der in Visual Basic vorliegt nach C# zu konvertieren. Ein freies Tool, welches auch große Mengen konvertieren kann ist dabei „Econ NetVert“. Neben der Möglichkeit Visual Basic nach C# zu konvertieren, steht auch der umgekehrte Weg offen.

NetVert in Aktion

NetVert in Aktion

Auch das Konvertieren von mehreren Dateien ist kein Problem, genauso wie die Umwandlung ganzer Projekte. Bei „Econ NetVert“ handelt es sich um freie Software welche unter der GPLv2 steht. Bezogen werden kann die Anwendung und der Quelltext unter http://econnetvert.codeplex.com .

One Game a Month

Die Entwicklung eines Spieles zu beginnen, ist eine relativ einfache Angelegenheit. Schwieriger wird es ein solches zu beenden. Denn hier schlägt meist die Prokrastination zu. Damit das nicht so bleibt wurde die Webseite „One Game a Month“ ins Leben gerufen. Ziel ist es pro Monat genau ein Spiel zu entwickeln. Dabei kann man sich auch mit anderen Entwicklern vergleichen und schauen was diese so auf die Beine gestellt haben. Regeln gibt es eigentlich keine, alle Plattformen sind erlaubt und auch sonst ist einem eigentlich alles freigestellt. Wichtig ist nur das pro Monat ein Spiel fertig wird. Zu finden ist die Webseite unter http://www.onegameamonth.com.