seeseekey.net - Invictus Deus Ex Machina

Manch­mal ist es nötig je nach Kon­fi­gu­ra­tion ein ande­res Assem­bly in ein .NET/Mono Pro­jekt ein­zu­bauen. Direkt im Visual Stu­dio funk­tio­niert das lei­der nicht. Aller­dings kann man die Ein­stel­lung mit einem Text­edi­tor in der Pro­jekt­da­tei vornehmen:

<Reference Include="libInterval" Condition="'$(Configuration)'=='Debug'">
  <HintPath>libInterval\x32-debug\libInterval.dll</HintPath>
</Reference>
<Reference Include="libInterval" Condition="'$(Configuration)'=='Release'">
  <HintPath>libInterval\x32-release\libInterval.dll</HintPath>
</Reference>

Wich­tig ist dabei der „Condition“-Teil wel­cher fest­legt das die eine DLL nur bei der jewei­li­gen Kon­fi­gu­ra­tion genutzt wird. Durch die­sen lan­det das rich­tige Assem­bly spä­ter im ent­spre­chen­den Buildordner.

Über das Wochen­ende hatte ich einige GPS getagte Bil­der geschos­sen und wollte diese auf einer Karte dar­stel­len. Eine kurze Suche im Netz ergab, das so etwas in die­ser Form nicht exis­tierte (wobei hier natür­lich ein Irr­tum vor­lie­gen kann). Also wurde das ganze auf Basis von Leaf­let implementiert.

Die Webapplikation in Aktion

Die Webap­pli­ka­tion in Aktion

Leaf­let ist ein Frame­work mit wel­chem man schnell Kar­ten­ap­pli­ka­tio­nen im Web rea­li­sie­ren kann. Um den „Gps Tag­ged Image Viewer“ zu benut­zen, müs­sen die Dateien auf einem Web­ser­ver kopiert wer­den. Die Bil­der wer­den dabei in den Ord­ner „images“ kopiert. Anschlie­ßend wird das PHP Skript „parseimages.php“ aus dem „utils“ Ord­ner aus­ge­führt. Die­ses ließt die EXIF Daten aus den Bil­dern aus und erzeugt die ent­spre­chen­den Mar­ker in einer Java­script Datei. Danach kann das ganze genutzt werden.

Die Karte ist dabei mit drei Kar­ten­ebe­nen ver­se­hen, ein­mal Bing Luft­bil­der (für wel­che ein API-Key regis­triert wer­den muss), sowie Open­Street­Map in zwei unter­schied­li­chen Ren­de­rings. Der Quell­text ist unter GPLv3 ver­füg­bar und kann auf Git­Hub bezo­gen werden.

Manch­mal ist es nötig zu ermit­teln für wel­che Platt­form ein Assem­bly kon­fi­gu­riert wurde. Dies kann man dabei unkom­pli­ziert über die „GetAs­sem­bly­Name“ Funk­tion wel­che sich im Name­space „System.Reflection“ befin­det 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 „Pro­ces­sor­Ar­chi­tec­ture“ auch die ent­spre­chende Archi­tek­tur ersichtlich.

Da beginnt man den Tag mit dem gemüt­li­chem Debug­gen von Java­script Code und plötz­lich bekommt man von Chrome fol­gende Mel­dung auf der Javascript-Konsole:

Cross origin requests are only supported for HTTP.

vor­ge­setzt. Da stellt sich natür­lich die Frage was pas­siert ist. Die Ant­wort ist rela­tiv ein­fach. Chrome unter­bin­det das die betref­fende Webap­pli­ka­tion etwas von einem ande­ren Ursprung laden kann. Bei HTTP würde so etwas funk­tio­nie­ren. Wenn man das ganze über das „file:///“ Schema auf­ruft wird es etwas kom­pli­zier­ter. Dafür muss Chrome der Para­me­ter „-allow-file-access-from-files“ über­ge­ben wer­den, wel­cher das ganze dann wie­der erlaubt. Unter Mac OS X könnte die Kom­man­do­zeile dann wie folgt aussehen:

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

Danach funk­tio­nie­ren die „Cross ori­gin requests“ unter Chrome auch lokal.

Unter .NET kann man Assem­blies mit einem „Strong Name“ ver­se­hen. Die­ser sorgt dafür das dass Assem­bly ein­deu­tig iden­ti­fi­ziert wer­den kann. Möchte man einen sol­chen erstel­len so benö­tigt man zuerst ein Schlüs­sel­paar wel­ches mit dem „Strong Name Uti­lity“ ange­legt wird:

sn –k keypair.snk

Das Tool befin­det sich dabei im Win­dows SDK Ord­ner (z.B. C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A) wobei sich die Ver­sion des SDKs durch­aus unter­schei­den kann. Die erzeugte Snk-Datei wird dabei dem Pro­jekt hin­zu­ge­fügt. Anschlie­ßend stellt man in den Pro­jekt­ein­stel­lun­gen unter „Signing“ die ent­spre­chende Datei ein. In die­sem Tab ist es auch mög­lich eine neue Schlüs­sel­da­tei zu gene­rie­ren, so das man für den Schritt der Erzeu­gung nicht auf das „Strong Name Uti­lity“ ange­wie­sen ist.

Die Projektoptionen im Visual Studio

Die Pro­jek­top­tio­nen im Visual Studio

Bei der Signie­rung ist es wich­tig dar­auf zu ach­ten, das alle Biblio­the­ken eben­falls mit einem Strong Name ver­se­hen sind, sonst ver­wei­gert das Stu­dio die Signie­rung der Anwen­dung. Möchte man aus dem signier­ten Assem­bly den öffent­li­chen Schlüs­sel extra­hie­ren, so kommt wie­der das „Strong Name Uti­lity“ zur Anwendung:

sn -e Assembly.exe public.pk

Das Schlüs­sel­paar wel­ches man erzeugt hat, kann man dabei für alle eige­nen Anwen­dun­gen benut­zen. Es ist nicht nötig, für jede Anwen­dung ein eige­nes Schlüs­sel­paar zu erzeu­gen, da sich der „Sim­ple­Name“ bei jedem Assem­bly unterscheidet.

Wei­tere Infor­ma­tio­nen 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

Manch­mal ergibt es Sinn Quell­code der in Visual Basic vor­liegt nach C# zu kon­ver­tie­ren. Ein freies Tool, wel­ches auch große Men­gen kon­ver­tie­ren kann ist dabei „Econ Net­Vert“. Neben der Mög­lich­keit Visual Basic nach C# zu kon­ver­tie­ren, steht auch der umge­kehrte Weg offen.

NetVert in Aktion

Net­Vert in Aktion

Auch das Kon­ver­tie­ren von meh­re­ren Dateien ist kein Pro­blem, genauso wie die Umwand­lung gan­zer Pro­jekte. Bei „Econ Net­Vert“ han­delt es sich um freie Soft­ware wel­che unter der GPLv2 steht. Bezo­gen wer­den kann die Anwen­dung und der Quell­text unter http://econnetvert.codeplex.com .

Die Ent­wick­lung eines Spie­les zu begin­nen, ist eine rela­tiv ein­fa­che Ange­le­gen­heit. Schwie­ri­ger wird es ein sol­ches zu been­den. Denn hier schlägt meist die Pro­kras­ti­na­tion zu. Damit das nicht so bleibt wurde die Web­seite „One Game a Month“ ins Leben geru­fen. Ziel ist es pro Monat genau ein Spiel zu ent­wi­ckeln. Dabei kann man sich auch mit ande­ren Ent­wick­lern ver­glei­chen und schauen was diese so auf die Beine gestellt haben. Regeln gibt es eigent­lich keine, alle Platt­for­men sind erlaubt und auch sonst ist einem eigent­lich alles frei­ge­stellt. Wich­tig ist nur das pro Monat ein Spiel fer­tig wird. Zu fin­den ist die Web­seite unter http://www.onegameamonth.com.

Mit der Instal­la­tion einer Ver­sion des Visual Stu­dios lan­den eine Menge Tools auf dem Rech­ner des Benut­zers. Eines der Tools wel­che dabei lei­der nicht auf der Platte lan­det, ist der CLR Pro­fi­ler, wel­cher auch aus dem Hause Micro­soft stammt.

Eine Auswertung des CLR Profilers

Eine Aus­wer­tung des CLR Profilers

Mit die­sem Tool kann die Inne­reien sei­ner .NET Soft­ware, wie die Spei­cher­brauch im Heap, die Hand­le­an­for­de­run­gen und ähn­li­ches ana­ly­sie­ren und aus­wer­ten. Her­un­ter­ge­la­den wer­den kann der CLR Pro­fi­ler unter http://www.microsoft.com/en-us/download/details.aspx?id=16273.

Wenn man in Xcode eine iOS oder Mac OS X App schreibt, so ist manch­mal auf bestimmte Con­trols ange­wie­sen, wel­che nicht in den Stan­dard BIblio­the­ken zu fin­den sind. Abhilfe schaf­fen hier soge­nannte „Custom Con­trols“, wel­che über­all im Netz zu fin­den sind.

cocoacontrols.com

cocoacontrols.com

Eine zen­trale Anlauf­stelle für sol­che Con­trols bie­tet dabei die Seite cocoacontrols.com. Dort sind die Con­trols nach Lizen­zen, Betriebsys­tem und eini­gen ande­ren Kate­go­rie­ren sor­tiert, so das man meist rela­tiv schnell das pas­sende Con­trol findet.

In Java­Script kann man ver­nünf­tig pro­gram­mie­ren, wenn man die schlech­ten Teile weg­lässt. Nicht umsonst gibt es das Buch Java­Script: The Good Parts. Dabei haben sich im Laufe der Zeit einige „Best Prac­tices“ ent­wi­ckelt, wel­che unter ande­rem in Form von Design Pat­terns vor­lie­gen. Auf der Web­seite http://shichuan.github.com/javascript-patterns/ kann man sich diese anschauen und so sehen, was man in Zukunft bes­ser machen kann. Das ent­spre­chende Git­Hub Pro­jekt ist dabei unter https://github.com/shichuan/javascript-patterns/ zu fin­den. Lei­der scheint es keine defi­nierte Lizenz für das Pro­jekt zu geben, so das der Lizenz­sta­tus im Moment augen­schein­lich noch unge­klärt ist.