Nachdem ich einer vorhandenen Tabelle  einige Felder über den Table Designer hinzugefügt habe und diese Änderungen speichern wollte, habe ich folgende Meldung erhalten:

Verzeihung liebes Management Studio, Nein ich möchte nicht dass du die Tabelle löschst und sie mit der neuen Struktur Neu erstellst.

Da mir aber zu diesem Zeitpunkt wieder mal entfallen war, dass ich dieses Problem früher schon hatte, habe ich mich kurzerhand an meine Timeline in Twitter gewandt.

Dort habe ich prompt, wie fast immer,  die richtige Antwort erhalten.

Danke dafür an Sebastian und Norbert, bei den beiden Funktioniert das Gedächtnis wohl noch besser als bei mir.

Und damit ich in Zukunft selbst daran denke, und auch Uwe nachschauen kann wie man das Problem lösen kann, habe ich diesen Beitrag geschrieben.

Und hier nun die Lösung des Problems:

Man kann in den Optionen einstellen, ob das Management Studio diese Vorgehensweise “Warnung ausgeben und das Drop/Create Szenario” anstelle einer “Änderung der Tabellenstruktur”, verwenden soll (Siehe nachfolgende Abbildung).

Vielleicht hilft das hier nicht nur mir und Uwe

Meine Geschichte zu SugarSync

Vor einigen Wochen, eigentlich sind es schon Monate her, bin ich auf das Synchronisations Tool SugarSync aufmerksam geworden.

Dieses Tool stellt ähnliche Funktionalitäten wie die Dropbox oder Live Mesh zur Verfügung.

Da ich sowohl Dropbox als auch Live Mesh einsetze, und das nicht weil ich gerne mehrere Tools für ein und denselben Zweck einsetze, sondern weil jedes der Tools ein Alleinstellungsmerkmal hat, dass ich benötige musste ich beide verwenden.

Alleinstellungsmerkmal Dropbox (gegenüber Live Mesh)

Bei der Dropbox war das Alleinstellungsmerkmal die Möglichkeit “Public Links” erstellen zu können, die man einfach weiter geben kann, damit ein anderer sich die mit dem “Public Link” verknüpfte Datei herunterladen kann.

Alleinstellungsmerkmal Live Mesh (gegenüber Dropbox)

Bei Live Mesh, ist es die Möglichkeit beliebige Ordner aus dem Dateisystem in die Synchronisation aufzunehmen und mit beliebigen Ordner auf anderen Geräten synchronisieren zu können.

SugarSync Alleinstellungsmerkmal (gegenüber Live Mesh und Dropbox)

SugarSync, kann sowohl “Public Links” erstellen, als auch beliebige Ordner des Dateisystems synchronisieren. Damit würden meine beiden speziellen Anforderungen von einem Tool erfüllt werden und ich müsste nicht auf mehrere Tools zurückgreifen.

Nach der Installation – der erste Start

Nachdem ich also überzeugt war, dass ich durch SugarSync die beiden Produkte Live Mesh und Dropbox ersetzen zu können, habe ich SugarSync auf 4 Geräten installiert.

• 2 Geräte mit Windows 7 64 Bit
• 1 Gerät mit Windows 7 32 Bit
• 1 Gerät mit Windows XP 32 Bit

Auf 3 der 4 Geräte funktionierte alles wie erwartet, auf dem 4ten Gerät, das leider mein aktueller Entwicklungsrechner (Windows 7 64 Bit) war, trat das folgende Problem auf:

Der Versuch, nachdem der Rechner neu gestartet wurde, ein Windows Explorer Fenster zu öffnen führte dazu, dass dieses einfriert und nach einigen Sekunden abstürzt.

Neben dem Absturz des Explorer Fenster wurden auch einige Programme aus der Symbolleiste beendet:

Da ich mir nicht erklären konnte warum dieses Problem auftritt, ich aber sicher war, dass ich nicht der einzige sein kann, der dieses Problem hat, habe ich eine Mail an den Support geschrieben, und gehofft, der würde mir eine Antwort geben können.

Die Support Odyssee

Am 26.10.2011 habe ich dann eine ausführliche Beschreibung meines Problems per E-Mail an den Support gesendet.
Da SugarSync (sowohl das Produkt als auch die Webseite) auch auf Deutsch verfügbar ist, hatte ich ohne groß darüber nachzudenken, dass E-Mai in Deutsch geschrieben.

Am 01.11.2011 habe ich dann eine Nachricht vom Support erhalten (in Englisch), dass Sie das Ticket geschlossen haben, da ich mich nicht weiter gemeldet habe.

Am 02.11.2011 erhalte ich dann aber ein Mail vom Support, indem Sie mir erklären, dass ich doch bitte mein Problem in Englisch an sie senden soll, da der Support nur in English gegeben werden könnte.

Ich hatte in den folgenden Tagen wenig Zeit und habe mich daher erst wieder am 23.11.2011, nun in Englisch, an den Support gewendet und mein Problem in einer ausführlichen Mail beschrieben und darum gebeten mir mitzuteilen, wie man ein Error Logging einschalten könnte, damit ich mehr Informationen zu dem Problem liefern könnte.

Immerhin habe ich nun am gleichen Tag eine (automatisierte) Antwort bekommen, dass meine Mail angekommen sei und sich “ASAP” jemand um mein Problem kümmern würde.

Am 01.12.2011 (ist das ASAP) erhalte ich dann eine Mail, dass sie sich überhaupt nicht vorstellen können wie das Problem auftreten könnte, sie aber gerne mal Remote auf meinen Computer schauen würden um das Problem zu analysieren.

Ich habe dann kurz geantwortet, dass ich davon keinen Gebrauch machen möchte. Damit war klar ich werde das Problem selbst angehen, sobald ich etwas Zeit dafür habe.

Die Zeit war Reif für eine Analyse

Da ich SugarSync auf verschiedenen Rechnern installiert und das Problem in dieser Art nur auf einem Rechner aufgetreten ist, habe ich zuerst versucht die Besonderheit dieses Rechners zu ermitteln.

Hierbei habe ich festgestellt, dass ich einen Rechner mit exakt den gleichen installierten Programmen habe, auf dem das Problem nicht auftritt. Der einzige Unterschied, der Rechner auf dem es läuft ist ein 32 Bit Windows.

Also tritt das Problem vermutlich nur auf einem 64 Bit System auf.

Einer der installierten Rechner auf dem es läuft ist ein Windows 7 64 Bit Rechner. Dann vergleiche ich doch mal die darauf installierten Programme.

Bei Durchsicht der installierten Programme bekomme ich relativ schnell eine Ahnung woran das Problem liegen kann.

Auf dem Rechner mit dem Problem ist neben SugarSync auch TortoiseHg installiert, das ist auf dem anderen Windows 7 64 Bit Rechner nicht (mehr) installiert.

Ich möchte kurz erklären warum meine Vermutung relativ schnell in diese Richtung ging:

Das Stichwort lautet: Overlay Icons.

Sowohl TortoiseHg als auch SugarSync verwenden Overlay Icons um den Dateistatus im Windows Explorer darstellen zu können.

Wie sich nachfolgend herausstellen sollte, liegt tatsächlich das Problem an der Verwendung dieser Overlay Icons.

Die Lösung (vorübergehend auf jeden Fall)

Sowohl TortoiseHg als auch SugarSync bieten die Möglichkeit die Darstellung der Overlay Icons ein und ausschalten zu können.

Man kann eine der beiden Overlay Icon Anzeigen deaktivieren, und das Problem tritt nicht mehr auf. (Ich werde natürlich dieses Problem nun an SugarSync melden, damit sie das Problem aktiv angehen können, mal schauen ob und wann das dann geschieht)

Hier die Einstellungen die man ändern muss damit die beiden Produkte nebeneinander auf dem gleichen Rechner funktionieren.

Entweder dieses Option ausschalten (SugarSync):

Oder diese hier (TortoiseHg) ausschalten:

Und nun mal schauen ob der “Live Test” mit SugarSync meine Bedürfnisse ganz befriedigen kann und ich dann in naher Zukunft die beiden anderen Produkte ganz von meinen Rechnern entfernen kann.

Als .NET Entwickler bin ich es eigentlich gewohnt mit Visual Studio zu arbeiten. Auch wenn man nicht immer mit VS super zufrieden ist, kann man damit aber doch ganz ordentlich Entwickeln. daher war es mir  wichtig auch für diesen PHP Ausflug zuerst einmal eine “gescheite” Entwicklungsumgebung für dieses Projekt aufzubauen.

Da ich neben ReSharper (Visual Studio Plugin) bereits WebStorm (beides Erstklassige Produkte von JetBrains) einsetze war für mich sehr schnell klar, dass als PHP IDE PhpStorm vom gleichen Hersteller zum Einsatz kommen soll.

Unter einer “gescheiten” Entwicklungsumgebung verstehe ich ab er als minimale Anforderung:

• Einen guten Editor (IDE) (Am besten Syntax highlighting)
• Einen ordentlichen Debugger (Am besten in der IDE integriert)

Mit PhpStorm habe ich die “gute”  IDE bereits ausgewählt.

Das Problem des integrierten Debugger kann ich aber weder mir PhpStorm noch mit einer anderen mir bekannten Entwicklungsumgebung für PHP direkt und einfach lösen.

Um PHP zu debuggen gibt es eine Extension mit der Bezeichnung “Xdebug”,  die direkt zusammen mit PHP arbeitet und in der PHP.INI konfiguriert werden muss.

Und genau diese Konfiguration und Einrichtung ist mir als .NET Entwickler irgendwie nicht wirklich einfach von der Hand gegangen.

Die Konfiguration von Xdebug in PHP war noch recht einfach und auch ganz ordentlich dokumentiert. Wie man jedoch aus der IDE (PhpStorm) Breakpoints setzen und den Debugger nutzen kann, dass blieb zuerst ein Buch mit vielen Siegeln.

Über die Konfiguration von PHP und Xdebug auf einem IIS unter Verwendung von PhpStorm, gab es eigentlich keine oder nur unvollständige Anleitungen (oder ich habe sie einfach nicht gefunden).

Nun aber genug der Vorreden, ab hier geht es nun um die Beschreibung (Schritt für Schritt Anleitung) wie man auf einem Windows Rechner eine komplette Entwicklungsumgebung für PHP einrichten kann, mit der sogar ein .NET Entwickler etwas anfangen kann .

Systemumgebung, Programme, Voraussetzungen:

• Windows 2008 R2 Server (Windows 7 mit installiertem IIS würde auch funktionieren)
• WordPress (Oder jede andere PHP Anwendung wie z.B. Joomla)
• PhpStorm 3.X
• Xdebug (Debugger Tool für PHP)

Installation / Überprüfung IIS

Benötigt wird ein IIS 7 oder 7.5 (kein IIS Express).

Unter dem W2K8 geht das einfach indem man die Serverrolle Webserver (IIS) auswählt und installiert.

Es werden keine speziellen Rollendienste benötigt, also einfach nur auf Weiter und Installieren klicken bis die Installation abgeschlossen ist.

WordPress (und alle benötigten Komponenten installieren)

Der einfachste Weg um ein Produkt wie WordPress auf einem Windows Rechner zu installieren ist sicherlich die Verwendung des Web Plattform Installer (Der übrigens auch in WebMatrix integriert ist).

Der Web Plattform Installer stellt selbst fest welche Komponenten auf dem Rechner vorhanden sind und welche installiert werden müssen um das ausgewählte Produkt verwenden zu können.

Hier kann man dem Web Plattform Installer herunterladen

Also Web Plattform Installer herunterladen und aufrufen (installieren).

Nach der Initialisierung geben wir im Suchfeld “WordPress” ein und bestätigen die Eingabe mit der Enter Taste.

Nun wählen wir WordPress in der gewünschten Sprache aus und betätigen den Button hinzufügen.

Wenn man nun auf Installieren klickt werden die folgenden Tools und Produkte installiert.

Während der Installation müssen wir noch folgende Angaben machen:

Da ich eine Entwicklungsumgebung aufbauen möchte, werde ich MySQL auf dem lokalen Rechner installieren lassen. (Weiter klicken)

Nun bekommt man noch mal alle zu installierenden Produkte angezeigt und wird aufgefordert den Lizenzbedingungen zuzustimmen.

Jetzt muss noch ein root Passwort für die MySQL Installation angeben werden:

Beim Weiter Klicken, geht die Installation schon los.

Die Installation kann je nach Internet Geschwindigkeit unterschiedlich lange dauern, da während der Installation die aktuellen Pakete heruntergeladen und installiert werden.

Bei DSL 16000 und einem Rechner mit I7 Prozessor dauert die Gesamte Installation 3 – 5 Minuten.

Nächster Stop Webseite für WP konfigurieren:

Da ich WordPress nur in der Entwicklungsumgebung aufrufen und nicht von extern zugänglich machen möchte, lasse ich die Einstellungen wie vorgegeben. Das führt nach der Installation dazu, dass die Seite unter localhost/wordpress erreichbar sein wird.

Noch ein Stop Datenbank erstellen

Datenbank auswählen / erstellen und Root Passwort

Da wir MySQL gerade erst installiert haben, müssen wir natürlich eine Neue Datenbank erstellen.

Im Eingabefeld (roter Pfeil(, müssen wir das Root Passwort eingeben, dass wir während der Installation von MySQL vergeben haben.

Datenbankbenutzer / Passwort eingeben

Die Einträge mit den grünen Pfeilen müssen wir nicht anpassen.

In den Feldern mit den roten Pfeilen muss nun noch ein Kennwort für den Datenbank Benutzer eingegeben werden. Das muss nicht, kann aber das gleiche wie das Root Passwort sein (aber bitte nur auf lokalen Entwicklungssystemen, sonst sollten die Datenbank Passwort nicht dem Root Passwort entsprechen)

In allen weiteren Felder müssen keine Eingaben gemacht werden.

Damit sind nun WordPress und alle benötigten Tools und Programme installiert.

WordPress sollte nun schon funktionieren, also testen wir es mal.

Browser öffnen und localhost/wordpress eingeben.

Am besten geben wir gleich die notwendigen Daten für WP ein, so dass wir später direkt auf die Homepage von WordPress und nicht mehr auf die Admin Setup Seite geleitetet werden.

Beim nächsten Aufruf sollte das so aussehen:

Xdebug installieren

Nun müssen wir die Xdebug Extension installieren.

Wie wir weiter oben sehen wurde PHP in der Version 5.2 installiert, also müssen wir nun auch die Xdebug Version für PHP 5.2 herunterladen und installieren.

Aber Achtung es gibt 2 verschiedene Varianten:

Eine Thread sichere und eine Nicht Thread Sichere (nts), für die Installtion auf dem IIS muss die nts Variante verwendet werden.

Hier geht es direkt zum Download xdebug version 2.1.2 für PHP 5.2 Not Thread Safe

Die Extension besteht lediglich aus einer DLL Datei mit dem Namen:

php_xdebug-2.1.2-5.2-vc6-nts.dll

Nachdem man die Datei heruntergeladen hat muss diese in das Ext Verzeichnis von PHP kopiert werden.

Bei einer Standardinstallation auf einem W2K8 Server (64 BIT) findet man das Ext Verzeichnis unter folgendem Pfad:

C:\Program Files (x86)\PHP\v5.2\ext

Als nächstes muss die PHP.INI angepasst werden um die Debugger Extension verwenden zu können

Die PHP.INI befindet sich im Verzeichnis:

C:\Program Files (x86)\PHP\v5.2

Also öffnen wir die PHP.INI mit einem Texteditor und fügen folgende Einträge hinzu:

[xdebug]
zend_extension = "C:\Program Files (x86)\PHP\v5.2\ext\php_xdebug-2.1.2-5.2-vc6-nts.dll"
xdebug.remote_enable = On
xdebug.remote_host = "localhost"
xdebug.remote_port = 9000
xdebug.remote_handler = "dbgp"

Eigentlich ist es gleich an welcher Stelle diese Einträge hinzugefügt werden, aber wer sich gerne strikt an Vorgaben hält, kann die Einträge direkt unter dem folgenden Eintrag einfügen, dann funktioniert es auf jeden Fall.

Nun speichern wird die PHP.INI und müssen noch den IIS Neu starten:

Entweder über die Konsole “Internetinformationsdienste (IIS)-Manager

oder über die Kommandozeile:

net stop WAS (zum stoppen des IIS)

und dann

net start W3SVC (um den IIS wieder zu starten.)

Später (nachdem wir PhpStorm installiert haben und damit auch einen brauchbaren Editor  zur Verfügung haben)  prüfen wir auch noch ob die Extension richtig eingerichtet wurde.

PhpStorm installieren

PhpStorm gibt es in einer 30 Tage Trial Version, wer also keine Lizenz besitzt kann sich  erst einmal 30 Tage lang anschauen ob im PhpStorm das Geld, was es kostet, wert ist (Ich denke dass ist es auf jeden Fall, ein tolles Produkt wie eigentlich alle Produkte von JetBrains. Nein ich bekomme keine Prozente )

Den Download gibt es hier: http://www.jetbrains.com/phpstorm/download/

Nachdem herunterladen installieren wir PhpStorm einfach mit allen Standardeinstellungen.

WordPress Projekt in PhpStorm einrichten

Nun öffnen wir PhpStorm und wählen die nachfolgende Option aus:

Create New Project from Existing Files

Das Szenario: Lokaler Web Server und Source Code unterhalb des Web Root passt genau für unser vorhaben.

Nun wählen wir das Root Verzeichnis (Nicht das WordPress Verzeichnis auswählen) des Default WEB unseres localhost aus.

Jetzt geben wir dem Projekt Server noch einen Namen (z.B. MyLocalServer)

In nächsten Schritt (Siehe Abbildung oben) geben wir nun die Projekt URL unserer WordPress Installation an.

Und haben damit das Projekt eingerichtet (Wie man auch in der folgenden Abbildung sehen kann).

Xdebug überprüfen

Wir öffnen die Datei index.php aus dem Root Verzeichnis unserer WordPress Installation im PhpStorm Editor.

Dort fügen wir die Funktion phpInfo() direkt nach dem Kommentar ein und speichern die Datei ab.

Nun öffnen wir den Browser und geben localhost/wordpress ein. Wenn anstelle der normalen WordPress Startseite diese PHP Info Seite angezeigt wird, haben wir bis hierhin schon mal alles richtig gemacht.

Um die Prüfung von Xdebug durchführen zu können, benötigen wir den Source Code der im Browse dargestellten phpinfo Seite.

Dazu lassen wir uns den Quelltext der Seite anzeigen, markieren den gesammten Quelltext, kopieren diesen in die Zwischenablage, und öffnen anschließend folgende Webseite:

http://xdebug.org/find-binary.php

Dort wo der rote Pfeil hinzeigt fügen wir dann den in der Zwischenablage befindlichen Quelltext ein und betätigen anschließend den “Analyse my phpinfo() output” Button.

Wenn Xdebug richtig installiert ist, sollte das Ergebnis wie folgt aussehen:

Wenn Xdebug nicht richtig installier ist, sollte man überprüfen, ob die Pfadangabe und der Dateiname der Xebug DLL in der PHP.INI richtig angegeben sind.

PhpStorm für das Debugging konfigurieren

Wir öffnen den Dialog “Edit Configurations”

Nun fügen wir eine neue Konfiguration hinzu:

Eine PHP Web Application Konfiguration

Im Feld unnamed geben wir unserer Konfiguration einen Namen. Zum Beispiel IIS.

Dann müssen wir einen Server auswählen (da wir aber noch keinen Konfiguriert haben, müssen wir zuerst einmal einen neu anlegen).

Hier Dialog zum einrichten eines neuen Server öffnen:

Dann im Dialog auf das + um einen neuen Server anzulegen:

Hier der bereits ausgefüllte Dialog:

Eingabe bestätigen und anschließend folgende Eingaben noch ergänzen, siehe Beschreibung unterhalb der Abbildung.

Der Konfiguration einen Namen geben (z.B. LocalIISWordPress)

Und die StartUrl um WordPress ergänzen, so dass der korrekte Link (http://localhost/wordpress) unter der Start URL angezeigt wird.

Das sollte dann so aussehen:

Dann bestätigen wir auch diesen Dialog

Und wenn wir nun auf den RUN Button drücken ….

Sollte sich der Default Browser mit der WordPress Seite automatisch öffnen.

Eigentlich sollte das setzen von Breakpoint nun auch schon funktionieren, probieren wir das doch mal indem wir einen Breakpoint auf die Zeile phpinfo() setzen die wir in der index.php eingefügt haben.

Einen Breakpoint kann man übrigens ganz einfach dadurch setzen, indem man mit der Maus an die Stelle klickt auf die der Rote Pfeil zeigt.

Und wenn wir nun anstelle des RUN Button, den DEBUG Button drücken …..

Richtig, der Programmablauf bleibt am Breakpoint stehen und wartet darauf das wir den Programmablauf fortsetzen.

So und nun viel Spaß beim PHP Debugging.

Mit den, bis zur Visual Studio 2010 enthaltenen, und Stand Heute mit der nächsten Visual Studio Version nicht mehr unterstützen, “Visual Studio Setup Projekte”, war ich eigentlich noch nie wirklich zufrieden. Also muss etwas neues her, mit dem ich dieses ungeliebte Setup Projekt ersetzen kann und mein Projekt auch noch mit der nächsten Visual Studio Version weiter entwickeln und distribuieren kann.

Nach ein wenig Recherche und ein wenig Gezwitscher auf Twitter stand fest, dass WiX wohl die beste Lösung sei um das Deployment der Anwendung durchzuführen.

WiX ist ein von Microsoft initiiertes Open Source Projekt dass unter anderem von Microsoft selbst für die  Distribution von Microsoft Office verwendet wird.

Nachdem klar war, das WiX in Zukunft bei mir für die Installation meines Projektes zuständig sein soll, habe ich über Twitter von Sebastian Seidel einen Link auf einen Beitrag erhalten in welchem beschrieben wird wie man in 5 einfachen Schritten aus einem Visual Studio Setup ein WiX Setup Projekt machen kann.

Ich bin dann dieser Anleitung gefolgt und habe die Konvertierung und Änderungen laut dem oben genannten Beitrag durchgeführt.

Wobei ich sagen muss, dass diese Konvertierung zwar ganz schön ist, aber leider nicht so ohne weiteres direkt zum Erfolg führt.

Ich habe dann mit ein wenig Hilfe von Sebastian, Danke noch mal dafür, relativ schnell, erst einmal ein generell funktionierendes Setup mit WiX zum laufen bekommen. Leider noch ohne wirklich zu wissen wie WiX tatsächlich funktioniert und wie umfangreich WiX in Wirklichkeit ist.

Da ich aber nicht so leicht zufrieden zu stellen bin und mir das WiX Setup,  welches aus dem decompilierten alten Setup erstellt wurde, nicht gefallen hat (da waren zu viele statische Angaben enthalten und es hatte keine echte nachvollziehbare Struktur) habe ich mich mit WiX näher beschäftigt.

Nachdem ich ein paar Tage mit WiX gearbeitet habe, würde ich sagen, dass es sich nicht lohnt ein Setup Projekt zu decompilieren um dieses dann manuell nachzuarbeiten.

Meiner Meinung nach ist es einfacher ein Basistemplate mit den wichtigsten Funktionalitäten, gepaart mit ein wenig Grundwissen über WiX zu nehmen und sich das benötigte Setup Projekt manuell zu erstellen.

Und genau ein solches Basistemplate möchte ich hier zusammen mit dem notwendigen Basiswissen zu WiX vorstellen und vermitteln.

Wer WiX noch nicht auf seinem Rechner installiert hat, sollte das nun aber spätestens nachholen.

Hier der Link zum Download von WiX

Nachdem man WiX installiert hat und Visual Studio startet, findet man dort neue Projektvorlagen:

In diesem Beitrag dreht sich alles nur um das eigentliche Setup Projekt die anderen Projekt Vorlagen sind dann eher für die Fortgeschrittenen.

Um die Funktionsweise von WiX direkt selbst ausprobieren zu können, habe ich ein Testprojekt erstellt dass sowohl eine Windows Forms Anwendung, wie eine Class Library und das zugehörige Wix Setup Projekt in einer Solution enthält.

Also einfach die Solution (VS2010) herunterladen, entpacken, BS starten und loslegen.

Der Einfachheit halber habe ich alle Erklärungen direkt als Kommentar in das WiX Skript aufgenommen.

So hier das WiX Script zum anschauen. Im Anschluss folgt dann auch noch der Link zum herunterladen der gesamten Test Solution.

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
  <!--  <?define Manufactor = "Hans-Peter Schelian"?>
        Anstelle den Manufactor an mehreren Stellen anzugeben weise ich hier lieber einer Variablen den Wert zu
        und verwende im weiteren Verlauf einfach die Variable
  -->
  <!--  <?define UpgradeGuid = "{3B563A68-99BC-4528-9356-295ADB67909A}"?>
        Ganz Wichtig, die Guid für den UpgradeCode darf nach der ersten Installation nicht mehr geändert werden
        aus diesem Grund weise ich diese Guid einer Variablen zu die ich dann im weiteren Verlauf im Bereich
        <Product UpgradeCode="$(var.UpgradeGuid)" /> und  im Bereich <Upgrade Id="$(var.UpgradeGuid)" anstelle
        der Eingabe der eigentlichen Guid verwenden kann.
  -->

  <!-- Hier nun alle Defines die durch den Präprozessor aufgelöst werden -->
  <?define Manufactor = "Hans-Peter Schelian"?>
  <?define UpgradeGuid = "{3B563A68-99BC-4528-9356-295ADB67909A}"?>

  <!--  Erklärungen zum Bereich <Product> Siehe auch http://wix.sourceforge.net/manual-wix3/wix_xsd_product.htm

        Id="*" Mit dem + wird erreicht, dass bei jedem erzeugen des Setup eine neue Guid erstellt wird.
          Man könnte natürlich auch alternativ eine feste Guid vergeben, dass würde dann so ausssehen:
          Id="{2BE1FDE8-FAEE-48B5-AA08-FD2FE26D7FB2}"

        Name="WiXDemoProjekt" Name des Projektes wie es in "Programme und Funktionen" angezeigt wird

        Version="!(bind.FileVersion.MyApplicationFile)" - Das ist die Programmversion des Produktes,
          entweder man muss die Version manuell angeben: Version="1.0.1.1" oder man kann wie ich es hier
          demonstriere, Binder Variablen des WiX Linker verwenden um Dynamisch die Vesionsnummer aus
          einer beliebiegen Datei des Projektes zu ermitteln.
          Im Beispiel verwende ich die Möglichkeit die Version welche mit [assembly: AssemblyFileVersion("1.0.0.0")]
          in der AssemblyInfo gesetzt wurde aus der Datei auszulesen.

        Manufacturer="$(var.Manufactor)" Zuweisung des in der Präprozessor Variablen gespeicherten Herstellers,
          alternativ kann man natürlich auch eine manuelle Zuweiung Manufacturer="Hans-Peter Schelian" vornehmen

        UpgradeCode="$(var.UpgradeGuid)"> Zuweisung der in der Präprozessor Variablen gespeicherten Guid,
          alternativ kann man die Zuweisung UpgradeCode="{2BE1FDE8-FAEE-48B5-AA08-FD2FE26D7FB2}"> auch manuell
          durchführen.
  -->
  <Product
  Id="*"
  Name="WiXDemoProjekt"
  Language="1033"
  Version="!(bind.FileVersion.MyApplicationFile)"
  Manufacturer="$(var.Manufactor)"
  UpgradeCode="$(var.UpgradeGuid)">

    <!-- Erklärungen zum Bereich <Package> http://wix.sourceforge.net/manual-wix3/wix_xsd_package.htm
      InstallerVersion="200" Ab Windows Installer 2.0
      Compressed="yes" - So werden die Dateien im MSI File komprimiert
      Description="Installiert das WiXDemoProjekt" - Eine Beschreibung für das Installer Package
      Manufacturer="Hans-Peter Schelian" - Und wieder der Hersteller siehe auch <Procuct Manufacturer="" />
      Comments="Ich wünsche allen viel Spaß mit diesem Beispiel" - Das was es bedeutet ein Kommentar
    -->
    <Package
    InstallerVersion="200"
    Compressed="yes"
    Description="Installiert das WiXDemoProjekt"
    Manufacturer="$(var.Manufactor)"
    Comments="Ich wünsche allen viel Spaß mit diesem Beispiel"
  />

    <!-- Erklärungen zum Bereich <Media> Siehe auch http://wix.sourceforge.net/manual-wix3/wix_xsd_media.htm
    -->
    <Media
    Id="1"
    Cabinet="media1.cab"
    EmbedCab="yes"
  />

    <!-- ARP Support Oder wie konfiguriert man Add/Remove Programs mit dem Windows Installer
        Siehe auch http://msdn.microsoft.com/en-us/library/aa368032.aspx
    -->
    <Property Id="ARPHELPTELEPHONE" Value="XXXXX/XXXXXXX" />
    <Property Id="ARPHELPLINK" Value="http://blog.schelian.de" />
    <Property Id="ARPCONTACT" Value="Schelian IT Beratung" />
    <Property Id="ARPCOMMENTS" Value="Alles WiX oder was" />
    <Property Id="ARPURLINFOABOUT" Value="http://www.schelian.de" />

    <!-- Erklärungen zum Bereich <Upgrade>
        Upgrade Id="$(var.UpgradeGuid)"> hier Zuweisung durch Präprozessor Variable, siehe auch Hinweise
          zu define UpgradeGuid

        <UpgradeVersion Minimum="!(bind.FileVersion.MyApplicationFile)" - Hier wird festgestellt ob
          bereits ein neueres Produkt (Neuere Version) installiert ist.

        <UpgradeVersion Minimum="0.1.0.0" - Prüfung ob bereits eine frühere Version installiert ist

        <UpgradeVersion Minimum="1.0.0.0" Maximum="99.0.0.0" - Ist das Prpdukt in welcher Versio auch immer
            bereits auf dem Rechner installiert, dann setzt die internet Variable PREVIOUSVERSIONSINSTALLED,
            dadurch wird verhindert, dass selbst dann wenn man eine Version die nicht als Upgrade gilt
            (nur im vierten Bereich) der Versionsnummer geändert ist, nicht dazu führt, dass es zu doppelten
            Einträgen im Add/Remove Programms kommt.
    -->
    <Upgrade Id="$(var.UpgradeGuid)">
      <UpgradeVersion Minimum="!(bind.FileVersion.MyApplicationFile)"
                      IncludeMinimum="no"
                      OnlyDetect="yes"
                      Language="1033"
                      Property="NEWPRODUCTFOUND" />
      <UpgradeVersion Minimum="0.1.0.0"
                      IncludeMinimum="yes"
                      Maximum="!(bind.FileVersion.MyApplicationFile)"
                      IncludeMaximum="no"
                      Language="1033"
                      Property="UPGRADEFOUND" />
      <UpgradeVersion Minimum="1.0.0.0" Maximum="99.0.0.0"
         Property="PREVIOUSVERSIONSINSTALLED"
         IncludeMinimum="yes" IncludeMaximum="no" />
    </Upgrade>

    <!-- So nun wird die Verzeichnis Struktur für die Installation aufgebaut
      <Directory Id="TARGETDIR" Name="SourceDir"> Diese Zeile setzt das Root Verzeichnis der Installation
        "\"
      <Directory Id="ProgramFilesFolder"> verwendet eine durch den Windows Installer vordefinierte Id zur
        Verwendung der Standard Programmpfads.
        "C:\Program Files"
      <Directory Id="CompanyFolder" Name="Schelian IT Beratung">
        "C:\Program Files\Schelian IT Beratung\"

      <Directory Id="INSTALLLOCATION" Name="WiXDemoProjekt">
        "C:\Program Files\Schelian IT Beratung\WiXDemoProjekt\"
    -->
    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="ProgramFilesFolder">
        <Directory Id="CompanyFolder" Name="Schelian IT Beratung">
          <Directory Id="INSTALLLOCATION" Name="WiXDemoProjekt">
            <!-- Und dahinein packen wir eine Component, in diesem Fall Unser Ausführbares Programm
                Jede Component muss eine eindeutige Id bestzen, diese wird weiter unter verwendet um die Component
                einem Feature zuzuordnen.
                Eine Component sollte eine Guid besitzten, damit es später Möglich ist anhand dieser Guid die Datei
                eindeutig zu identifizieren, damit man mit dem MS Installer, eine Reparatur einer vorhandenen Installation
                durchführen kann.
            -->
            <Component Id="ProductComponent" Guid="{4A5619DF-5841-48EC-8D7C-D368718C6D1A}">
              <!-- Innerhalb der Komponente bestimmen wir dann die zu installierende Datei
                  Jedes File muss einen eindeutige Id besitzen, der Name ist der Dateiname am Zielort und
                  mit Source wird die Quelle der Datei angegeben.

                  Name="$(var.WixDemoProjekt.TargetFileName)" nutzt die Möglichkeit den Zielnamen aus dem
                  Visual Studio Projekt zu übernehmen, dass hat den Vorteil, dass man sich keine Gedanken
                  darüber machen muss das Setup anfassen zu müssen, wennm man den Ausgabe Namen im VS Projekt
                  ändert.

                  Source="$(var.WixDemoProjekt.TargetPath)" nutzt ebenfalls die Möglicheit der Visual Studio
                  Project References und Variablen.
                  Siehe auch http://wix.sourceforge.net/manual-wix3/votive_project_references.htm
                  Man miuss übrigens um diese References nutzen zu können im WiX Setup Projekt eine Reference auf das
                  Visual Studio Projekt setzen.

                  KeyPath="yes" Für nähere Informatinonen siehe http://wix.sourceforge.net/manual-wix3/wix_xsd_file.htm
              -->
              <File Id="MyApplicationFile" Name="$(var.WixDemoProjekt.TargetFileName)" Source="$(var.WixDemoProjekt.TargetPath)" KeyPath="yes">
                <!-- Dann legen wir doch gleich noch einen Desktop Shortcut für das Projekt an. -->
                <Shortcut Advertise="yes" Id="DesktopShortCut" Name="WiXDemoProjekt" Directory="DesktopFolder" WorkingDirectory="INSTALLLOCATION" Description="WiXDemoProjekt Programm ausführen" Icon="Icon.exe">
                  <!-- Und dieses Icon soll für den Shortcut verwendet werden -->
                  <Icon Id="Icon.exe" SourceFile="$(var.WixDemoProjekt.TargetPath)" />
                </Shortcut>
              </File>
            </Component>
            <!-- Nun muss für jedes weitere File dass installiert werden soll, eine Component erstellt werden
                Es wäre auch möglich mehrere Files in einer Component zusammenzufassen, allerdings würde ich das
                nur empfehlen, wenn man tgatsächlich einzeln zu installierende Feature implementiert, die je
                Component aus mehereren Dateien bestehen.
            -->
            <Component Id="WiXDemoLib" Guid="{777028E8-DA56-400E-9C71-844AE328E8BF}">
              <!-- Hier nun die zu installierende Datei der Component hinzufügen -->
              <File Id="WiXDemoLib" Name="WiXDemoLib.dll" Source="$(var.WixDemoProjekt.TargetDir)WiXDemoLib.dll" KeyPath="yes" />
            </Component>
            <!-- Beispiel wie man eine App.Config in das Setup aufnehmen und während der Setup Erstellung umbenennen kann
                Hier wird aus der app.config die WixDemoProjekt.Exe.Config
            -->
            <Component Id="app.config" Guid="{EE4CA09D-2C10-48E4-946A-D8B9242F557E}">
              <File Id="app.config" Name="WixDemoProjekt.Exe.Config" Source="$(var.WixDemoProjekt.ProjectDir)app.config" KeyPath="yes" />
            </Component>
            <!-- Und hier ein Beispiel wie man Datei in Unterverzeichnis am Zielort kopieren kann-->
            <Directory Id="IMAGEFOLDER" Name="Images">
              <Component Id="WiX.image" Guid="{ACD0322F-8170-4C67-84BC-161FCEE6274A}">
                <File Id="WiX.image" Name="wixlogo.png" Source="$(var.WixDemoProjekt.TargetDir)images\wixlogo.png" KeyPath="yes" />
              </Component>
            </Directory>
          </Directory>
        </Directory>
      </Directory>

      <!-- Verknüpfungen im Startmenü setzen
          Siehe auch http://wix.sourceforge.net/manual-wix3/create_start_menu_shortcut.htm
      -->
      <Directory Id="ProgramMenuFolder">
        <Directory Id="MyShortCutsDir" Name="WiXDemoProjekt">
          <Component Id="ShortCutComponent" Guid="{B51BC276-F509-4F25-9738-EE176445D073}">
            <Shortcut Id="ProgShortCut" Name="WiXDemoProjekt" Description="WiXDemoProjekt Programm Verkmüpfung" Target="[INSTALLLOCATION]WixDemoProjekt.Exe"></Shortcut>
            <Shortcut Id="UninstallShortCut" Name="Uninstall WiXDemoProjekt" Target="[System64Folder]msiexec.exe" Arguments="/x [ProductCode]"/>
            <RemoveFolder Id="RemoveMyShortCuts" On="uninstall"/>
            <RegistryValue Root="HKCU" Key="Software\Schelian IT Beratung\WiXDemoProjekt" Name="installed" Type="integer" Value="1" KeyPath="yes"/>
          </Component>
        </Directory>
      </Directory>
      <!-- Wird benötigt um den Desktop Shortcut anlegen zu können -->
      <Directory Id="DesktopFolder" Name="Desktop" />
    </Directory>

    <!-- Feature Bereich hier als Basistemplate nur ein Feature (Alles installieren)
        Siehe auch http://wix.sourceforge.net/manual-wix3/wix_xsd_feature.htm
    -->
    <Feature Id="ProductFeature" Title="WiXDemoProjekt" Level="1">
      <ComponentRef Id="ProductComponent" />
      <ComponentRef Id="WiXDemoLib" />
      <ComponentRef Id="app.config" />
      <ComponentRef Id="WiX.image" />
      <ComponentRef Id="ShortCutComponent" />
    </Feature>

    <!-- Das was nun folgt ist schon ein wenig Finetuning CustomActions
        siehe auch http://wix.sourceforge.net/manual-wix3/wix_xsd_customaction.htm
    -->
    <!-- Keinen Downgrade zulassen -->
    <CustomAction Id="PreventDowngrading"
                  Error="Es ist bereits eine neuere Version instlliert." />

    <!-- Nun noch die auszuführende Reihenfolg angeben
        siehe auch http://wix.sourceforge.net/manual-wix3/wix_xsd_installexecutesequence.htm
    -->
    <InstallExecuteSequence>
      <Custom Action="PreventDowngrading"
              After="FindRelatedProducts">NEWPRODUCTFOUND</Custom>
      <RemoveExistingProducts After="InstallFinalize" />
    </InstallExecuteSequence>

    <!-- Wenn ein neueres Produkt gerunden wurde, soll das auch in der UI ausgegeben werden
        siehe auch http://wix.sourceforge.net/manual-wix3/wix_xsd_installuisequence.htm
    -->
    <InstallUISequence>
      <Custom Action="PreventDowngrading"
              After="FindRelatedProducts">NEWPRODUCTFOUND</Custom>
    </InstallUISequence>

    <!-- So kann man eine eigene Lizenzmeldung ausgeben -->
    <WixVariable Id='WixUILicenseRtf' Overridable='yes' Value='$(var.WixDemoProjekt.ProjectDir)Lizenzbestimmungen.rtf'/>

    <!-- UI Definition für Minimales Setup
    Um diese UI Definition vornehmen zu können,
    muss im WiX Projekt die WixUIExtension.dll als Reference hinzugefügt werden
    -->
    <UIRef Id="WixUI_Minimal" />
    <UIRef Id="WixUI_ErrorProgressText" />
  </Product>
</Wix>

WixDemoProjekt (VS2010 Solution)

Einzelheiten dazu findet Ihr in meinem ersten Post dazu.

Um diesem Treffen einen angemessenen Rahmen zu geben, haben wir (das sind noch immer Sascha Dittmann und ich ) bei der Auswahl der Lokation selbstverständlich darauf geachtet eine Lokation mit einem würdigen Namen zu finden.

Ich denke dass ist uns gelungen.

Das Treffen findet im Restaurant “Zwölf Apostel” in Alzey statt.

Das Restaurant befindet sich inmitten der Innenstadt, direkt am Gerry Jansen Theater. Parklätze sind nicht direkt vor dem Restaurant vorhanden.

Es gibt jedoch mehrere Parkplätze in der Nähe, siehe nachfolgende Abbildung.

Restaurant Zwölf Apostel

A) Parkplatz am Obermarkt (3 Gehminuten)
B) Parkplatz Ostdeutsche Straße (5 Gehminuten)
C) Parkplätze am Straßenrand Sankt-Georgen-Straße (2 Gehminuten)

Hinweise zu den Parkmöglichkeiten:
In der Sankt-Georgen-Straße sind nur 5 Parkplätze und meisten belegt, doch auf dem Obermarkt sollten eigentlich genügend Parkplätze vorhanden sein.
Sollte am Obermarkt wirklich alles belegt sein, gibt es auf der Ostdeutschen Straße  Ecke Raugrafenstraße einen großen Parkplatz auf dem Abends immer genügend Platz vorhanden ist.

So nun noch einmal alle Fakten im Überblick:

Mittwoch 19.10.2011 um 18:30 Uhr

Zwölf Apostel
Hellgasse 7
55232 Alzey

Routenplaner

Bis Mittwoch !!

Seit einigen Woche kann man auch

Es gibt zwar keine #HashTags aber eigentlich sind diese auch gar nicht unbedingt notwendig, es geht auch ohne, wie wir gleich sehen werden.

Ich möchte bestimmte Ereignisse auf Google+ hinterlegen, diese je nach Art des Ereignisses, entweder mit bestimmten Leuten oder der Öffentlichkeit teilen, oder einfach nur für mich zur späteren Erinnerung festhalten.

Natürlich gehe ich an dieser Stelle davon aus, dass Google meine Daten nur denjenigen Zugängig macht, denen ich es erlaube (Circles), und auch sonst nichts mit meinen Daten anstellt, was ich nicht möchte (Die Hoffnung stirbt ja bekanntlich zuletzt ).

Aber das ist ein anderes Thema, dass ich hier nicht weiter vertiefen möchte. Wer also gar kein Vertrauen oder einfach nur zu viel misstrauen hat, soll halt keine Daten G+ anvertrauen. Und besser gar nichts im Internet haben, vor allem nicht auf Facebook, aber dass ist auch ein anderes Thema.

So nun aber zur Auflösung wie ich G+ als Logbuch verwende:

Als erstes muss ich mir ein Kürzel für mein Logbuch ausdenken, und zwar eines, dass vermutlich nicht sehr häufig in meinen anderen Beiträgen vorkommt. Das kann auch der Begriff “Logbuch” sein, wenn man nicht in allen Beiträgen über Logbücher schreibt.

Dann erstellt ich die Beiträge die in meinem Logbuch erscheinen sollen im Format:

Nun kann ich den Beitrag für beliebige Kreise freigeben und ihn teilen.

Wie kann ich nun aber Logbuch Einträge erstellen, die nur für mich (und Google ) sind?

Ich erstelle mir einen Kreis, zum Beispiel den Kreis “Privat”  und füge keine Personen in diesem Kreis hinzu.

Somit habe ich einen Kreis den ich zum Teilen von Nachrichten verwenden kann, dessen Nachrichten aber nur ich lesen kann.

Nun sind alle Vorbereitungen getroffen um Logbuch Einträge erstellen zu können die entweder nur von mir oder auch von bestimmten Kreisen gelesen werden können.

Aber was wäre ein Logbuch wenn man die Einträge eines Logbuchs nicht auch Chronologisch anzeigen lassen könnte, und nur meine Logbuch Einträge.

Dazu kommt nun die Google+ Suche ins Spiel.

In das Suchfeld gebe ich das Logbuch Kürzel zusammen mit meinem G+ Profilnamen bzw. meinem Nachnamen ein, also für mein Logbuch sieht das so aus:

Nachdem man die Suche das erste mal ausgeführt hat, bietet G+ einem an, dass man diese Suche speichern kann.

Und das machen wir auch.

Wenn man eine Suche speichert wird einem zum Wideraufruf der Suche ein Link auf der linken Seite unterhalb der Stream Auswahl angezeigt, diesen kann man dann jederzeit verwenden um sich sein Logbuch anzeigen zu lassen.

So und nun viel Spaß mit dem G+ Logbuch

Einen weißen Fleck !!

Und dieser Fleck muss weg !! 

Genau das haben wir (wir, das sind Sascha Dittmann und Ich) uns auch gedacht und haben kurzerhand den .NET Stammtisch Rheinhessen gegründet.

Und für wen ist dieser Stammtisch:

Alle, die Interesse an Gesprächen und Erfahrungsaustausch über Themen rund um die Entwicklung im Windows Umfeld (WPF, WCF, REST, WinForms, NT-Services, MVC, Web Apps, HTML5, JavaScript, METRO Apps, Azure, Cloud Computing und alles andere was man sich sonst noch in der Entwicklung vorstellen oder auch nicht vorstellen kann) haben, aus dem Raum Rheinhessen und Umgebung kommen, sind herzlich eingeladen sich unserem Stammtisch anzuschließen.

Wer einen XING Account hat, kann direkt der XING Gruppe beitreten.

Aber natürlich ist es nicht zwingend erforderlich einen XING Account zu besitzen um am Stammtisch teilnehmen zu können.

Anmeldungen zum Stammtisch können auch per Mail an:

info at dotnet-stammtisch-rheinhessen.de

gerichtet werden.

Das erste Treffen, sozusagen, das “Come Together” findet am 19.10.2011 in Alzey statt. Den genauen Ort des Stammtisches werden wir noch rechtzeitig bekannt geben.

Neben dem reinen “Come Together” werden wir, soweit es von Interesse ist über die ersten Erfahrungen mit Windows 8 (sowie das für und wieder der Metro Oberfläche), Visual Studio 11, dem .NET Framework 4.5 also auch über die neuen Sprachfeature von C#5 sprechen.

Aber wie das bei einem Stammtisch ist, da ist nichts in Fels gehauen und wenn an dem Abend andere Themen mit wesentlich mehr Aktualität und Interesse von Seiten der Teilnehmen besteht, dann wird eben darüber gesprochen.

Also auf geht’s zum ersten Treffen des .NET Stammtisch Rheinhessen nach Alzey.

Ich freue mich auf euer Kommen.

Und damit wäre auch der Weiße Fleck weg !!

Nun liegen die Fakten um Windows 8 auf dem Tisch!

• Doch stehen die Fakten mit der Präsentation von Windows 8 wirklich fest?
• Was wurde uns eigentlich als Windows 8 verkauft?
• Worüber freuen wir uns?
• Worüber ist die eine oder andere Gruppe betrübt?

Um diese Fragen und die meine Wahrheit um Windows 8 zu klären,  müssen wir aber auch die jüngere Vergangenheit vor der Öffentlichen Präsentation von Windows mit einbeziehen.

Denn die eigentliche Geschichte um Windows 8 beginnt bereits einige Wochen vor der BUILD in Anaheim.

Was ist in den letzten Wochen wirklich geschehen:

In den Tagen und Wochen vor der BUILD wurde viel Spekuliert.
Teilweise wurden echte Schreckensszenarien vermittelt.
Leider wurde auch von, sonst sachlich und nüchtern berichtenden Kollegen, mit Meldungen wie den folgenden Schlagzeilen gemacht:

• HMTL 5 und JavaScript werden zur Standard Sprache zur Entwicklung von Desktop Anwendungen
• Silverlight wird als Technologie nicht mehr unterstützt
• Die Zukunft um WPF ist ungewiss
• .NET wird es nicht mehr geben oder aussterben und damit wird auch C# und VB verschwinden
• HTML 5 und vor allem JS sind die “must be” Sprachen für jeden Entwickler, sonst ist für Ihn/Sie der Zug abgefahren.
• …. und ganz vieles Mehr.

Unabhängig davon, ob und wie viel davon tatsächlich irgendeiner Wahrheit nahe kommt, haben all diese Überlegungen und Gerüchte darauf basiert, dass davon ausgegangen wurde,  dass mit Windows 8 direkt von einem Nachfolger des Windows 7 wie wir es Heute kennen, einem reinen Desktopbetriebssystem,  gesprochen wird.

Doch was haben wir auf der BUILD wirklich vorgestellt bekommen?

• Eine zu groß geratene Ausgabe von Windows Phone WP7
• Ein neues Tablet Betriebssystem
• Der Nachfolger des Windows 7 Desktop Betriebssystems

Ein wenig von allem!

Präsentiert hat uns Microsoft natürlich “das Neue”, das was man direkt sieht, das was vollkommen anders ist wie bisher, das was dem aktuellen Trend entspricht, das was Hype verspricht, das was ….

Das was präsentiert wurde, war die “Metro Style Oberfläche”

Und dieses neue, ist doch genau das, was uns entweder empört oder begeistert hat.

Je nachdem welcher Zielgruppe man angehört, findet man diese Neuerung als “vollkommen abgefahren”, “Super Innovativ”,  “vollkommen daneben” oder als “Weltuntergang”.

Und ich glaube es gibt mehr Zielgruppen als wir uns das momentan überhaupt vorstellen können.

Allerdings sind die Zielgruppen, die sich bisher mit Windows 8 beschäftigt haben und sich öffentlich darüber geäußert haben, doch eher die aus dem Umfeld derer, welche sich mit der Entwicklung von Software beschäftigen, und für all diese, oder besser gesagt für die meisten von diesen, bedeutet Neuerung und Veränderung natürlich erst einmal die Angst vor Verlust.

Angst vor Verlust, Angst davor dass Wissen das man sich Jahrelang angeeignet hat, nicht weiter verwenden zu können.

Und wenn ich mir das anschaue, was Microsoft uns auf der BUILD als WIN 8 präsentiert hat, dann habe ich als Entwickler von Business Anwendungen (Egal ob als Web Anwendung, Desktopanwendung oder im Backend als Server Anwendung) im ersten Moment auch diese Angst (ganz kurz) verspürt.

Doch als analytischer Mensch lässt man sich natürlich nicht von einem Schauer der einem über den Rücken läuft lähmen und man beginnt die Sache, in diesem Fall Windows 8, mit dem notwendigen Abstand und der notwendigen Sorgfalt von den verschiedensten Seiten zu betrachten.

Ich habe die letzte Woche genutzt um mir Windows 8 genauer anzuschauen und mir Gedanken über die Auswirkungen von Windows 8 auf meinen Job als Entwickler zu machen.

Nachfolgend hierzu meine Gedanken und Thesen.

Metro Style Apps

Metro Style Apps sind nur auf Geräten mit Touch Bedienung sinnvoll einzusetzen.

Microsoft hat als Vision, dass es in Zukunft nur noch Geräte mit Touch Interface geben wird, und daher auf jedem Gerät Metro Style Apps sinnvoll eingesetzt werden können. Dem möchte ich auch nicht wiedersprechen, doch denke ich nicht, dass wir diese Zukunft noch dieses Jahrzehnt erleben werden.

Metro Style Apps werden für mich, meinen Job und meine Kunden mit oder ohne Windows 8 (damit meine ich die nächsten 2 – 3 Jahre) noch nicht wirklich eine entscheidende Rolle spielen.

Metro Style Apps werden weder Heute noch Morgen (mal schauen was übermorgen geschieht und ob dann noch jemand von Metro Style Apps spricht) als Ersatz für Rich Client Desktop Anwendungen im Büro und Produktionsstätten geeignet sein.

Wenn solche Art von Apps überhaupt für Rich Client Anwendungen eingesetzt werden sollten, wird das sicherlich noch bis Ende des Jahrzehnts und darüber hinaus dauern.

Um es nicht später zu vergessen:

Einen Wunsch an Microsoft bezüglich Windows 8 und der Metro Style Oberfläche hätte ich aber schon:

Hallo Microsoft, lasst bei der Installation von Windows 8 per Option entscheiden, welchen Desktop man als Standard verwenden möchte, den Metro Style oder den Standard Desktop  (WIN 7 Like)

Und eines noch Microsoft, solltet Ihr auf die Idee kommen, die in der Windows 8 Preview vorhandenen Möglichkeit, durch Änderung eines Registry Eintrags ein “Windows 7 Like” Startmenü zu bekommen, aus dem Final Release von WIN 8 gänzlich zu entfernen, sage ich euch mit WIN 8 ein zweites VISTA voraus (auf  jeden Fall auf Desktop PCs)

WinRT

Mit der WinRT stellt Microsoft den zentralen Baustein für die neue Metro Style Oberfläche zur Verfügung.

WinRT wird nicht als zusätzlicher Framework sondern als integraler Bestandteil des Betriebssystems betrachtet.

Ob WinRT wirklich eine Lösung oder mehr ein Problem ist, wird sich im Laufe der Zeit zeigen.
Ich finde es, Stand Heute sehr gewagt mit WinRT auf eine Technik wie COM (auch wenn es ein objektorientierter modernerer Ansatz ist) zurückzugreifen, die man vor fast 10 Jahren, aus guten Gründen, durch die .NET Technologie abgelöst hatte.
Einzig die Tatsache dass es in WinRT außer den WinRT eigenen DLLs keine gemeinsamen Bibliotheken gibt lässt mich hoffen, dass es kein zweite DLL Hölle geben wird.

Wer in Manage Code C# oder VB Metro Style Apps schreiben will muss sich im klaren sein, dass man dabei starken Beschränkungen unterliegt, da die WinRT nur eine Teilmenge der .NET Klassen zur Verfügung stellt.

Dinge wie direkte Dateizugriffe, Zugriffe aufs Dateisystem oder auch zugriffe auf eine Datenbank wie SQL oder andere sind nicht direkt möglich.

Um Beispielsweise auf eine Datenbank zugreifen zu können muss man sich zuerst einen Web Service erstellen, den man dann über die WinRT aufrufen kann.

Damit die Metro Style Apps immer den Eindruck hervorrufen dass Sie auf Benutzereingaben sofort reagieren, wurde in der WinRT darauf geachtet, dass alle Aufrufe die im allgemeinen länger als 50 ms dauern Asynchron aufgerufen werden.

.NET (C# 5 und VB)

.NET ist also noch nicht tot.

Neben Metro Style und dem damit zusammenhängenden WinRT wurde auch am .NET Framework gearbeitet.

Das .NET Framework 4.5 wird zusammen mit Windows 8 ausgeliefert (gibt es aber auch für Windows 7).

Zusammen mit dem Framework gehen auch die Managed Code Sprachen C# und VB in die nächste Versionsrunde.

• C# 5.0
• Visual Basic 11.0

Die umfangreichste Erweiterung der Sprachen besteht wohl in der Implementierung der await und async Schlüsselwörter und der damit einhergehenden Vereinfachung der Asynchronen Programmierung.

Die Zukunft von .NET dürfte wohl für die nächsten Jahre zumindest für “echte” Desktop Anwendungen” sowie natürlich für Web und Backend Anwendungen, gesichert sein.

HMTL 5 und JavaScript

Weder HMTL 5 noch JavaScript, und auch nicht die Kombination der beiden Sprachen, sind eine Erfindung von Windows 8.

Jedoch wird diese Kombination sicherlich nicht nur für die Web Entwicklung immer interessanter und wer sich bis Heute nicht damit beschäftigt hat, ist sicherlich gut beraten sich mit diesem Thema in näherer Zukunft auch ein wenig auseinanderzusetzen.

Ganz sicher dann, wenn man nicht nur Backend Programmierung betreibt.

Silverlight

Meiner ganz persönlichen Meinung nach, sieht die Zukunft von Silverlight nicht so rosig aus. Ich denke dass Silverlight mittelfristig zu den Klassischen Verlierern zählen wird und weder weiter entwickelt noch auf ewig weiter unterstützt werden wird.

Rich Web Applikationen können mit anderen Technologien wie HTML 5 zusammen mit JS auf der Client Seite erstellt und zusätzlich noch durch MVC oder ähnliche Technologien (evtl. auch mal durch node.JS) Serverseitig unterstützt werden.

Wenn man sieht, dass der IE10 in der Metro Style Variante keine Add Ins und somit kein Silverlight und kein Flash mehr unterstützt, muss man nur 1 und 1 addieren um sich über die Zukunft on SL seine Gedanken machen zu können.

Mein Tipp: Wenn du merkst, dass du ein totes Pferd reitest, steig ab!

Resümee und Weisheiten

Die Suppe wird nie so heiß gegessen wie Sie gekocht wird.
.NET lebt auch nach Windows 8 weiter, wir müssen nicht alle sofort nur noch HTML 5 und JS Programme schreiben

Der Markt und die Akzeptanz regelt im allgemeinen ganz viel alleine (Siehe VISTA), also wenn Windows 8 letztendlich wirklich nur per Touch ordentlich zu bedienen sein wird, dann wird es vermutlich ein Tablet OS aber kein Nachfolger für Windows 7

Warten wir mal ab wie Windows 8 in der Final Release dann wirklich auf den Markt kommt.

Eines habe ich übrigens vergessen, und das ist der bisher positivste Aspekt des neuen Windows:

Windows 8 startet um ein vielfaches schneller als jede andere Windows Version die es bisher gab.

Abschließen möchte ich, auch wenn dies kein Bericht über ein Fußballspiel war, mit den Worten eines großen Deutschen Fußballers:

Nach dem Spiel ist vor dem Spiel!

Freuen wir uns schon mal auf die Gerüchte und Aufregung um Windows 9.

Diese Version ist die erste, welche eine komplette Gallery Integration (Installation, Update und löschen) von Paketen enthält.

Da ich einige persönliche Änderungen der BlogEngine vorgenommen habe, musste ich zuerst eine Verschmelzung (Merge) der Original Version 2.5.0.11 mit meiner lokale geänderten Version, die aber schon auf dem Code Version 2.5.0.10 basiert, vornehmen.

Der Merge konnte ohne manuelle Nacharbeiten einfach so durchgeführt werden.

Nach der Aktualisierung meins lokalen Quellcodes habe ich in Visual Studio 2010 einen kurzen Testlauf durchgeführt (mit XML Provider) und konnte keinen Fehler feststellen.

Nun habe ich mein NANT Skript aufgerufen, was mir aus der lokalen Version ein Package zur Aktualisierung meines Servers erstellt.

Das dabei erstellt ZIP File mit der Version 2.5.0.11 (in meiner angepassten Version) dann auf den Server hochgeladen und im Root Verzeichnis der BlogEngine entpackt (natürlich nicht ohne vorher eine Datensicherung durchgeführt zu haben).

Nun den Blog aufgerufen und…..

…. auf den ersten Blick war alles in Ordnung, nur auf den zweiten Blick leider nicht.

Beim Aufruf der Seite Plugins gab es eine Fehlermeldung die sich in weitestem Sinne um folgenden Aufruf gedreht hat.

BlogEngine.Core.Packaging.PackageRepository.GetPackage

Eine kurze Recherche hat das gezeigt, dass das Problem dadurch entsteht, dass diese Methode versucht auf eine Tabelle im SQL Server zuzugreifen, die es “noch” gar nicht gibt.

Da auf der Codeplex Seite keine Hinweis auf ein erweitertes Datenbankschema zu finden war, hatte ich auch nicht nach einem Skript zur Aktualisierung der Datenbank gesucht.

Es gibt aber tatsächlich ein Script, allerdings mit dem merkwürdigen Zukunftsweisenden Namen “MSSQLUpgradeFrom2.5to2.6“, also einer Aktualisierung die erst beim Update der BE von 2.5 auf 2.6 notwendig sein soll.

Aber gut, es ist nun mal so, dass folgendes Script schon bei einem Update einer Version 2.5.0.X auf 2.5.0.11 notwendig ist:

SET CONCAT_NULL_YIELDS_NULL, ANSI_NULLS, ANSI_PADDING, QUOTED_IDENTIFIER, ANSI_WARNINGS, ARITHABORT ON
SET NUMERIC_ROUNDABORT, IMPLICIT_TRANSACTIONS, XACT_ABORT OFF
GO

--
-- Create table "dbo.be_Packages"
--
CREATE TABLE dbo.be_Packages (
  [PackageId] nvarchar(128) NOT NULL,
  [Version] nvarchar(128) NOT NULL
)
GO

--
-- Create table "dbo.be_PackageFiles"
--
CREATE TABLE dbo.be_PackageFiles (
  [PackageId] nvarchar(128) NOT NULL,
  [FileOrder] int NOT NULL,
  [FilePath] nvarchar(255) NOT NULL,
  [IsDirectory] bit NOT NULL
)
GO

Nachdem ich diese Skript auf der Datenbank ausgeführt habe, war der Fehler behoben und das Update auf Version 2.5.0.11 erfolgreich abegschlossen.

Und zwar unter den Umständen, dass man nur einen Office365 Account hat und für diesen natürlich auch gleichzeitig der Administrator dieses Accounts ist.

Mit den Bordmitteln von Office365 und der Administrationswebseite ist dies nämlich nicht möglich.

Da sich der Exchange Server aber durch die Windows Powershell steuern lässt, können wir über diesen Weg all die Dinge tun, die uns die Webseite zur Administration nicht im Dialog zur Verfügung stellt.

Ich versuche diese Beschreibung so zu gestalten (Schritt für Schritt). dass auch Leser, die sich mit der Powershell nicht auskennen, die Einstellungen vornehmen können. Ich hoffe das gelingt mir.

Die Windows Powershell ruft man wie folgt auf:

Start Menü –> Programme–> Zubehör –> Windows Powershell –>

Dort dann mit der rechten Maus auf Powershell klicken und “Als Administrator ausführen”

Als erstes müssen wir prüfen, ob die Berechtigungen für die Powershell so eingerichtet sind, dass sie ausreichen um eine Remote Verbindung zum Office365 (Remote Exchange Server) herstellen zu können. Im Standard dürften die Berechtigungen nicht ausreichen und wir müssen diese Berechtigung dann entsprechend anpassen.

Aber eins nach dem anderen.

Prüfen der aktuellen Powershell Berechtigung:

In die Powershell geben wir den nachfolgenden Befehl in die Kommandozeile ein und betätigen dann die Eingabetaste.

Get-ExecutionPolicy

Unbedingt darauf achten, hier ist kein Leerzeichen im Befehl enthalten, es handelt sich im ein Wort.

Wenn vorher noch keine Änderungen an den Berechtigungen der Powershell vorgenommen wurden, sollte folgende Systemantwort zurückgegeben werden “Restricted”:

Wenn anstelle “Restricted”, “RemoteSigned” oder “Unrestricted” zurückgegeben wird, sind die Berechtigungen bereits ausreichend und man kann den nächsten Schritt überspringen.

Setzen der Powershell Berechtigung (nur wenn notwendig)

Der nachfolgende Befehl wird in die Powershell eingegeben und mit der Eingabetaste bestätigt.

Set-ExecutionPolicy RemoteSigned -Force

Eigentlich sollte der Befehl ohne Probleme ausgeführt werden, und es sollte keine Fehlermeldung ausgegeben werden. Zur Sicherheit prüfen wir das noch einmal mit dem Befehl: “Get-ExecutionPolicy”

Nun sollte der Rückgabewert wie folgt aussehen:

Powershell Remote an Office356 anmelden

Nachdem wir nun die Berechtigungen geprüft bzw. gesetzt haben, müssen wir nun die Powershell Remote an Office365 anmelden.

Hierzu geben wir den nachfolgenden Befehl in die Powershell ein und bestätigen wie immer mit der Eingabetaste:

$LiveCred = Get-Credential

Nun sollte sich ein Anmeldebildschirm wie nachfolgend öffnen.

In den Dialog muss man nun die Anmeldeinformationen für seinen Office365 Account eingeben und mit OK bestätigen.

Powershell Session mit Office365 (Exchange Server) herstellen

Als nächstes müssen wir eine Powershell Session mit dem Exchange Server von Office365 herstellen. Hierzu muss man den nachfolgenden Befehl in die Powershell eingeben:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection

Wie immer mit der Eingabetaste bestätigen. Dann sollte eine Meldung wie die nachfolgende in der Powershell zurückgegeben werden.

Powershell Commands importieren (Damit die Powershell Exchangich sprechen kann)

Um in der Powershell die Exchange Kommandos verwenden zu können ist es notwendig die Befehle zu importieren.

Das geht mit der Eingabe des nachfolgenden Befehls in die Powershell:

Import-PSSession $Session –AllowClobber

Nachdem man diesen Befehl wie immer mit der Eingabetaste bestätigt hat, sollte eine, der folgenden Abbildung entsprechenden Rückmeldung, ausgegeben werden.

Damit sind nun die Vorbereitungen abgeschlossen und wir können endlich an die eigentliche Aufgabe gehen:

Wie war die noch mal ?

Ach ja richtig wir wollten die Primäre E-Mail Adresse des Exchange Postfachs ändern.

Ändern der primären E-Mail Adresse

Um die Primäre E-Mail Adresse zu ändern, müssen wir folgenden Befehl in die Powershell eingeben:

Set-Mailbox [Office365Benutzernamen] -EmailAddresses SMTP:[myPrimary@mail.de], [meineAktuelleMail@onmicrosoft.com]

Hier die Syntax dieses Befehls:

• [Office365Benutzernamen] steht hier als Platzhalter für den Office365 Benutzeraccount (der wird und kann nicht geändert werden, ist also der Benutzername)
• [myPrimary@mail.de] steht als Platzhalter für die E-Mail Adresse die nun die primäre E-Mail Adresse sein soll.
• [meineAktuelleMail@onmicrosoft.com] steht als Platzhalter für die aktuelle primäre E-Mail Adresse (bei der ersten Änderung ist das gleich mit dem Benutzernamen)

Und hier auch noch ein Beispiel:

Set-Mailbox max@musterman.onmicrosoft.com -EmailAddresses SMTP:max@musterman.de, max@musterman.onmicrosoft.com

Session schließen

Und ganz zum Ende müssen wir dafür sorgen, dass die Powershell Session wieder geschlossen wird.

Dies geht mit der Eingabe des folgenden Befehls in die Powershell:

Remove-PSSession $Session

Das sollte unbedingt gemacht werden, da es sonst bei mehrfachem herstellen einer Session und nicht korrektem Schließen dazu kommen kann, dass keine neue Session mehr geöffnet werden kann, Max Session überschritten.

(Ich glaube der Wert liegt zwischen 3 und max 5 Session)

So und nun viel Spaß mit Office365 und der eigenen E-Mail als primären E-Mail Adresse.

Welche Mail Adresse die Primäre ist, kann man übrigens in den E-Mail Optionen des Exchange Servers kontrollieren.

Wie das geht kann man in dem bereits oben erwähnte Beitrag nachlesen

http://blog.schelian.de/2011/08/office365-einrichtung-mail-adressen-bei-verwendung-eigener-domain/