Windows 8: WinRT - Die Windows Runtime 30.11.2011

Matthias Jauernig, Senior eXpert

Zur BUILD-Konferenz im September 2011 stellte Microsoft vor allem auch vor, was Windows 8 für Entwickler bedeutet. Im Fokus lag dabei die Entwicklung von (touch-fähigen) Metro-Apps, die sich in ihrem Verhalten und Aussehen durch das Metro-Design an Apps für Windows Phone anlehnen.

Dieser Artikel beschreibt das (vorläufige) Programmiermodell von Windows 8 und die Windows Runtime als wesentliche Komponente in diesem Zusammenhang.

Ein Bild und tausend Worte

Ein Bild, das auf der BUILD von Anfang an für Verwirrung sorgte, war das folgende Architektur-Schaubild, das bereits in der Keynote aufgelegt wurde.

Wie viele Diagramme abstrahiert das Bild zu sehr von der eigentlichen Realität, .NET ist nur als kleines Kästchen mit Silverlight in der rechten unteren Ecke zu sehen. Doch ist dem wirklich so?

Zwei Welten

Ein Sachverhalt wird aus dem Architektur-Schaubild deutlich: das Programmiermodell von Windows 8 bezieht 2 Welten mit ein. Zum einen ist da die Welt der klassischen Desktop-Applikationen (Desktop Apps). Diese werden wie bisher auf Basis von .NET bzw. der Win32-API umgesetzt. Zudem sind hier weiterhin RIA-Anwendungen auf Basis von Silverlight lauffähig. In dieser klassischen Welt bleibt also alles beim Alten und für den, der klassische Applikationen schreibt, gibt es keine Neuerungen im grundlegenden Modell.

Auf der anderen Seite ist da die Welt der neuen Metro-Apps (Metro style Apps), die für Touch optimiert (trotzdem noch per Maus bedienbar) auf der neuen Metro UI im Vollbild laufen. Eine wesentliche Neuerung ist hierbei die Windows Runtime (WinRT).

WinRT - nur eine Bibliothek?

Prinzipiell ist die Windows Runtime eine objektorientierte Ablösung der Win32 API und damit mehr als eine bloße Klassenbibliothek. WinRT wurde auf Basis einer weiterentwickelten Version von COM in C++ implementiert, ist in den Windows-Kern verwoben und stellt eine Schnittstelle zur Nutzung von Windows-Funktionalität aus Programmen heraus zur Verfügung. Die WinRT APIs sind damit klassische Betriebssystem-APIs. Sie sind grundsätzlich nicht an die Metro UI gebunden, stellen aber eine Voraussetzung für die Entwicklung von Metro-Apps dar. WinRT läuft dabei als native Runtime im Gegensatz z.B. zu .NET, das sich als managed Code Layer auf einer höheren Ebene befindet.

Metro-Apps auf Basis der Windows Runtime können in verschiedenen Sprachen entwickelt werden, wie auch das obige Architektur-Schaubild zeigt. Neben XAML/C# (Managed Code) und XAML/C++ (nativ) sowie DirectX/C++ handelt es sich dabei aktuell um HTML/JavaScript. WinRT stellt dabei die gemeinsame Basis dar. WinRT APIs können aus allen unterstützten Sprachen heraus direkt angesprochen und verwendet werden, Konzepte wie P/Invoke für den Aufruf von Win32-APIs entfallen. Generell gilt, dass das WinRT zugrundeliegende erneuerte COM viele Anleihen an .NET genommen hat. Dadurch sind Konzepte wie Delegates, Events, Collections, Generics etc. auch in WinRT verfügbar. Somit können die WinRT-Datentypen und -Konzepte über einen schlanken Wrapper (Language Projection) auf die jeweilige Sprache gemappt werden, ohne großen Overhead zu erzeugen.

Das folgende Schaubild beschreibt die Laufzeit-Architektur der Windows Runtime und enthält neben der angesprochenen Language Projection auch die großen API-Blöcke von WinRT:

Weiterhin ist erwähnenswert, dass WinRT-Komponenten zu einem hohen Grad asynchron sind. Alle Methoden, die potentiell länger als 50ms dauern, lassen sich nur asynchron aufrufen. Somit wird der Weg hin zu mehr Asynchronität fortgesetzt, der von Microsoft vor allem mit der Einführung von Silverlight eingeschlagen wurde. Das erfordert natürlich ein gewisses Umdenken von Entwicklern, die eher synchrone Aufrufe gewöhnt sind. Andererseits machen es neue Konzepte in den unterstützten Sprachen wie z.B. async/await in C# 5.0 recht einfach, mit der erhöhten Asynchronität umzugehen.

Ausblick

Alles neu macht Windows 8 - zumindest wenn es um die Entwicklung von Metro-Apps geht. WinRT löst endlich die uralte Win32-API ab, das Programmiermodell hat das Potential, ein riesiges Ökosystem an Apps aufzubauen. Und im Gegensatz zu vielen Behauptungen kommt Microsoft hier keineswegs zu spät, sondern ist sogar Vorreiter, wenn man die Vereinigung von Desktop- und Tablet-Betriebssystem sowie die Entwicklung von Metro-Apps mit HTML5/JavaScript betrachtet.

Der nächste Artikel wird weiter auf WinRT eingehen, indem er die Auswirkungen auf das bisherige Entwickler-Ökosystem zeigt und zu klären versucht, welche Zukunft .NET und Silverlight beschert ist

Share |

BI 2008 Migration: Integration Services (2/3) 28.11.2011

Michael Beuss, Principal eXpert

Im zweiten Teil dieser Serie über die Migration von SQL Server 2005 Business Intelligence Anwendungen schauen wir uns an, wie Integration Services Pakete nach SSIS 2008 migriert werden können.

Microsoft selbst liefert ein detailliertes Dokument zur Migration nach SQL Server 2008, jedoch möchte ich in diesem Artikel weitere praktische Erfahrungen einfließen lassen.

Beim Öffnen eines Integration Services 2005 Projektes mit Visual Studio 2008 startet der Upgrade Wizard ganz automatisch und führt die Umwandlung in das neue Projekt- und Paket-Format durch. Im Hintergrund passiert jedoch viel mehr: Die verwendeten nativen Microsoft Komponentenreferenzen (Data Flow Task, Data Source u.a.) werden in Referenzen auf die neuen 2008er DLLs überführt. So weit, so gut. Doch was ist mit den selbst entwickelten Komponenten, den Custom Components?

Gerade hier leistet der Upgrade Wizard wertvolle Dienste. Damit dieser erkennt, welche neuen Komponenten den alten entsprechen, werden Mapping-Dateien ausgewertet, die diesen Zusammenhang definieren. Für jede Komponente stellt der Entwickler eine Datei beliebigen Namens zum Zeitpunkt der Migration bereit. Mapping-Dateien haben folgenden Aufbau:

   1: <?xml version="1.0" ?>

   2: <Mappings xmlns="http://www.microsoft.com/SqlServer/Dts/UpgradeMapping.xsd">

   3:     <ExtensionMapping

   4:         tag="$$Short Description$$"

   5:         

   6:         oldAssemblyStrongName="$$AssemblyName.ClassName$$, $$AssemblyName$$, Version=1.0.0.0, Culture=neutral, PublicKeyToken=$$Token$$"

   7:         

   8:         newAssemblyStrongName="$$AssemblyName.ClassName$$, $$AssemblyName$$, Version=2.0.0.0, Culture=neutral, PublicKeyToken=$$Token$$"

   9:     />

  10: </Mappings>

Die mit $$ umschlossenen Identifier müssen individuell angepasst werden. Befinden sich entsprechende Dateien im neuen SQL Server Unterverzeichnis DTS\Upgrade Mappings, so versucht der Upgrade Wizard alle Referenzen der alten Komponente (“oldAssemblyStrongName”) im SSIS Paket auf die neue zu aktualisieren. Und schon ist das Paket mit der neuen Komponente einsatzbereit. Ach ja: Die neue Komponente sollte natürlich auf dem Rechner vorhanden sein!

Ganz so komfortabel ist die Migration von Script Tasks manchmal jedoch nicht. Der Upgrade Wizard überführt den Script Code zwar in die neue Entwicklungsumgebung, kann jedoch inhaltlichen Anpassungsbedarf nicht erkennen. Dazu gehört beispielsweise die textuelle Verwendung des SQL Providernamens (neu SQLNCLI10) sowie Referenzen auf alte Libraries in Strings. Deshalb ist schon noch etwas Aufmerksamkeit gefragt um diese Probleme zu erkennen.

Gute Dienste leistet hierbei der Upgrade Advisor. Dieses Tool untersucht alle Pakete in einem ausgewählten Verzeichnis und zeigt als Analyseergebnis u.a. die verwendeten Script Tasks an. Diese Ergebnisliste ist manuell abzuarbeiten und damit jedes Skript auf mögliche Probleme zu untersuchen.

Abschließend noch ein Tipp: Verwenden Sie keine SSIS-Pakete mit Punkten im Dateinamen. Der Upgrade Advisor schneidet nämlich den Namen des Ergebnispaketes sofort nach dem ersten Punkt ab. Pakete mit gleichem Namensraum-Benennungsschema würden sich gegenseitig überschreiben und das Ergebnis der Migration unbrauchbar machen.

Beherzigen Sie jedoch die erwähnten Hinweise, sollte einer erfolgreichen Paketmigration nichts mehr im Wege stehen.

Share |

BI 2008 Migration: Analysis Services (1/3) 25.11.2011

Michael Beuss, Principal eXpert

Keine Frage – SQL Server 2008 spielt mit in der obersten Liga der Datenbanksysteme. Im Gegensatz zu anderen Anbietern integriert Microsoft Business Intelligence Komponenten mit in das Produktrelease des Datenbanksystems. Diese Marktstrategie trug dazu bei, dass MS Produkte mit zu den Marktführern im BI Bereich gehören.

Viele Firmen entwickelten ihre BI-Anwendungen mit SQL Server 2005 und möchten nun auf die seit 2010 verfügbare Version 2008 R2 migrieren. In dieser dreiteiligen Artikelserie möchte ich über meine Erfahrungen mit verschiedenen Lösungsansätzen der Migration von BI-Anwendungen von SQL Server 2005 nach 2008 R2 berichten. Eine sehr detaillierte Beschreibung liefert Microsoft selbst im Technical Upgrade Guide. Von praktischer Bedeutung ist insbesondere die dort beschriebene Side-By-Side Migration auf neue Server.

Die Überführung existierender SQL Server 2005 Datenbanken nach 2008 gelingt erstaunlich problemlos. Man kann sowohl ein mit dem SQL Management Studio 2005 (SSMS) erstelltes Backup mit SSMS 2008 über Restore als Datenbank verfügbar machen als auch aus einem Backup aus SSMS 2008. Auch Datenbank Setup-Skripte der Version 2005 laufen problemlos auf SQL Server 2008.

Bei Analysis Services gibt es ebenfalls zwei Migrationsstrategien. Zum einen kann die AS-Datenbank über Deployment Skripte im XMLA Format in der Zielumgebung neu erzeugt werden. Dann muss ein Reprocessing erfolgen, um die AS DB mit Daten aus der relationalen DB zu befüllen. Der zweite Ansatz überträgt die AS DB mit Backup/Restore auf die Zielumgebung. Beide Strategien verlaufen normalerweise problemlos. Doch Achtung: Microsoft hat die Verbindungsprovider umgestellt. Für SQL Verbindungen ist dieser nun SQLNCLI10, für OLAP-Verbindungen MSOLAP.4. Dies ist in den ConnectionStrings in den Data Sources der AS DB bzw. im Deployment Skript zu überprüfen und gegebenenfalls zu editieren.

Die Migrationsstrategie mit Backup/Restore der AS DB bringt Zeitvorteile gegenüber dem Ansatz des neu Erstellens/Reprocessing. Beim Backup wird die AS DB nämlich mindestens 50% komprimiert. Der Vorteil kommt insbesondere in produktiven Umgebungen zum Tragen, wenn ein zuverlässiges Filecopy-Tool verwendet wird um die AS DB auf den neuen Server zu kopieren.

Auf der anderen Seite kann mit einem neuen Deployment und Reprocessing auch ein neues Release verknüpft werden. Läßt sich der mit dem Reprocessing verbundene Zeitbedarf produktiv planen, ist diese Migrationsstrategie flexibler.

Bei einem Migrationsprojekt sind diese und andere Aspekte vorher zu diskutieren und auch Zeitmessungen bei Testmigrationen durchzuführen. Die SDX AG kann Sie hierzu kompetent beraten und die optimale Strategie für Ihre Umgebung ausarbeiten.

Share |

Windows 8: "SDX News" Metro-App

Matthias Jauernig, Senior eXpert

Um erste Erfahrungen bei der Entwicklung von Apps für die Metro-UI (nachfolgend Metro-Apps genannt) von Windows 8 zu sammeln, habe ich nach einem abgegrenzten und leicht zu verwendenden Szenario gesucht, das gut mit den vorgegebenen Visual-Studio-Templates umsetzbar ist.

Meine Wahl fiel dabei auf die aufbereitete Darstellung der hier vorhandenen Blogbeiträge des SDX Flurfunks. Dieser Artikel gibt eine kurze Übersicht über die finale Windows-8-App.

First things first - der technische Rahmen

Um erste Erfahrungen mit beiden Programmiermodellen zu sammeln, wurde die “SDX News”-App von mir zweifach entwickelt: einmal mit XAML/C#, das zweite Mal mit HTML/JavaScript. Auf Charakteristika, Vor- und Nachteile beider Modelle werde ich in kommenden Blogbeiträgen noch eingehen. Die in diesem Beitrag gezeigte Variante entspricht der HTML/JS-Version.

Entwickelt wurden die Anwendungen auf Basis der Developer Preview von Windows 8 mit der darin enthaltenen Preview von Visual Studio 11. VS11 (Codename) kommt mit vorgefertigten Projekt-Templates für Metro-Apps daher, die sich einfach nutzen lassen und bereits einen sinnvollen Rahmen für die eigene App liefern, der angepasst und mit Leben gefüllt werden kann.

Wird die Metro-App aus Visual Studio heraus gestartet, so lädt sie automatisch auf der Metro-UI und wird per Vollbild dargestellt. Zur Anzeige der Blogbeiträge wird der RSS-Feed des SDX Flurfunks abgerufen, dessen Inhalte ausgewertet und aufbereitet dargestellt werden.

Gruppierte Übersicht auf der Startseite

Nach dem Start der App gelangt man auf die Startseite, die eine nach Monat gruppierte Ansicht der Flurfunk-Beiträge beinhaltet. Mit einer Wischgeste nach links bzw. rechts gelangt man zu älteren Blogbeiträgen, die Darstellung ist dabei sehr flüssig und die App intuitiv bedienbar. Wird statt dem eigenen Finger eine Maus verwendet, so blendet sich automatisch eine Scrollleiste am unteren Bildschirmrand ein, die per Maus bedient werden kann. Leider wird im Gegensatz zum Metro-Startscreen in eigenen Apps aktuell noch kein Mausrad unterstützt, was sicher auf die frühe Version von Windows 8 zurückzuführen ist und zukünftig kein Thema mehr sein sollte.

Touch-first in der Detailansicht

Wird auf ein Element geklickt/getippt, so öffnet sich mit einer kleinen Animation die Detailansicht des zugehörigen Blogbeitrags. In dieser kann wieder per Touch gescrollt werden, wenn der Inhalt die Grenzen einer Bildschirmseite übersteigt. Zudem wird wiederum ein Scrollbalken angezeigt, sobald die Bewegung einer Maus erkannt wird. Die Anwendung ist damit optimal per Touch verwendbar, kann aber trotzdem noch mit einer Maus bedient werden.

Quer- und Hochformat

Ändert sich die Ausrichtung des Bildschirms (explizit vom Nutzer oder implizit durch einen Sensor) und es wird vom Quer- in das Hochformat gewechselt, so bieten das Programmiermodell und die Standard-Controls von Windows 8 Möglichkeiten an, darauf zu reagieren bzw. Inhalte entsprechend angepasst darzustellen. Dies stellt natürlich auch zusätzliche Herausforderungen an App-Entwickler, die aufgrund der Vollbild-Ausführung einer Metro-App sowohl auf beliebige Auflösungen ab 1.024 x 768px als auch auf einen Wechsel der Orientierung reagieren müssen. Die SDX-News-App verwendet Standard-Controls, die sich automatisch optimal anpassen.

Side by Side mit anderen Programmen

Eine interessante Möglichkeit von Metro-Apps unter Windows 8 ist es, dass sie ab einer Bildschirmbreite von 1.366px mit einem anderen Programm parallel Seite an Seite angezeigt werden können. Ein Programm nimmt dabei den Hauptteil des Bildschirms ein, das andere läuft in einer schmaleren seitlichen Spalte. Interessant und nützlich ist das z.B. bei einem Twitter-Client, der als App an der Seite angeheftet wird. Bei Klick auf einen Link in einem Tweet könnte dieser dann in einem Browser als Haupt-Anwendung angezeigt werden, ohne den Kontext der eigentlichen Twitter-App verlassen zu müssen. Hier sind weitere Beispiele denkbar, z.B. ein Video, das im Hauptbereich neben einem Chat-Client im Seitenbereich läuft, etc..

Wichtig ist, dass wie beim Wechsel der Orientierung in einer Metro-App auf das Anheften der App an die Seite (“Snapped” State) reagiert werden kann. Inhalte können dann anders dargestellt werden, so dass sie sich optimal im Seitenbereich nutzen lassen.

Ausblick

Dieser Artikel hat einen ersten Einblick der Funktionalität der umgesetzten “SDX News”-Metro-App gewährt. Die bestehenden Visual-Studio-Templates machten die Implementierung recht einfach, von einigen Bugs der Developer Preview abgesehen. Trotzdem konnte mit vorhandenem Wissen in XAML/C# bzw. HTML/JS die App schnell umgesetzt werden und dennoch bietet sie bereits eine gute Funktionalität, wenn man das Reagieren auf die Änderung der Orientierung bzw. das Anheften an die Seite berücksichtigt. In nachfolgenden Blogbeiträgen wird darauf detaillierter eingegangen.

Share |

Microsoft BI bald mit Touch (iPad, Android, Windows 8...) 23.11.2011

Nicolas Meseth, Senior eXpert

Auf dem PASS Summit hat Microsoft seine Roadmap für BI auf mobilen Endgeräten preisgegeben. Dabei wurden ein paar sehr interessante Dinge für 2012 angekündigt.

Ich möchte ich kurz die Roadmap, wie Microsoft sie verkündet hat, zusammenfassen. Was dürfen wir 2012 erwarten? Microsoft unterteilt die Map in drei Phasen. Die erste soll mit dem ersten Halbjahr 2012 abgeschlossen sein und als Ergebnis im Wesentlichen die Unterstützung der SharePoint BI Inhalte wie Excel Services, PerformancePoint oder SSRS Reports auch in "feindlichen" Browsern (die Formulierung stammt von mir, nicht von MS) wie Safari oder Chrome mit sich bringen.

Die Unterstützung für Apples und Googles Browser stellt die Voraussetzung für die zweite Phase dar, die grob für das 2. Halbjahr 2012 terminiert wurde. Jetzt sollen für Touch optimierte User-Experiences mit den genannten Technologien auf unterschiedlichen Endgeräten wie iPad, iPhone, Android Tablets und Phones sowie WP7 bereitgestellt werden. Auf der PASS wurden erste Demos diesbezüglich bereits gezeigt.

Die dritte Phase, für die keine konkrete Zeit genannt wurde, die aber wohl dann Ende 2012 oder Anfang 2013 erwartet werden dürfte, fokussiert sich dann auf die Bereitstellung von BI Inhalten auf Windows 8 Geräten. Hier dürfen wir besonders gespannt sein.

Was hat das alles mit Denali bzw. SQL Server 2012 zu tun? Nichts, denn Microsoft weist ausdrücklich darauf hin, dass alle drei Phasen nichts mit dem Launch des SQL Server 2012 zu tun hat. Eine zeitliche Übereinstimmung ist rein zufällig.

Wer es nicht erwarten kann jetzt schon sein iPad für seine Reports zu verwenden, der kann mit Drittanbietertools bereits heute schon erste Lösungen ausprobieren oder produktiv nutzen. Eine Liste, die auch hier zu finden ist:

• Decision Support Panel
• RoamBI
• Extended Results
• Install Free
• MobiWeave

Share |

Erste Deutsche Microsoft SQL Server Konferenz im Februar 2012 21.11.2011

Viktor Ewert, Senior eXpert

Am 27. und 28. Februar 2012 findet die erste Deutsche Microsoft SQL Server Konferenz mit dem Titel “Microsoft SQL Server 2012 Launch auf der ersten Deutschen Microsoft SQL Server Konferenz” statt. Inhaltliche geht es um die Vorstellung der neuen Features des SQL Server.

Ob man aus dem Titel darauf schließen kann, dass der SQL Server 2012 zu dem Zeitpunkt released wird, darüber darf spekuliert werden. Offizielle Aussage von Microsoft ist: “Erstes Halbjahr 2012”.

Mehr Infos:
http://www.microsoft.com/de-de/server/sql/launch-event.aspx
http://www.event-team.com/events/SQL2012/Agenda.aspx

Share |

Windows 8: Erste Eindrücke 16.11.2011

Matthias Jauernig, Senior eXpert

Viel war spekuliert worden, als Microsoft im Juni 2011 auf der Computex-Konferenz einen ersten Blick auf das neue Windows 8 gewährt hat. Programmiert jetzt alle Welt nur noch HTML5 / JavaScript? Ist Silverlight (schon wieder) tot? Und werden Geräte mit Windows 8 mit Android- und iOS-Devices konkurrieren können?

Auf der BUILD-Konferenz im September beantwortete Microsoft einige dieser Fragen, andere blieben offen. Zeit, sich die Vorabversion von Windows 8 anzuschauen und hier anhand einiger Blogbeiträge etwas Licht ins Dunkel zu bringen.

Erster Eindruck

Zum Kennenlernen von Windows 8 hat mir die SDX ein Dell Inspiron Duo bereitgestellt. Dabei handelt es sich um einen Convertible, der sowohl als Netbook als auch (durch Herumklappen des Bildschirms) als Tablet verwendet werden kann. Gerade dass es auch als klassisches Netbook verwendet werden kann und dabei von den Leistungsmerkmalen (Dual Core, 2 GB RAM) trotzdem zufriedenstellend ist, war mir wichtig – schließlich sollten auch erste Apps mit Visual Studio darauf entwickelt werden können. Der Preis für das Inspiron Duo liegt aktuell bei günstigen 399€.

Die von Microsoft veröffentlichte Developer Preview von Windows 8 ist eine erste Vorabversion, die kostenlos heruntergeladen und installiert werden kann. Wichtig ist dabei wirklich das Attribut “Preview”, das leider zu oft in den aktuellen Diskussionen übersehen wird. Windows 8 ist damit noch nicht einmal in einer Beta-Phase, viele Features fehlen noch, sehr viele Dinge werden sich noch ändern. Ziel von Microsoft mit der Preview ist es, vorrangig Entwicklern einen ersten Eindruck des neuen Systems zu vermitteln und sie erste Erfahrungen mit dem Programmiermodell von Windows 8 sammeln zu lassen.

Die Preview von Windows 8 ist schnell und unkompliziert installiert. Schon bei der Installation und beim ersten Start zeigen sich dabei große Unterschiede zu altbekannten Windows-Systemen. Nicht mehr der Desktop steht jetzt im Vordergrund, sondern ein Startscreen, der eine Art Kachel-Ansicht (Tiles) darstellt, die in einer anderen Form bereits von Windows Phone bekannt sind. Tiles sind nicht nur Icons, um Programme zu starten. Sie können auch Informationen einer App darstellen, selbst wenn diese nicht läuft. Beispiele hierfür sind ein Aktien-Ticker oder Wetter-Informationen, die direkt auf dem Tile angezeigt werden.

Auf dem neuen Startscreen und auch an vielen anderen Stellen wird die neue Metro-UI von Microsoft sichtbar, die ebenfalls von Windows Phone entlehnt ist. Metro-Anwendungen werden ausschließlich über den Startscreen gestartet, sie laufen Vollbild und sind primär per Touch bedienbar. Das Konzept wirkt stimmig, die als Beispiele gelieferten Metro-Apps laufen schnell, flüssig und sind auf dem Testgerät per Touch hervorragend zu bedienen.

Zwei in einem

Naturgemäß fehlen noch die Apps, um wirklichen Sinn aus Windows 8 auf einem Tablet machen zu können. Es kann aber schon jetzt gesagt werden, dass die neue Metro-UI optimal für Tablets ist und iOS/Android einige Dinge Voraus hat.

Doch Microsoft würde kein Windows liefern, ohne auch an die “klassischen” Windows-Benutzer zu denken. Und so bringt Windows 8 neben der neuen Metro-UI auch noch den klassischen Desktop mit, der aber mehr oder weniger wie eine normale App über den neuen Startscreen gestartet wird. Der Desktop kommt dabei mit einigen Verbesserungen daher: neuer Task Manager, neuer Kopierdialog für Dateien, Ribbons im Explorer, Fähigkeit zum Mounten von virtuellen Images etc.. Am Auffallendsten ist der neue “Start”-Button, der zurück zum Startscreen führt. Es gibt viele kontroverse Diskussionen über diese Funktionalität. Fakt ist: der neue Startscreen ist als Launcher für klassische Desktop-Programme und Metro-Apps und als Ablösung des alten Startmenüs zu sehen und Microsoft hat gute Gründe dafür. Es bedarf allerdings einiger Zeit, sich an diese Funktionalität zu gewöhnen und selbst dann hat auch das alte Startmenü mit seiner flexiblen Gestaltung viel Charme. Doch Microsoft hat bereits auf Kritik reagiert und einige Unzulänglichkeiten des neuen Startscreens ausgemerzt.

Touch oder Maus?

In der Developer Preview wird ein Punkt offensichtlich: die 2 Welten Metro-UI und klassischer Desktop bedingen aktuell auch 2 Bedienkonzepte. Die Metro-UI ist wunderbar per Touchscreen zu bedienen, alles läuft flüssig und es macht Spaß, sich durch die Apps zu bewegen. Ein tolles System für Tablet-Devices! Doch per Maus ist es aktuell noch nicht wirklich gut bedienbar. “Touch-first” bedeutet zwar, dass sich die Metro-UI auch per Tastatur/Maus bedienen lässt, doch momentan macht es damit einfach keinen Spaß, zu eingeschränkt ist die Nutzerfreundlichkeit. Doch es heißt abwarten: Microsoft hat klar gesagt, dass die aktuelle Preview-Version primär auf Touch optimiert ist, die Bedienung per Maus wird noch in den Fokus rücken und entsprechend wird die Metro-UI angepasst werden. Man darf gespannt sein.

Auf der anderen Seite ist der klassische Desktop kaum/nicht per Touch zu bedienen. Das wurde bereits bei Windows 7 klar, das nicht für Touch geeignet ist und war ein Grund, warum Microsoft den radikalen Schritt der Metro-UI bei Windows 8 gegangen ist. Kleine Buttons zu treffen und Menüs zu öffnen macht mit dem Finger keinen Spaß, daran wird sich nichts ändern. Dafür ist der klassische Desktop allerdings für die Bedienung mit der Maus optimal geeignet.

Blick in die Glaskugel

Microsoft treibt mit Windows 8 ein recht riskantes Spiel. Sie versuchen als erster Anbieter den Spagat, ein Betriebssystem zu liefern, das sowohl für den klassischen Desktop-Benutzer und damit Geräte wie Notebooks, Netbooks und Desktop-PCs geeignet ist als auch für Tablets, die aktuellen Tablet Devices mit iOS (iPad) und Android in nichts nachstehen. Auf der einen Seite dürfen sie dabei Nutzer ohne Touchscreen und Business-Anwender nicht verschrecken, auf der anderen Seite muss das System per Touch flüssig und einfach bedienen lassen.

Mein Dell Inspiron Duo ist ein Convertible und damit optimal geeignet, um sowohl mit dem klassischen Desktop als auch mit dem Metro UI interagieren zu können. Mir erscheint das aktuell als perfekte Form, um das Beste aus beiden Welten herausholen zu können. Und solange noch keine/wenige Metro-Apps verfügbar sind, macht es auch keinen Sinn, ein “reines” Windows-8-Tablet ohne Maus/Tastatur zu benutzen. Convertibles sind damit augenscheinlich die beste Möglichkeit, professionelle Nutzer von Windows 8 zu überzeugen. Sie können damit alle ihrer altbekannten Desktop-Applikationen verwenden, zudem kommen sie in den Genuss der neuen Metro-Apps, die sie per Touch bedienen können. Doch die Zeiten werden sich ändern. Gerade für Couch-Surfer und Consumer wird der klassische Desktop immer mehr an Bedeutung verlieren und mit steigender Anzahl an Metro-Apps werden Tablets interessant, die wie ein iPad leicht, leistungsfähig, lange lauffähig und stylisch daherkommen. Windows 8 bietet dafür die besten Voraussetzungen.

Erstes Fazit

Auch wenn es sich noch um eine Preview-Version handelt, kann ich sagen: Windows 8 macht Spaß, gerade wenn man ein Convertible besitzt. Das System ist flüssig, ressourcenschonend, fährt schnell hoch und lässt sich angenehm bedienen. Wird Windows 8 gegen iOS/Android ankommen können? Mit Sicherheit! iPad und Android haben zwar bereits einen Vorsprung im Tablet-Markt, den viele als groß bezeichnen. Allerdings darf man nicht vergessen, dass der Marktanteil von iOS und Android als Betriebssysteme bei gerade einmal 3,38% (iOS) bzw. 1,3% (Android) liegt, der von Windows (XP+Vista+7) liegt bei 77,69% (laut Statistik, 08/2011). Windows 8 hat damit schon aufgrund der Windows-Benutzerbasis ein großes Potenzial, mit hoher Durchschlagskraft den Tablet-Markt aufzumischen.

Einen Vorteil hat Apple mit iOS jedoch zumindest gegenüber Windows 8: für das iPhone entwickelte Apps sind i.d.R. auch auf dem iPad lauffähig, was in einer großen Anzahl hochwertiger Apps für die iOS-Plattform resultiert. Anwendungen für Windows Phone werden aller Voraussicht nach nicht auf Windows 8 lauffähig sein, da sich das grundlegende Programmiermodell stark unterscheidet (dazu mehr in einem kommenden Blogbeitrag). Ich bin gespannt, ob/wann Microsoft die Programmiermodelle von Windows Phone und Windows (Metro-UI) angleichen wird. Auf der anderen Seite hat Microsoft aber auch einen Vorteil gegenüber Apple/iOS: die riesige Anzahl bestehender klassischer Windows-Anwendungen wird auch unter Windows 8 lauffähig sein, eine Trennung zwischen Desktop- und Tablet-Betriebssystem (vgl. Mac OS und iOS bei Apple) gibt es nicht. Ob das wirklich ein Vorteil ist oder der Spagat misslingt, wird sich noch zeigen.

Als Fazit ist festzuhalten, dass Microsoft mit Windows 8 ein System mit viel Potenzial entwickelt, welches nur noch ausgespielt werden muss. Nach der Developer Preview wird als nächstes wohl eine Beta-Version erscheinen, mit der finalen Version von Windows 8 ist im Herbst 2012 zu rechnen. Schlussendlich hängt der Erfolg davon ab, ob es Microsoft mit Windows 8 gelingt, die Nutzer von dem Hybrid-Ansatz Desktop/Metro-UI zu überzeugen. Gerade im Businessbereich könnte das schwierig werden, doch zur Business-Story von Windows 8 hat Microsoft bisher noch kaum etwas verlauten lassen, daher heißt es abwarten. Im Consumerbereich werden sich vor allem Benutzer mit Touchscreen auf Windows 8 freuen, bei Tablets wird es hier von der Hardware abhängig sein, ob man sich für iPad/Android-Tablet oder Win8-Tablet entscheidet. Die Vorfreude auf die ersten Windows-8-Geräte ist bei mir zumindest sehr groß.

Share |

SQL Server 2012 als BI Edition 14.11.2011

Nicolas Meseth, Senior eXpert

Den SQL Server 2012, früher Codename "Denali", wird es in 3 unterschiedlichen Editionen geben. Dass dies eine Vereinfachung zu dem bisherigen Modell darstellt muss nicht extra erwähnt werden. Neu und besonders erfreulich für alle BIler ist die Business Intelligence Edition. Damit können nun beispielsweise die Analysis Services mit dem vollen Feature-Umfang genutzt werden und es bedarf dafür nicht mehr einer Enterprise Edition. Unverständlich ist allerdings warum eines DER BI Features, nämlich der neue Column-Index, nur mit einer Enterprise Edition verwendet werden kann ?! Naja, nicht ganz unverständlich, schließlich will Microsoft ja gute Argumente für die Enterprise Edition haben. Aus Sicht eines kleinen oder mittleren Unternehmen, das trotzdem die Spaltenindexe mit der BI Edition nutzen möchte, ist das aber sehr ärgerlich. Es anzunehmen, dass Microsoft mit der Enterprise Edition klar in Richtung der großen Unternehmen zielt, und besonders hier wird der Column-Index interessant. Kleinere und mittlere Unternehmen sind dann eventuell mit der BI Edition schon sehr gut bedient.

Neu ist auch die Option, die Standard- und Enterprise Edition jetzt Core-basiert zu lizenzieren. Damit antwortet Microsoft auf die vielfache Nachfrage am Markt. Mehr dazu ist hier nachzulesen!

Ich freu mich auf den SQL Server 2012!

Share |

SharePoint 2010 Workflows mit Nintex Workflow 2010 11.11.2011

Torben Mahr, Senior eXpert

In einer früheren Flurfunk Artikelserie hatte sich unser Chief eXpert Matthias Strasser mit der Workflowentwicklung für SharePoint 2010 in Visual Studio beschäftigt.

Der heutige Beitrag gibt einen kurzen Einblick in eines der bekanntesten und erfolgreichsten 3rd Party Tools für SharePoint, den Nintex Workflows in der Version 2010.

Allgemein

Ähnlich wie beim Microsoft On-Board-Tool SharePoint Designer 2010 ist es hier auch für Nicht-Entwickler und Power-User möglich, Workflows bis zu einem gewissen Komplexitätsgrad selbst und einfach zu erstellen, ohne hierfür Entwicklungswerkzeuge wie Microsoft Visual Studio 2010 einsetzen zu müssen. Ein weiterer Pluspunkt gegenüber dem Microsoft SharePoint Designer 2010 ist die Möglichkeit, State-Machine-Workflows zu erstellen. State-Machine-Workflows sind zustandsgesteuerte Workflows, die im Gegensatz zu sequentiellen Workflows ihren Zustand ändern können. Somit reagieren State-Machine-Workflows auf bestimmte Ereignisse, während die einzelnen Schritte bei einem sequentiellen Workflow lediglich nacheinander ablaufen.

Anders als der SharePoint Designer, der als separate lokale Installation auf dem Rechner vorhanden sein muss (Download des SharePoint Designers 2010 64-bit oder 32-bit), integriert sich Nintex Workflow 2010 vollständig in die SharePoint Benutzeroberfläche, sodass kein separater Client benötigt wird. Auch hier kommt die von SharePoint 2010 und Office 2010 bereits bekannte Ribbon-Oberfläche zum Einsatz, sodass die Benutzer eine gewohnte Umgebung antreffen, in der sie sich schnell zurechtfinden.

Nintex Workflows 2010 Versionen

Die Nintex Workflow Suite ist in folgenden drei Editionen mit unterschiedlichem Funktionsumfang erhältlich:

1. Workgroup Edition
2. Standard Edition
3. Enterprise Edition

Diese Editionen unterschieden sich beispielsweise unter anderem in der Limitierung der Anzahl von unterstützen SharePoint Webseiten und in der Anbindungsmöglichkeit externer Systeme wie z.B. Microsoft Dynamics, Exchange oder BizTalk.

Eine niedrigere Produktversion kann jederzeit auf eine Höhere upgegraded werden, falls man zusätzliche Funktionen benötigen sollte. Durch die komplette Integration in den Microsoft SharePoint 2010 ist der Funktionsumfang natürlich auch von der jeweils eingesetzten SharePoint-Version abhängig.

Die Nintex-Enterprise Edition unterstützt alle vorhandenen Features und ist für große bis sehr große SharePoint Installationen geeignet. Die Herstellerwebsite gibt einen sehr guten Überblick, wann welche Version eingesetzt werden sollte (Nintex-Versionsvergleich).

 

Zusätzlich zu den beiden niedrigeren Editionen werden unter Nintex Workflow 2010 Enterprise unter anderem folgende Features geboten:

• Delegierung von Workflow-Aufgaben
• Workflow-Benachrichtigung per E-Mail, Instant Messenger oder SMS
• Geplante und zeitgesteuerte Workflows
• Workflow-Templates für Geschäftsprozesse wie z.B. Urlaubsanträge
• Lazy Approval System: Reaktion auf Workflows ohne Zugriff auf SharePoint Portal und von unterwegs

Einrichtung und Installation

Die Installation von Nintex Workflow 2010 ist einfach und geht problemlos vonstatten. Nachdem diese erfolgreich abgeschlossen ist, findet sich in der SharePoint Zentraladministration ein neuer Punkt namens “Nintex Workflow Management” unter welchem die komplette Konfiguration des Tools durchgeführt werden muss.

Hier muss zuallererst der Lizenzschlüssel importiert werden, der das Produkt freischaltet. Danach werden die notwendigen SharePoint Datenbanken erstellt, bevor Nintex Workflow 2010 benutzt werden kann. Außerdem ist die Angabe der SharePoint Web Application nötig.

Der folgende Screenshot zeigt die möglichen Konfigurationseinstellungen.

Im SharePoint Portal findet sich nach erfolgter Konfiguration unter den Website-Einstellungen ein neuer Eintrag “Nintex Workflow”. Hier können mit der entsprechenden Berechtigung weitere Konfigurationseinstellungen, wie z.B. die “LazyApproval settings” getätigt oder Benachrichtigungstemplates erstellt werden. Der folgende Screenshot zeigt hierbei die möglichen Optionen.

Die eigentlichen Workflows werden auch aus dem SharePoint Menü heraus designed. Wie im Beitrag an anderer Stelle schon angesprochen, integriert sich Nintex Workflow 2010 komplett in die gewohnte Microsoft SharePoint 2010 Umgebung. Der Anwender findet im “Site Actions”-Untermenü einen neuen “Nintex Workflow 2010”-Eintrag. Unter diesem ist es möglich, einen neuen Workflow zu starten oder ein Workflow Template anzulegen.

Workflowerstellung und -ausführung

Sobald ein neuer Workflow gestartet wird, öffnet sich ein neues Browserfenster, in welchem die einzelnen Workflowschritte und –tasks angelegt werden. Die möglichen Workflowaktionen sind hierbei in Kategorien nach ihrem Anwendungsgebiet unterteilt.

Die folgende Grafik zeigt einen einfachen (noch unkonfigurierten) Workflow zur Anlage eines Active Directory Users inkl. Gruppenzuordnung und Mailbenachrichtigung.

Fazit

Nintex Workflow 2010 wurde im Vergleich zu Nintex Workflow 2007 nochmals verbessert und ist eine sehr interessante Erweiterung des Microsoft SharePoint 2010, falls man nicht über die Entwicklungsressourcen für komplexere Workflows verfügt und der Microsoft SharePoint Designer 2010 nicht mehr ausreichend ist.

Durch die vollständige Integration in die SharePoint 2010 Umgebung wird es den Benutzern leicht gemacht, mit der Erstellung von Workflows zu starten und die bereits mitgelieferten Aktionen decken einen großen Teil der alltäglichen Anforderungen ab.

Die Möglichkeiten mit Nintex sind im Gegensatz zum SharePoint Designer ungleich größer. Dies hat natürlich auch seinen Preis und so ist die Enterprise Version von Nintex Workflow 2010 mit ca. 14.000 Euro nicht günstig. Wer aber viel mit Workflows arbeitet, jedoch nicht über interne oder externe Entwickler verfügt, sollte sich einmal mit dem Thema Nintex und deren Produkten auseinandersetzen.

Mit Nintex Live existiert nun auch eine Erweiterung mit der man SharePoint an cloud-basierte Dienste (z.B. Google, Twitter, Facebook etc.) anbinden kann. Den Zugang hierfür erhält man mit einer gültigen Nintex Workflow Software Assurance.

Share |

SDX Technical Council: Silverlight 5 mit Ausblick auf HTML5 und Windows 8 09.11.2011

Simone Franz, Marketing Manager

Herzlich laden wir Sie zum letzten Technical Council in diesem Jahr ein.
Im TC "Silverlight 5 mit Ausblick auf Windows 8 und HTML5" stellen wir Ihnen aktuellste Front-End-Technologien vor:

Thema: ”Silverlight 5 mit Ausblick auf Windows 8 Technologien”
Termin: Mittwoch, den 23. November 2011, 17:00 bei SDX
Zielgruppe: Techn. Projektleiter, Architekten, Lead Developer, Developer

17:00 Uhr:	Begrüßungskaffee
17:30-19:30 Uhr:	Silverlight für Business Applications Neuerungen von Silverlight 5 Abgrenzung zu ASP.NET/HTML5 Architekturen und MVVM-Pattern Silverlight für Windows Phone Ausblick: WinRT auf Windows 8
19:30 Uhr:	Abendessen mit Bier vom Fass und Wein

Im Bereich der Web-Technologien und für die mobile Plattform Windows Phone spielt Silverlight für Microsoft weiterhin eine strategische Rolle.

Silverlight 5 reichert die Plattform um weitere interessante Möglichkeiten an, mit denen Silverlight noch ausgereifter wird. Neben der Vorstellung der wichtigsten Neuerungen von Silverlight 5 wird insbesondere auf den Aufbau einer Silverlight-Applikation eingegangen und die Unterschiede zu anderen Technologien wie ASP.NET und HTML5 werden aufgezeigt.

Ein Ausblick auf die neue Plattform WinRT von Windows 8 und deren Möglichkeiten rundet dieses Technical Council ab.

Unsere eXperts Patric Schouler und Matthias Jauernig werden am Projekt "SDX Privatbilanz" die wichtigsten Aspekte einer LOB-Applikation mit Silverlight vorführen und die Möglichkeiten einer Windows 8 Metro-App auf einem Tablet PC aufzeigen

 

Genießen Sie das abschließende Herbstbuffet und unterhalten Sie sich in lockerer Atmosphäre mit den Teilnehmern und den SDX eXperts.

Das SDX Team freut sich über Ihr Kommen. Auf Wiedersehen im SDX Büro in der Borsigallee (Nähe Hessencenter).

Herzliche Grüße
Simone Franz

Die komplette Einladung bzw. die Teilnahmebedingungen erhalten Sie >hier<.

Share |

Migration von Sourcen nach TFS – Teil 2 Zeitlicher Ablauf 07.11.2011

Matthias Malsy, Principal eXpert

Eine Migration von Sourcen aus Visual Source Safe (VSS), Subversion, Clear Case o.a. nach TFS erfolgt nicht von einer Sekunde auf die andere. Es gibt eine Übergangsphase, in der für jeden Entwickler klar geregelt sein muss, auf welchem Source Verwaltungssystem und Branch jeweils entwickelt wird, wo Fehler behoben werden und wie die Bugfixes schlussendlich alle im TFS landen.

Im nachfolgenden werden für die Übergangsphase drei Varianten für die technische und zeitliche Branch-Migration beschrieben.

Durchführung – Nur Main-Branch

Die einfachste Möglichkeit eine Migration durchzuführen besteht im Übertrag der Sourcen des Main-Branches in den TFS Source Control. Am Tag der Migration wird die alte Source Code Verwaltung (in der Grafik mit SVN dargestellt) gesperrt und alle Sourcen in den TFS kopiert.

Nach Fertigstellung kann das Entwicklerteam in der neuen Umgebung weiterarbeiten. Zusätzlich müssen alle Systeme, die die Versionsverwaltung als Datenquelle benutzen, umgestellt werden. Primär spielt hier ein Nightly Build eine Rolle, der seine Sourcen ab sofort aus dem TFS ziehen muss. Des Weiteren können aber auch Excel, Text oder andere Datenquellen eingecheckt sein, die von Fachabteilungen oder Fremdsystemen genutzt werden. Am Tag der Umstellung müssen diese alle auf die neue Quelle zugreifen.

Durchführung – Migration von Branches

Verlässt man die Stufe ganz einfacher Softwareentwicklungsprojekte, so existieren einer oder mehrere Branches. Um den initialen Aufwand niedrig zu halten kann es sinnvoll sein, zeitlich entkoppelt einen Branch nach dem Anderen auf den TFS umzuziehen. Somit ergibt sich eine Übergangsphase in der beide Versionierungssystem aktive Branches beinhalten.

Hierdurch bekommt man die zusätzlich die Sicherheit, dass man den gerade aktuellen Produktions-Branch unangetastet lassen kann.

Für das nachfolgende Beispiel nutze ich die beliebte – da überschaubare – Strategie „Branch on Deployment“ (siehe [BranchPrimer]). Dabei wird für jedes Auslieferungs-Release ein eigener Branch erstellt. Bugfixes werden auf dem Release-Branch durchgeführt und nach Main gemerged.

Im ersten Schritt empfiehlt es sich, den Main-Branch nach TFS zu übertragen. Er bildet die Basis für zukünftige Releases. Der beste Zeitpunkt hierfür ist kurz nach einem durchgeführten Release. Im nachfolgenden Beispiel wurde für die Version 3.0 ein produktiver Branch erstellt. Kurz danach kann die Migration des Main-Branches (=> „Main Migration“) erfolgen.

Interessant wird der Zeitpunkt, an dem Fehlerbehebungen auf dem Produktions-Branch (hier auf SVN) durchgeführt werden. Spätestens am Tag des Deployment (=> „Prod Patch“) sollten diese auf den Main-Branch zurück geführt werden. Das ist aber gar nicht so leicht, da der Main-Branch in der Zwischenzeit auf dem TFS liegt und selber verändert worden sein kann. Ein automatisierter Merge ist somit nicht mehr möglich, da die Basisinformation für einen 3-Wege-Merge [3WayMerge] über die Toolgrenze nicht funktioniert.

Über einen Zwischenschritt kann man sich die Arbeit erleichtern. Zuerst wird ein automatisierter Merge (kleiner blauer Pfeil) auf den – eigentlich stillgelegten – SVN-Main-Branch durchgeführt. Das hierzu erstellte Änderungsprokoll nutzt man zur Qualitätssicherung des manuellen Merges (kleiner orangener Pfeil) in den TFS.

Ein nachfolgendes Release 4.0 mit eigenem Branch stellt dann kein Problem mehr dar (=> „Neuer Prod Branch“). Der „alte“ SVN Produktions-Branch wird beendet und ein neuer TFS Produktions-Branch eröffnet.

Welcher Leser hat’s gemerkt? Der angekündigte „niedrige initiale Aufwand“ ergibt sich daraus, dass faktisch nur der Main-Branch in das neue System überführt wird. Der Produktions-Branch verbleibt im alten System. Somit bietet sich diese Verfahren an, wenn nur wenige Produktions-Patches zu erwarten sind. Zudem muss man die Möglichkeit haben das alte und neue System über einen gewissen Zeitraum parallel zu betreiben.

Durchführung – Parallele Migration von Branches

Wird das alte Source Control System stillgelegt, so müssen alle relevanten Branches fast zeitgleich auf den TFS übertragen werden. Im Prinzip ist das eine recht einfach Aufgabe. Am Tag der Migration wird der Main-Branch erzeugt und alle bisherigen Main-Sourcen aus dem Altsystem kopiert und eingecheckt.

Als nächsten Schritt erzeugt man den TFS-Prod-Branch als Kind des Main-Branches. Wichtig ist dabei, dass alle Dateien im Basis-Branch vorhanden sind d.h. der Prod Branch darf erst dann erzeugt werden wenn alle Dateien von Main migriert und eingecheckt sind. Der Zeitpunkt der Branch-Erstellung definiert den Ausgangspunkt für spätere Merge-Operationen. Wird auf Basis eines leeren Main-Branch ein Prod-Branch erstellt, so werden alle kopierten Dateien als „Neu“ angesehen und es kommt später zu einer immensen Anzahl an Merge-Konflikten.

In der Konsequenz muss die Reihenfolge der Branch-Struktur des alten Source Control Systems eingehalten werden und Stück für Stück nachgezogen werden.

Fazit

Die Migration von Sourcen und Branches in den TFS will technisch und zeitlich gut geplant sein. Wenn es möglich ist, sollten nur die Informationen des alten Systems übernommen werden, die für die Weiterentwicklung unbedingt notwendig sind. Im günstigsten Falle werden allein die Sourcen von aktiven Branches benötigt.

Links

[BranchPrimer] Branching and Merging Primer
http://msdn.microsoft.com/en-us/library/aa730834%28VS.80%29.aspx

[3WayMerge] Three-Way Merge
http://en.wikipedia.org/wiki/Merge_%28revision_control%29#Three-way_merge

Share |

Deklarativer Ansatz mit Code-Attributen 04.11.2011

Sven Erik Matzen, Chief eXpert

Die Verwendung von Custom-Code-Attributen kann die Übersichtlichkeit von Quellcode durch kompaktere Schreibweise deutlich erhöhen und unübersichtliche Switch-Statements und die Verteilung von zusammen gehörigen Informationen über mehrere Dateien hinweg verhindern.

Der folgende Programm-Code zeigt exemplarisch, wie Informationen über Objekte häufig verarbeitet werden: das Property „Class“ der Instanz von „Device“ wird in Switch-Statements ausgewertet, um Meta-Informationen (Name, Beschreibung) des verwendeten Wertes auszugeben.

namespace SwitchSample
{
    using System;


    class Program
    {
        static void Main()
        {
            var device = new Device { Class = SwitchApproach.DeviceClass.WebServer };
            SwitchApproach.PrintDetails(device);
            Console.ReadLine();
        }
    }

    public class Device
    {
        public SwitchApproach.DeviceClass Class { get; set; }
    }

    public static class SwitchApproach
    {
        public static void PrintDetails(Device device)
        {
            Console.WriteLine(GetUserFriendlyName(device.Class));
            Console.WriteLine(GetDescription(device.Class));
        }

        public enum DeviceClass
        {
            WebServer,
            Switch,
            Router,
            AppServer,
            Client,
        }

        private static string GetDescription(DeviceClass device)
        {
            switch (device)
            {
                case DeviceClass.AppServer:
                    return "- server that is accessible from another server";
                case DeviceClass.Client:
                    return "- machine that might access other machines, 
                              but does not host any service";
                case DeviceClass.WebServer:
                    return "- server that is accessible via http";
                case DeviceClass.Router:
                    return "- ip-based packet routing device";
                default:
                    return "Some computing device";
            }
        }

        private static string GetUserFriendlyName(DeviceClass device)
        {
            switch (device)
            {
                case DeviceClass.WebServer:
                    return "Web-Server";
                case DeviceClass.Switch:
                    return "Network Switch";
                case DeviceClass.AppServer:
                    return "Application Server";
                case DeviceClass.Client:
                    return "End User Client";
                default:
                    return "Some computing device";
            }
        }
    }
}

Daran ist zunächst mal nichts falsches – wenn man von dem Problem absieht, dass für den „Switch“ kein Name und für den „Router“ keine Beschreibung vorhanden ist (bemerkt?). Solche Probleme sind schwierig zu erkennen, weil zusammengehörige Informationen (Name, Beschreibung, Definition der Enum) in verschiedene Programm-Abschnitte verteilt wurden – in Real-World-Szenarien sind das meinst auch noch verschiedene Klassen/Assemblies.

Eine Lösung des Problems wäre die Implementierung einer Basis-Klasse oder besser eines Interfaces (die Basisklasse hat den Nachteil, dass in C# nur von einer Klasse geerbt werden kann), welches die Informationen zur Verfügung stellt. Nachteile dieser Lösung sind, dass

1. dieses Interface statische Inhalte zurück liefert und in der Implementierung der Klasse viel Platz verbraucht (und somit die Lesbarkeit sinkt)
2. die Enum in eine Anzahl von Klassen zerfällt. Im Beispiel sind das 5 – in „Real World“-Szenarien dürfte die Anzahl aber stark steigen.

Der folgende Ansatz verwendet hingegen selbst definierte Code-Attribute, um die Informationen Name und Beschreibung direkt an die Enum-Mitglieder zu knüpfen:

namespace AttributeSample
{
    using System;
    using System.Linq;

    class Program
    {
        static void Main()
        {
            var device = new Device { Class = AttributeApproach.DeviceClass.WebServer };
            AttributeApproach.PrintDetails(device);
            Console.ReadLine();
        }
    }

    public class Device
    {
        public AttributeApproach.DeviceClass Class { get; set; }
    }

    public static class AttributeApproach
    {
        public static void PrintDetails(Device device)
        {
            Console.WriteLine(device.Class.GetAttrib<FriendlyNameAttribute>().Name);
            Console.WriteLine(device.Class.GetAttrib<DescriptionAttribute>().Description);
        }

        public enum DeviceClass
        {
            [FriendlyName(Name = "Web-Server")]
            [Description(Description = "- server that is accessible via http")]
            WebServer,

            [Description(Description = "- networking device for distributing 
                                          ethernet packages")]
            Switch,
            
            [FriendlyName(Name = "Nerwork Router")]
            Router,
            
            [FriendlyName(Name = "Application Server")]
            [Description(Description = "- server that is accessible from another server")]
            AppServer,
            
            [FriendlyName(Name = "EndUser Client")]
            [Description(Description = "- machine that might access other machines,
                                          but does not host any service")]
            Client,
        }
    }

    public static class Extension
    {
        public static TAttribute GetAttrib<TAttribute>(this Enum value)
            where TAttribute : Attribute, new()
        {
            var type = value.GetType();
            var fieldInfo = type.GetField(value.ToString());
            var attrib = fieldInfo.GetCustomAttributes(true)
                                  .OfType<TAttribute>().FirstOrDefault();
            return attrib ?? new TAttribute();
        }
    }

    public class FriendlyNameAttribute : Attribute
    {
        public string Name { get; set; }
    }

    public class DescriptionAttribute : Attribute
    {
        public string Description { get; set; }
    }
}

Die Zusatz-Informationen „Name“ und „Description“ werden hier durch zwei „Custom Attributes“ abgebildet, welche die Mitglieder der Enum DeviceClass deklarativ mit diesen Informationen erweitern. Das Suffix „Attribute“ der beiden Klassen entspricht der .Net-Konvention für Code-Attribute und muss bei der Verwendung der Attribute nicht mit angegeben werden.

Auf diese Art lässt sich das Fehlen von Informationen für einzelne Enum-Mitglieder deutlich einfacher erkennen, da selbst bei 10 Enum-Mitgliedern inkl. Attributen alle auf eine Bildschirmseite passen (bei 1080 Pixel vertikaler Auflösung und Standard-Schrift-Einstellungen). Durch den Einsatz einer Extension-Method ist auch das Abfragen des Attributs extrem einfach und intuitiv möglich.

Zusätzlich sinkt die zyklomatische Komplexität, so dass weniger Test-Fälle ausreichen, um den Code vollständig zu testen – das Vorhandensein eines entsprechenden Attributs an jedem Enum-Mitglied lässt sich in einer Test-Methode problemlos so implementieren, dass zusätzliche Mitglieder ohne Attribut einen Fehler auslösen:

[TestMethod]
public void EnsureAllMembersHaveFriendlyNameAttribute()
{
    var invalid =
        typeof(AttributeApproach.DeviceClass)
            .GetEnumValues()
            .Cast<Enum>()
            .Where(x => string.IsNullOrEmpty(x.GetAttrib<FriendlyNameAttribute>().Name));

    Assert.AreEqual(0, invalid.Count());
}

Der Code der Extension-Methode muss natürlich noch um NULL-Prüfung und ggf. Logging (falls das Attribut erwartet aber nicht gefunden wurde) erweitert werden – die Übersichtlichkeit des Codes nimmt aber trotzdem deutlich zu. Die Attribute sollten noch als „sealed“ gekennzeichnet und mit einem AttributeUsage-Attribut ausgestattet werden. Der Übersicht halber wurde in diesem Beispiel vollständig auf Kommentare verzichtet.

Auch diese Technik hat ihre Grenzen und speziellen Anwendungsfälle und der Einsatz von Attributen statt Interfaces muss sorgfältig abgewägt werden (Performance-Implikationen, KowHow im Projekt, was soll tatsächlich ausgedrückt werden), so dass der Gebrauch von Custom Attributes sicher nicht in jedem Fall angeraten ist. Eine Überlegung ist dieser Ansatz meiner Meinung nach aber auf jeden Fall wert. Er kann (richtig angewendet) die Testbarkeit und Eleganz des Codes, sowie die Produktivität stark erhöhen.

Share |

Migration von Sourcen nach TFS – Teil 1 Planung 02.11.2011

Matthias Malsy, Principal eXpert

Keinen Zweifel, mit seinem Engagement in „Application Lifecycle Management“ (ALM) hat Microsoft den Nerv der aktuellen Softwareentwicklung getroffen. Mit der integrierten Verwaltung von Anforderungen, Tests und Testprozesse, Fehlertracking , automatisiertem Build und versionierter Source Code Verwaltung im Team Foundation Server (TFS) erreicht Microsoft unterschiedlichste Programmiersprachen und Plattformen. Die Möglichkeiten sind enorm.

Doch vor Nutzung dieser (meist) schönen neuen Welt ist eine Menge Arbeit angesagt. In einem ersten Schritt steht in der Regel die Umstellung der Source Code Verwaltung an. Diese Aufgabe, die sich nach einem Copy-Paste-Job anhört, beherbergt einige Fallstrick die im Ablauf zu beachten sind.

Planung

Die spontane Antwort auf die Frage „Was soll migriert werden“ wird üblicherweise mit „Alles“ beantwortet. Das ist aber gar nicht so einfach und auch nicht unbedingt sinnvoll.

In der Regel existiert bereits eine Source Code Verwaltung auf Basis Visual Source Safe (VSS), Subversion, Clear Case o.a. Diese beinhalten nicht nur den Source Code, sondern auch wichtige Meta-Information wie:

• Branches
• Labels
• Kommentare
• Verknüpfungen
• Berechtigungen
• Dateiversionen und deren Delta-Informationen (Unterschiede zwischen zwei Versionen)

Diese Informationen lassen sich gar nicht - oder nur mit enormen Aufwand - verlustfrei zwischen den verschiedenen Herstellern migrieren. Zu unterschiedlich sind die internen Mechanismen der Systeme.

Wer führt die Migration durch?

Falls es nicht zufällig eine spezielle Task Force (d.h. eine eigenes Projektteam) für die Migration gibt, bleiben die Arbeiten der Migration am Softwareentwicklerteam hängen. Die Arbeiten hierzu müssen im Rahmen der üblichen Featureplanung zusätzlich untergebracht werden. In der Konsequenz bedeutet dies, dass die Migration nicht viel Zeit kosten darf.

Muss alles migriert werden?

Es hilft sich klar zu machen, dass eine Versionsverwaltung üblicherweise zwei Zwecken dient.

Zweck 1 hilft dem Team die aktuelle Tagesarbeit zu bewältigen. Es ermöglicht zeitgleich mit unterschiedlichen Branches und Versionen auf einem gemeinsamen Source-Stand zu arbeiten. Die verschiedenen Stände können kombiniert oder auch zurückgerollt werden.

Das Entwicklerteam benötigt nach einer TFS Migration für seine Tagesarbeit die aktuellen Branches und Versionen. Im Extremfall beschränkt sich das auf den aktuellen Main-Branch.

Zweck 2 besteht aus einer Revisionspflicht. Damit werden Nachweise geführt, wann welche Änderungen durchgeführt wurden. Für eine Revisionspflicht reicht es in der Regel ausschließlich die ausgelieferten Versionsstände zu betrachten. Die vielen kleinen Zwischenstände der Tagesarbeiten spielen nach Jahren keine Rolle mehr. Der Nachweis muss zudem nicht notwendigerweise im aktuellen Source System geführt werden. Hierzu gibt es durchaus Alternativen:

· Wichtige Label-Stände werden in Archive gezogen

· Check-In Kommentare werden pro Datei in PDF Reports ausgelagert

· Finale Stände von Branches werden in Archive gezogen

Wenn es die Lizenzgestaltung erlaubt, kann die alte Source Verwaltung auch im Read-Only Modus weiter betrieben werden, so dass das System für Revisionszwecke weiterhin zur Verfügung steht.

Wenn es mehr sein soll

Sollen viele Softwareprojekte umgestellt werden oder möglichst viele Metainformationen zu Branches, Labels, Check-Ins, Berechtigungen etc. aus dem Altsystem übernommen werden, wird Unterstützung durch Spezialisten nötig. Es empfiehlt sich hier dringend eine spezielle „Migration Task Force“ einzurichten. Diese hat dann die Aufgabe Tools für den automatisierten Übergang zu evaluieren und die Entwicklerprojekte in der Umstellung zu unterstützen und zu beraten.

Für die Umstellung von ClearCase gibt es ein umfangreiches White Paper [ClearCaseTfs], das Vorgehen und Toolunterstützung detailliert beschreibt.

Fazit und Vorschau auf Teil 2

In der Regel reicht es, die aktuellen Developer-Branches und Produktions-Branches zu migrieren. Für Revisionszwecke können alternative Archivierungsmethoden genutzt werden. Die Minimierung des Migrationsumfanges kommt dem Software-Entwicklerteam sehr entgegen, da sie in der Regel nicht viel Zeit bekommen eine TFS Migration durchzuführen.

Im zweiten Teil werde ich anhand dreier unterschiedlicher Beispiele aufzeigen, wie der zeitliche Ablauf einer Source-Migration für Branches vorgenommen werden kann.

Links

[MS_ALM] Application Lifecycle Management
http://www.microsoft.com/visualstudio/en-us/strategies/alm

[ClearCaseTfs] Migration ClearCase to Team Foundation Server
http://download.microsoft.com/download/9/2/3/923D72FB-0076-49B6-96C4-AAC1C255A60E/WhitePaper_Migration_ClearCase_to_TFS_V1.0.pdf

Share |