Es ist soweit, die bereits vor kurzem in diesem Blog angekündigte Version von Mono for Android ist ab sofort verfügbar. Jedoch nicht wie chronologisch vermutet in der Version 2.0 sondern in der Version 4.0. Damit passt Xamarin auch die Mono Versionen an die jeweiligen Versionen des Betriebssystems an, Mono for Android 4.0 = Android 4 (Ice Cream Sandwich) und MonoTouch 5 = iOS 5 .

Die wichtigsten Neuerungen auf einen Blick:

1. Unterstützung von Android 3.x (Honeycomb) und Android 4.0 (Ice Cream Sandwich). Alle damit verbundenen APIs können jetzt benutzt werden.
2. Die Google Maps API wird jetzt durch die neu ausgelieferte Mono.Android.GoogleMaps.dll unter C# unterstützt.
3. Der Startvorgang von Applikationen die mit dem Standard-Template erstellt werden, wurde um 50% (gemessen auf einem Nexus One) beschleunigt.
4. Der Deploymentvorgang auf Emulatoren und angeschlossene Mobiltelefone wurde beschleunigt, dies gilt solange sich keine Ressourcen oder Java Stubs geändert haben.
5. Einige Bufixe im Garbage Collector
6. Verbesserter Installer der neben Mono for Android auch alle benötigten Komponenten (Java, Andoird SDK usw.) automatisch installiert.

Genauere Informationen zu den Änderungen durch Mono for Android 4.0 sowie die Änderungen in den einzelnen API Level finden sich hier.

Alle Anwender von Visual Studio (ab Mono for Android 1.9.1) und MonoDevelop sollten beim nächsten Start automatisch auf das Update hingewiesen werden. Sollte dies nicht der Fall sein, kann die aktuelle Version 4.0 von Xamarin heruntergeladen werden.

Nachdem bis jetzt die Plattform und der Einsatz von Mono festeht, können wir uns den ersten Schritten bei der Entwicklung mit Mono zuwenden. Genauer gesagt geht es darum Mono for Android zu installieren und  die verschiedenen Möglichkeiten des Testens kennen zu lernen.

Systemanforderungen

Es gibt lediglich zwei Voraussetzungen die vorab abgeklärt werden müssen. Es werden zwei Betriebssysteme unterstützt, Windows und Mac OS. Für Mac OS ist die Entwicklungsumgebung MonoDevelop verfügbar, für Windows kann ebenfalls MonoDevelop oder Visual Studio 2010 Professional und höher verwendet werden. Der Einsatz von Visual Studio Express ist nicht möglich!

Installation

Im folgenden beschreibe ich kurz die Installation von Mono for Android mit Visual Studio unter Windows. Anleitungen für alle anderen Kombinationen findet man hier.

Schritt 1: Java JDK Installation

Bevor weitere Komponenten installiert werden können, muss das Java JDK installiert werden. Bis zum Release 1.9 wurde lediglich das JDK 6 unterstützt, seit dem Release 1.9 kann aber auch das JDK 7 verwendet werden. Das JDK kann von folgender Seite heruntergeladen werden: http://www.oracle.com/technetwork/java/javase/downloads/index.html

Wichtig ist zu beachten das bei der Installation die 32Bit Version und nicht die 64Bit Version verwendet wird, da das Android SDK nur die 32 Bit Version unterstützt. Das JRE wird nicht benötigt.

Schritt 2: Android SDK installieren

Das aktuelle Android SDK findet man unter http://developer.android.com/sdk/index.html (.exe Datei). Nach der Installation sollte der SDK Manager ausgeführt werden, dieser läd die verschiedenen SDK-Versionen und Tools, die für die Entwicklung mit Android nötig sind, herunter. Dort müssen mindestens folgende Pakete installiert werden:

1. Android SDK Tools, Revision 10 oder höher
2. Android SDK Platform-Tools, Revision 3 oder höher
3. Eine oder mehrere der Android API’s, ich empfehle die API 8 (Android 2.2) sowie die API 10 (Android 2.3.3). Wer für Tablets und ganz neu Geräte entwickelt kann auch die höheren Versionen installieren. Wer eine möglichst hohe Abwärtskompatibilität möchte sollte noch niedrigere Versionen verwenden. Gegen die hier gewählten Versionen wird unser C# Projekt später kompiliert. Weiter Versionen können auch im nachhinein installiert werden.
4. Zusätzlich können noch bei Bedarf die Pakete unter “Extras” installiert werden um z.B. die Google USB Treiber zu erhalten

Schritt 3: Mono for Android Installation

Das eigentliche Mono-Framework inkl. Visual Studio Plugin wird erst jetzt installiert. Vor der Installation sollten alle laufenden Instanzen von Visual Studio beendet werden. Die aktuellen Release finden sich unter: http://android.xamarin.com/Releases/Mono_for_Android_1 wer eine der Previews installieren möchte (um z.B. vorab die neusten Entwicklungen zu testen) findet diese Versionen unter http://android.xamarin.com/Releases/Previews. Nachdem das Framework installiert ist sind alle Vorbereitungen getroffen um mit der Entwicklung der ersten App zu beginnen. Die Einrichtung des Emulators wird nicht mehr benötigt, da bereits ein Standardemulator nach der Installation vorhanden ist.

Im letzten Beitrag haben Sie bereits erfahren welche Anforderungen vor der Entwicklung einer eigenen App abgeklärt werden müssen. Wir haben und also bereits eine Zielgruppe ausgesucht, der Endgerätetyp steht fest und die Hardwareanforderungen sind definiert. Nun geht es zumindest mir so, wenn ich schon den ganzen Aufwand für die Entwicklung in eine App stecke, möchte ich das diese auch auf möglichst vielen Smartphones/Tablets lauffähig ist. Aus diesem Grund habe ich mich für die Plattformübergreifende Entwicklung mit dem Mono-Framework entschieden. Worum es sich dabei handelt und welche Vorteile es bietet erfahren Sie in diesem Artikel.

Das .NET Framework entstammt aus dem Hause Microsoft und wird auch aktiv von deren Mitarbeitern weiterentwickelt. Jodoch wird das .NET Framework nur für Windows-Produkte von Microsoft selbst entwickelt, andere Betriebssysteme werden offiziell nicht unterstützt. Aus diesem Grund wurde das Mono-Projekt ins Leben gerufen, das sich die portierung der .NET-Plattform auf andere Betriebssysteme zur Aufgabe gemacht hat. Nach mehreren Jahren hat 2011 die Firma Xamarin die Entwicklung und den Support von Mono übernommen.

MonoTouch

Xamarin hat neben dem Mono Projekt für Linux & co. auch die Lizenz für MonoTouch erhalten. Bei MonoTouch handelt es sich um eine Portierung des .NET Frameworks für die iOS-Systeme von Apple. MonoTouch kompiliert dabei die in C# geschriebenen Anwendungen in nativen Machinencode, da der iPhone-Kernel das Ausführen von Just-In-Time Kompilern verbietet. Die erste Version, MonoTouch 1.0, erschien, damals noch entwickelt unter Novell, am 14.09.2009.

Nach weiteren Versionen 2 und 3 war das Fortbestehen von MonoTouch ab April 2010 unklar, da Apple neue Lizenzbedingungen für Applikationen veröffentlichte. Durch diesen Bedingungen war die Verwendung von anderen Programmiersprachen wie C, C++ and Objective-C untersagt. Erst im September 2010 lockerte Apple diese Lizenzbedingungen und MonoTouch wurde wieder aktiv weiterentwickelt.

Mono for Android alias MonoDroid

Genauso wie MonoTouch handelt es sich bei Mono for Android um eine portierung des .NET Frameworks durch Xamarin. Dabei wird es C#-Enwtcikelern ermöglicht den geschriebenen Code auf Geräten mit Android Betriebssystem auszuführen. Im gegensatz zur MonoTouch kompiliert Mono for Android die Applikationen aber nicht in nativen Code, sondern liefert eine Runtime aus die den C#-Code in Java übersetzt. Da die Runtime an die Applikation gelinkt wird, ist es nicht notwendig zusätzliche Pakete auf dem Endgerät zu installieren.

Die erste Betaversion von MonoDroid erschien im August 2010, im April folgte die Version 1.0. Bis heute wurden zahlreiche weitere Zwischenversionen veröffentlicht. In Kürze soll das neue Release 2.0 erscheinen.

Plattformübergreifende Entwicklung

Wie bereits im letzten Artikel erwähnt, ist Mono das einzige plattformübergreifende Framework mit dem es möglich ist in einer Programmiersprache Anwendungen für verscheidene mobile Betriebssysteme zu entwickeln. Dazu kann der Programmcode einmal geschrieben und für mehrere Betriebssysteme kompiliert werden. Allerdings gibt es einige Einschränkungen. Alle Grafischen Oberflächen sowie der Zugriff auf die Hardware (Kamera, GPS, Audio, usw.) sind Gerätespezifisch, also auf das jeweilige Betriebssystem festgelegt. Das bedeutet diese Zugriffe müssen gekapselt und die Businesslogik in seperate Klassen/dlls ausgelagert werden. Der Zugriff auf die Folgenden Bibliotheken kann dabei problemlos in der gemeinsamen Businesslogik verwendet werden:

- mscorlib.dll
- System.dll
- System.Core.dll
- System.Json.dll
- System.Runtime.Serialization.dll
- System.ServiceModel.dll
- System.ServiceModel.Web.dll
- System.Web.Services.dll
- System.Xml.dll
- System.Xml.Linq.dll
- Mono.Security.dll
- Mono.Data.Sqlite.dll
- Mono.Data.Tds.dll
- monotouch.dll
- OpenTK.dll

Zu beachten ist das alle Mono.XXX.dll Bibliotheken für Android und iOS verwendbar sind, für die Verwendung mit Windows Phone 7 müssen auch diese Zugriffe gekapselt werden. Die OpenTK.dll (Bibliothek für den Einsatz von OpenGL) ist sowohl für Android wie auch iOS übergreifend verwendbar.

Zusammenfassend ist es also möglich die Businesslogik für alle drei mobilen Betriebssysteme zu verwenden. Der Zugriff auf UI-Komponenten, Hardware und vereinzelte Bibliotheken muss jedoch gekapselt und je System einzeln implementiert werden. Der nächste Abschnitt beschreibt wie in Zukunft auch diese zusätzliche Kapselung entfallen könnte.

Xamarin Mobile API

Vor sechs Tagen, am 22. November 2011, hat Xamarin die neue API Xamarin Mobile auf Ihrem Blog vorgestellt. Doch um was handelt es sich dabei? Bisher muss die Businesslogik seperat von den plattformspezifischen Hardwarezugriffen und Grafikbibliotheken entwickelt werden. Dies bedeutet zum Teil doppelten Aufwand wenn eine App auf mehreren Betriebssystemen ausgeliefert werden soll. Die Xamarin Mobile API setzt an diesem Punkt an und zieht eine weitere Zwischenschicht ein. In Zukunft erfolgt der Zugriff auf Hardware- und UI-Komponenten über die Mobile API von Xamarin. Diese API kümmert dich dann um die jeweiligen Plattformspezifischen Eigenheiten. Dadurch muss in Zukunft keine Kapselung der Businesslogik durchgeführt werden. Das Ziel soll also ganz klar sein, jede Funktion soll nur einmal geschrieben werden und auf verscheidenen plattformen eingesetzt werden können.

Zum Start stellt Xamarin die Mobile API mit der Unterstützung für Geolocation-Basierte Zugriffe (Ortsbestimmung über GPS usw.) zum Download zur Verfügung. Diese sind vorerst für Android und iOS verwendbar, ein Update für Windows Phone soll ebenfalls bald erscheinen. In einer Online-Umfrage wird bereits jetzt abgefragt welche Komponenten (Kamera, Kontakte, Audio, …)  als nächstes durch Xamarin für die Mobile API implementiert werden sollen. Zu hoffen ist das diese Entwicklung auch weiterhin so rasant fortgeführt wird um den doppelten Arbeitsaufwand zu veringern und die Verbreitung von Mono zu beschleunigen.

Ich besitze eine unter Entwicklern weit verbreitete Krankheit. Wenn mir eine Idee in den Kopf kommt möchte ich am liebsten sofort los programmieren ohne mir zuvor Gedanken über Plattformen, Endgeräte und Technische Voraussetzungen machen zu müssen. Da ich mich bisher nahezu ausschließlich mit Desktop-Applikationen beschäftigt habe hat das auch wunderbar funktioniert. Der Grund: Windows nutzt sowieso fast jeder, das .NET Framework ist auf jedem PC installierbar und  ausreichend Performance ist mit heutigen PC’s meist kein Problem mehr.

Doch als Entwickler von mobilen Apps sieht das schon ganz anders aus. Wenn die Zielgruppe nicht klar ist, braucht man erst gar nicht mit dem Entwickeln anzufangen. Im schlimmsten Fall ist sonst der aufwändig zusammengeschusterte Code unbrauchbar. Daher sollten die folgenden Punkte stets als erstes geklärt werden:

1. Welche mobilen Endgeräte kommen zum Einsatz (Smartphone, Tablet)
2. Welche Betriebssysteme laufen auf den mobilen Endgeräten (iOS, Android,…)
3. Welche Frameworks/Programmiersprachen sind darauf verfügbar (C, C#, Java,…)
4. Welche Hardwareanforderungen müssen eingehalten werden (CPU, Kamera, …)

Jeder dieser Punkte muss vorab ausführlich durchdacht werden. Änderungen in nur einem der Parameter können zu einem späteren Zeitpunkt des Entwicklungsprozesses weitreichende Auswirkungen haben. Jeder einzelne Punkt wird daher im Folgenden genauer behandelt.

Welche mobilen Endgeräte kommen zum Einsatz?

Mobile Endgeräte können hauptsächlich in zwei Kategorien eingeteilt werden, Smartphones und Tablets. Doch wieso ist es so wichtig jetzt schon zu wissen wo nachher die geplante App zur GPS gestützten Positionierung der Kaffeemaschine  laufen soll? Ganz einfach, die Zielgruppe entscheidet über den Erfolg einer Applikation und wenn eine Zielgruppe gar keinen Zugang zu unserer App hat, wird daraus auch nie ein Erfolg. Zurzeit teilen sich iOS (ca. 66%) und Android (ca. 27%) nahezu den kompletten Tabletmarkt. Wer also an die Entwicklung von Windows Mobile Applikationen gedacht hatte, kann sich das vermutlich ganz schnell aus dem Kopf schlagen.

Welche Betriebssysteme laufen auf den mobilen Endgeräten?

Wie bereits im Punkt zuvor angedeutet, spielt das Betriebssystem eine große Rolle bei der Wahl der geeigneten Entwicklungswerkzeuge. Hier unterscheidet sich der Smartphonemarkt zum Teil deutlich vom Tabletmarkt. Die folgende Grafik zeigt einen kurzen Überblick über die aktuellen (3. Quartal 2011, Marktanalyse durch Gartner und Strategy Analytics) Anteile der jeweiligen Betriebssysteme bei Smartphones und Tablet-PCs.

Die Grafiken zeigen schnell, der Markt wird von iOS und Android dominiert. Symbian (hauptsächlich Nokia Endgeräte) ist zwar bei Smartphones noch relativ stark vertreten, dies wird sich aber in den kommenden Monaten ändern, da Nokia in Zukunft auf Windows Phone 7 statt Symbian setzt.

Dies bedeutet dass aktuell die Plattformen Android, iOS und z.T. Windows Phone 7 für die Entwicklung von Apps interessant sind.

Wichtig ist ebenso die Eingrenzung der Betriebssystemversionen. Die Unterstützung von bestimmten Funktionen in einer der ersten SDK-Versionen von Android unterscheiden sich zum Teil deutlich von der aktuellen SDK Version 4.0.

Welche Frameworks/Programmiersprachen sind darauf verfügbar?

Zuerst muss geklärt werden, welche Sprachen die jeweiligen Betriebssysteme als Standardsprache definieren.

Android: Bei Android ist Java die Sprache der Wahl. Nahezu der komplette Sprachumfang von Java wurde implementiert, für den Zugriff auf die Hardwarekomponenten (GPS, Audio/Video, …) stehen zusätzliche Libraries zur Verfügung. Bei Performancekritischen Anwendungen besteht die Möglichkeit via Native Development Kit (NDK) C/C++-Quelltexte einzubinden.

iOS: Hier dominiert die Sprache Objectiv-C. Dabei handelt es sich um eine Variation des Standard-C Umfangs der um objektorientierte Spracherweiterungen ergänzt wurde.

Windows Phone 7: Da es sich, wie der Name bereits verrät, um ein Microsoft Produkt handelt, wird von Anfang an auf C#/VB.NET gesetzt. Die Verwendung von Silverlight und der XNA Technologie kommen ebenso zum Einsatz.

Damit wäre also klar, dass jedes System von Haus aus auf eine andere Programmiersprache setzt. Hat man den Luxus und kann sich (bzw. die Zielgruppe) auf ein Betriebssystem einschränken, so ist meine Empfehlung stets die Standardsprache des jeweiligen Betriebssystems zu verwenden. Der Vorteil liegt darin das alle Funktionalitäten immer gut getestet sind, neu Features (Hardware/Software) sofort zur Verfügung stehen und die Sprache vermutlich so schnell nicht ausstirbt.

Zwei Gründe können jedoch gegen meine letzte Empfehlung sprechen. Erstens, man beherrscht die Programmiersprache des gewählten Betriebssystems nicht und möchte sie nicht lernen. Zweitens, die geplante App soll auf mehreren Betriebssystemen lauffähig sein. Aus diesem Grund gibt es die Möglichkeit ein Framework einzusetzen, das die Programmierung und den Zugriff auf die Hardware in der Sprache der Wahl zulässt. Zurzeit ermöglicht nur .NET (in Form von Mono for Android/MonoTouch) die Plattformübergreifende Verwendung einer gemeinsamen Programmiersprache.

Java läuft zwar auf Android, jedoch gibt es bisher meines Wissens nach keine Unterstützung für Windows Mobile 7 und iOS. Zumindest für iOS soll ein Compiler folgen der die JVM inkl. Programmcode in Zukunft in einer APP ausliefert, ein genauer Releasetermin steht aber noch nicht zur fest.

Welche Hardwareanforderungen müssen eingehalten werden?

Last but not least die Hardwareanforderungen. Könnte man davon ausgehen dass alle Benutzer stets die neuste Hardware verwenden, wäre dieser Punkt überfällig. Leider sieht die Realität meist anders aus. Nicht jedes Endgerät verfügt über gleich viel Speicher, eine super schnelle CPU oder ein riesiges Display. Auch Komponenten wie Kamera, GPS und Beschleunigungssensoren sind nicht immer vorhanden. Und selbst wenn z.B. eine Kamera vorhanden ist, bedeutet das noch lange nicht dass sämtliche Features unterstützt werden (Auflösung, Autofocus, Zoom,…). Neben der Hardwareaustattung spielt auch die bereits oben erwähnte Version des Betriebssystems eine große Rolle. Daher gilt es vorab genau die nötige Hard- und Software zu definieren auch wenn dies bedeutet das gewisse Benutzer ausgeschlossen werden. Der Test von verschiedenen Systemen (Minimal-/Maximalanforderungen) durch Emulatoren oder, falls vorhanden, durch verschiedene Smartphones/Tablets sollte stets in den Entwicklungsprozess integriert werden.

Zusammenfassung:

Dieser Artikel zeigt dass es wichtig ist bereits vorab die Hard- und Software der Zielgruppe genau zu kennen bzw. zu definieren. Es hat sich herauskristallisiert das iOS und Android (bedingt auch Windows Phone 7) die Betriebssystem der Wahl sind. Wer lediglich für eine Plattform entwickelt ist gut beraten die Standard-Programmiersprachen des jeweiligen Systems zu verwenden. Für Plattformübergreifende Projekte ist das .NET-Framework/Mono die richtige Lösung. Und zu guter Letzt müssen vorab die Minimalanforderungen für die Hardware (Speicher, CPU, Kamera, GPS, ..) definiert werden, damit Zielgruppengerechte Anwendung erstellt werden können.

Lange ist er her, der letzte Artikel. Über 3 Jahre und dafür möchte ich mich vorab entschuldigen. Viel ist seitdem passiert! Hauptsächlich hat sich meine berufliche Situation verändert, seit diesem Jahr bin ich selbständig und somit mein eigener Chef. Dies hat viele Vorteile, doch mehr Zeit hat man dadurch nicht wirklich =:-) Dennoch war es der richtige Weg, nicht nur weil man sich seine Aufgaben selbst aussuchen darf.

So kommt es das ich mich seit kurzem mit der Entwicklung von mobilen Applikationen für Smartphones (im Volksmund Apps) beschäftige. Und da wir hier bei .NET worker sind, handelt es sich natürlich um Apps die mit .NET entwickelt werden. Als Zielplattform steht in erster Linie Android im Vordergrund, doch auch die Entwicklung für iPhone und Windows Phone 7 soll in naher Zukunft berücksichtigt werden. Für alle Plattformen gibt es mittlerweile Mono-Implementierungen oder eine direkte Unterstützung des .NET Frameworks. Und da der Bereich Mono for Android gänzlich vernachlässigt wird in der deutschen Blogszene versuche ich in den nächsten Artikeln diese Lücke zu schließen. Ziel ist es Anfängern (wie mir) den Einstieg in das Thema zu erleichtern und vor Stolperfallen zu warnen.

Viel Spaß bei den nächsten Artikeln!

Heute Abend war ich zum ersten Mal bei einem Treffen der .NET Developers Group Stuttgart zum Thema “Qualitätsmanagement mit VSTS und TFS”. Die Veranstaltung war für mich eine sehr gute Einführung in das Thema und ich empfand Sie als sehr gelungen. Weiterhin gab es noch eine kurze Übersicht welche Testmöglichkeiten in Visual Studio 2008 bestehen. Evt. soll es hierzu auch noch einen eigenständigen Vortrag geben, da es sich doch um ein sehr umfangreiches Thema handelt.

Eintrag komplett lesen »

So nach einer zweichwöchigen Pause melde ich mich nun wieder zum Thema WPF. Da ich zur Zeit sehr viel mit dieser Thematik zu tun habe, werde ich wohl noch das ein oder andere Mal Beiträge zu 2D-Grafiken in WPF schreiben.

Hier nun ein kurzes Beispiel in dem gezeigt wird das man ein UI-Element wie eine Geometrie oder auch z.B. ein Bild mit mehreren Transforms des gleichen Typs transformieren kann. Das bedeutet ich kann z.B. eine Geometrie nicht nur einmal gleichzeitig Rotieren sondern mehrfach, einmal um den eigenen Nullpunkt und einmal um einen versetzten Nullpunkt. Der Vorteil dabei ist das ich nicht wild umher rechnen muss sondern ganz bequem meine Transformationen auf einmal erledigen kann.

Eintrag komplett lesen »

Wer schon einmal vor der Aufgabe stand, den Zustand seiner Objekt in eine XML Datei zu serialisieren weiß das .NET hierfür den Namespace System.Xml.Serialization und im speziellen die Klasse XmlSerializer vorsieht. Jeder der diese Klasse zum Serialisieren oder Deserialisieren schon benutzt hat wird festgestellt haben das nur öffentliche Member der zu serialisierenden Objekte in die XML Datei geschrieben werden. Alle anderen Member werden leider nicht berücksichtigt. Um diese nun doch noch serialisieren zu können, kann man public Properties einführen. Dies ist aber oftmals nicht erwünscht, da andere Klassen diese Member erst gar nicht kennen sollen geschweige denn darauf zugreifen dürfen.

Für dieses Problem liefert WCF (ab dem .NET Framework 3.0) nun Abhilfe. Der Schlüssel zum Ziel hierfür ist die Klasse DataContractSerializer im Namespace System.Runtime.Serialization. Primär dient diese Klasse zur Serialisierung/Deserialisierung von Objekten die mittels WCF z.B. über das Netzwerk verschickt oder empfangen werden. Man kann die Klasse aber auch hervorragend zur Serialisierung seiner eigenen Objekte verwenden und sehr einfach XML-Code aus seinen Objekten erzeugen.

Eintrag komplett lesen »

Gestern bin ich auf ein Problem mit ODBC-Treibern unter 64Bit Systemen wie z.B. Windows 2003 Server oder Windows Vista gestoßen. Dabei sollte eine .NET Anwendung die bisher auf allen 32Bit Systemen problemlos lief auf einem 64Bit Windows 2003 Server installiert und betrieben werden. Das Starten der Anwendung war auch problemlos möglich nur beim Verbinden mit der Datenbank konnte meine Anwendung den ODBC-Treiber bzw. den zugehörigen DSN nicht finden.

Nach aufwendiger Suche hat sich als erstes gezeigt das unter 64 Bit Systemen ODBC nicht gleich ODBC ist. Dies liegt daran das es zwei Arten von ODBC Treibern gibt, 32Bit und 64Bit ODBC Treiber. Viele Systeme liefern bisher aber noch ausschließlich die 32Bit Treiber aus und installieren diese auch. Wenn man nun unter dem Menüpunkt Systemsteuerung->Verwaltung->Datenquellen die Einträge für den System-DSN, User-DSN oder den zugehörigen ODBC Treiber sucht wird man nichts finden. Hier werden lediglich die DSN’s und Treiber angezeigt die 64Bit tauglich sind.

Eintrag komplett lesen »

In letzter Zeit ist Silverlight das große Schlagwort wenn es um neue Webtechnologien im Hause Microsoft geht. Mit der kommenden Version 2.0 werden erstmals viele nützliche Features aus dem .NET Framework in die stark abgespekte Laufzeitumgebung von Silverlight übernommen. Unter den Neuerungen befinden sich Technologien wie LINQ oder die Unterstützung von WS*-Diensten. Das Microsoft auch intern auf Silverlight umstellt kann man z.B. an der Beta der nächsten Download Center Version sehen. Die andere Seite der Medaille gibt es aber auch, so zeigt Rob Eisenberg in seinem Post das in Silverlight noch nicht alles Gold ist was glänzt. Ein Beispiel ist die fehlende 3D-Unterstützung oder Hardwarebeschleunigung.

Eine Alternative stellt hier meiner Meinung nach XBAP (XAML Browser Application) dar. XBAP ist keine neue Technologie sondern schon seit beginn von WPF verfügbar. Es ermöglicht WPF Anwendungen im Browser ausführen zu können. Ein Beispiel findet sich hier.

Eintrag komplett lesen »