Visual Studio 2013 – VS2013 – Abwärtskompatibilität mit VS2012 und WIX Setup Projekten

Nachdem Visual Studio 2013 Gestern offiziell veröffentlicht wurde stellt sich mir nun die Frage ob VS2013 zu VS2012 abwärts kompatibel ist und idealerweise sogar vorhandene VS2012 Solutions mit VS2012 und VS2013 wechselweise verwendet werden können.

Vorab kann ich schon mal sagen, dass „meine“ Projekte,. sogar welche die noch auf .NET Framework 2.0 basieren, generell so eingesetzt werden können.

Lediglich Solutions die auch ein WIX Setup Projekt enthalten funktionieren unter VS2013 nicht, „nicht sofort“.

Es gibt wohl noch keine offizielle VS2013 – WIX Unterstützung.
Aber das ist kein Problem, nachfolgend beschreibe ich einen einfachen Weg (danke an stackoverflow) wie man Visual Studio 2013 zu WIX kompatibel bekommt.

Es sei noch darauf hingewiesen, dass meine Beschreibung sowohl mit WIX 3.6 also auch mit WIX 3.7 funktioniert.

Voraussetzung für die von mir beschriebene Änderung ist, dass man eine funktionierende Installation von WIX (3.6 oder 3.7) mit Visual Studio 2012 vorliegen hat.

Aus dieser Installation kopiert man das Verzeichnis

C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Extensions\Microsoft\WiX

nach

C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Extensions\Microsoft\WiX

Danach öffnet man die Datei C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Extensions\Microsoft\WiX\extension.vsixmanifestUnd fügt unterhalb von


201311141327.jpg
den nachfolgenden Abschnitt ein:

201311141324.jpg
Nun öffnet man noch einen Command Fenster mit dem Shortcut
"Developer-Eingabeaufforderung für VS2013"und gibt dort den Befehl
devenv /setup

ein.

Wenn der Befehl ausgeführt ist, kann man VS2013 starten und die WIX Unterstützung funktioniert nun einwandfrei.

Windows 8 Store Apps (HTML5/JavaScript) – CSS ist nicht gleich CSS

imageBei der Arbeit an einer Windows 8 Store App die ich mit HTML5 und JavaScript realisiere, bin ich auf folgendes Problem gestoßen (welches ich hier bereits auf Facebook gepostet habe):

Doch zuerst einmal ein kurzer Ausschnitt des Markup bei welchem das Problem auftritt:

<body>
	<div id="itemTemplate">
		<figure>
			<img id="profile-image" src="images/smalllogo.png" />
		</figure>
		<div>
			<span data-win-bind="innerText: text">Testen</span>
		</div>
	</div>
</body>

Im zugehörigen Stylesheet sind unter anderem folgende Styles definiert:

figure {
    margin: 0px;   
}

#itemTemplate figure img {
    margin: 30px;
}

So wie die Styles definiert sind, sollte das Image Element mit der ID “profile-image” eine Margin von 30px auf allen Seiten vorweisen.

Das funktioniert auch wenn man es in einem Browser aufruft (Sogar der IE funktioniert hierbei korrekt Smiley ).

imageWenn man diese Formatierung allerdings in einem “HTML5/JavaScript Windows a Store App” (was für ein BegriffTrauriges Smiley ) verwendet, greift der Style “#itemplate figure img” nicht in dem Image Element, welches in dem Figure Element eingebettet ist, sondern die Margin Einstellung des übergeordneten Elementes Figur hebt die Formatierung des darin eingebetteten Image Elementes auf.

Ein erstes kleines Fazit dabei ist, dass man sich nicht darauf verlassen kann, dass der zuletzt definierte Style tatsächlich Verwendung findet.
Wenigstens dann nicht wenn man übergeordnete globale Element Formatierungen verwendet.

XAML oder HMTL5

Zum Jahresende stellt sich für mich noch die „Frage aller Fragen“
(Also die aktuelle „Frage aller Fragen“ werde sicherlich bald wieder eine neue haben :

image

Bisher konnte ich mich um dieses XAML Gedöns ganz gut herumdrücken.

  • Viel Backend Entwicklung (kein XAML notwendig)
  • WPF habe ich ausgesessen.
  • Silverlight ignoriert
  • Für die Dicken “Fat Clients” habe ich (immer noch) Winforms eingesetzt und für Webseiten neben C#, HMTL nur ein wenig JavaScript benötigt.

Und nun, stehen Windows 8 Apps (also die Kachel Programme Smiley) auf der Liste.

imageimageimage

Alles WiX oder was – Windows Installer XML toolset für Dummies

Im Zuge der Zukunftssicherung (Heute nennt man das Refactoring) eines meiner älteren aber immer noch aktiven Projekte, einem Windows Forms Projekt sollte es dieses mal nicht nur dem eigentlichen Code sondern dem gesamten Build und Deployment Prozess an den Kragen gehen.

imageMit 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.

imageIch 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:

SNAGHTMLb687d8

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="https://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)

SQL Server – Nach Neuinstallation SQL Server Express auf Dev Rechner Fehler mit DateTime Formaten

Ich will hier kein riesen Fass zum Thema SQL DateTime Formate aufmachen, dazu gibt es schon ganz viele Fässer im Internet, die das ganz ausführlich beschreiben.

In erster Linie geht es mir in diesem Artikel darum, mir selbst eine Nachricht zu hinterlassen, was ich beim nächsten mal machen muss, wenn ich ein solches Problem nochmal habe.

Eventuell hilft der Artikel auch mal jemand anderem, der das gleiche Problem hat, wie das, welches ich nun kurz beschreibe.

Hier nun das Problem:
Nach der Einrichtung eines neuen Entwickler Rechners, natürlich mit ein wenig aktuelleren Programmversionen als es auf dem bisherigen Rechern der Fall war, bekomme ich beim Versuch eine Windows Forms Anwendung[*1] aus Visual Studio heraus zu Debuggen Fehlermeldungen, wenn ich auf die lokale Datenbank die ich auf einem SQL Server Express 64 BIT, auf dem Rechner installiert habe, zugreifen möchte.

Das Programm läuft jedoch einwandfrei wenn ich Remote auf einen anderen SQL Server zugreife.

Da ich die lokale Datenbank aus einem aktuellen Backup des Servers erstellt habe auf dem es per Remote Zugriff keine Problem gibt, schließe ich schon mal aus das meine Datenbank selbst das Problem ist.

Die Fehlermeldung lautet wie folgt:

{„Bei der Konvertierung eines varchar-Datentyps in einen smalldatetime-Datentyp liegt der Wert außerhalb des gültigen Bereichs.“}

Probleme mit der Konvertierung von DateTime Werten, deutet auf ein Problem mit falschen Formaten hin. Die Standard Formate sind abhängig von der verwendeten Sprache.

Auf dem Rechner habe ich entgegen der bisherigen Installationen eine englische SQL Server Express Version installiert und nicht wie sonst einen deutsche Version.

Sowohl auf dem Produktionsserver des Kunden als auch auf meinem „echten“ Server ist aber der SQL Server als Deutsche Version installiert.

Soll das mein Problem sein? (Und es soll sich heraus stellen, dass mein Problem wenigstens damit zusammenhängt)

Mit dem Befehl

SELECT @@LANGUAGE

kann man die aktuellen Spracheinstellungen der aktuellen Verbindung abfragen.

Die Abfrage auf meinem lokalen SQL Express Server ergibt als Antwort English.

Eine Abfrage auf den „echten“ SQL Servern ergibt jeweils Deutsch.

Bingo, da liegt das Problem. Doch wie kann ich das ändern, bzw. was ich muss ich da überhaupt ändern.

Ich muss die Standard Sprache (Default Language) des SQL Login (Benutzer) ändern.

Das kann am einfachsten über die Login Eigenschaften mit dem SQL Server Management Studio machen.

Nun möchte ich aber vermeiden, dass beim nächsten Benutzer den ich anlege wieder die „für mich“ falsche Standardsprache des Benutzers hinterlegt wird.

Die Standardsprache kann man ebenfalls mit dem SQL Server Management Studio ansehen und auch ändern.

Hierzu öffnet man die Server Eigenschaften indem man im SQL Server Management Studio im Object Explorer auf dem Knotenpunkt des Server mit der rechen Maus das Kontextmenü öffnet und dort das Eigenschaften (Property) Fenster öffnet.

Und dort stellen wir die Default Language von English auf German um. Und schon wird beim nächsten Benutzer den man anlegt die „richtige“ Standardsprache für den Benutzer hinterlegt.

Natürlich kann man auch diese Einstellungen per SQL Befehle ausführen, aber wie ich bereits am Anfang sagte, ich möchte hier kein Riesen Fass öffnen, und es gibt ganz viele die sich mit dem SQL Server besser auskennen als ich.

Eventuell ist ja ein Leser des Berichtes so SQL fit und kann die SQL Befehle oder einen direkten Link zu den Befehlen als Kommentar hinterlassen.


[*1] ja die gibt es noch und diese von der ich hier sprechen ist auch schon einige Jahre alt, bzw, wird seit Jahren immer weiter entwickelt

SQL Server Management Studio – Select Top X und Edit Top X Beschränkung

Im Microsoft SQL Server Management Studio (SQL Server 2008) werden im Kontextmenü zu Tables (Tabellen) und Views (Sichten) die beiden nachfolgenden Funktionen angeboten:

  • Select Top 1000 rows (Oberste 1000 Zeilen auswählen)
  • Edit Top 200 rows (Oberste 200 Zeilen bearbeiten)

Über den Sinn oder Unsinn warum man in einer View die Möglichkeit der Bearbeitung angeboten bekommt, möchte ich an dieser Stelle nicht weiter sprechen.

Nun ist es aber so, dass mich, diese Einschränkung stört!

Wenn ich eine Tabelle oder Sicht angezeigt bekomme,  möchte ich diese mit allen Datensätzen und nicht nur mit den ersten 1000 angezeigt bekommen.

Das gleich gilt übrigens auch für die Bearbeitung.

Nun gibt es, „Microsoft sei Dank“ die Möglichkeit, diese Einschränkung in den Optionen zum SQL Server Management Studio einstellen zu können.

Diese Option finden wir unter:

Tools -> Options -> SQL Server Object Explorer

oder für die eingefleischten Deutsch Programm Anwender:

Extras -> Optionen -> Objekt-Explorer von SQL Server

Dort finden wir  unter Table and View Options (Tabellen- und Sichtoptionen)

Die beiden Einträge:

Englische Version Deutsche Version

Nun kann man diese Werte beliebig ändern.

Oder wenn man wie ich keine Einschränkung haben möchte (alle Datensätze), kann man den Wert 0 eintragen.

Dann sieht das Kontextmenü wir folgt aus:

The URL ‚….. for Web project ‚….‘ is configured to use IIS Express as the web server but the URL is currently configured on the local IIS web server.

Die komplette Fehlermeldung die ich erhalten habe lautet wie folgt:

20110622 - IIS Express

Auch wenn dieser Fehler bei arbeiten an einem DotNetNuke Modul aufgetreten ist, kann dieser Fehler in jedem anderen Web Projekt unabhängig von DotNetNuke auftreten.

Was war geschehen.

Ich habe ein laufendes Projekt, von einem Windows 7 Rechner mit Visual Studio 2010 auf dem auch der IIS7 installiert ist, in ein Mercurial Repository gespeichert, und dann später auf einem zweiten Rechner geklont um auf diesem anderen Rechner einige Änderungen vornehmen zu können.

Nach dem Klonen des Projekts musste ich, da der Rechner auf dem ich den Klone erstellt habe, keinen IIS sondern nur den IIS Express installiert hat die Projekteigenchaften dahingehend ändern, dass das Projekt mit dem IIS Express funktioniert.
Was übrigens auch kein Problem war und einwandfrei funktioniert hat.

Bereits zu diesem Zeitpunkt hatte ich mir tatsächlich schon überlegt, ob es zu Problemen führen könnte, wenn ich das Projekt später wieder eingecheckt und dann auf dem ursprünglichen Rechner aktualisiere. Bin aber, da ich neben dem echten IIS auch den IIS Express auf dem ursprünglichen Rechner installiert habe zu der Überzeugung gekommen, dass es keine Probleme geben dürfte, was sich, wie man hier lesen kann nicht bewahrheitete.

Einige Wochen später, natürlich hatte ich mittlerweile vergessen, dass ich eine Umstellung von IIS auf IIS Express vorgenommen hatte, habe ich das Projekt aus dem Mercurial Repository auf dem ursprünglichen Rechner wieder ausgecheckt, bzw. eigentlich nur aktualisiert.

Und nachdem ich mit Visual Studio das Projekt geöffnet habe, kam es zu dem oben beschriebenen Fehler.

Mit der Fehlermeldung konnte ich erst überhaupt nichts anfangen. Dann fiel mir aber ein das ich ja diese IIS Express Änderungen an dem Projekt machen musste um es auf dem auf dem anderen Rechner zum laufen zu bekommen.

Das eigentliche Problem bei diesem Fehler ist, dass sich das Visual Studio Projekt nicht mehr öffnen lässt und daher auch keine Einstellungen geändert werden können. So dass man nicht einfach die Verwendung des IIS Express wieder ausschalten kann. (Ich hätte natürlich händig auch den IIS Express konfigurieren können, das hätte vermutlich auch geholfen)

Ich habe dann folgende Lösung entdeckt, und möchte diese für mich und gegebenenfalls auch für andere die ein solches Problem haben hier veröffentlichen, damit man,  wenn ein solches Problem wieder auftritt diese Lösung wieder finden kann und nicht wieder nach einer Lösung suchen muss.

So nun aber zur eigentlichen Lösung des Problems:

In der Konfigurationsdatei [Projektname].vbproj.user befindet sich unter der Region PropertyGroup folgende Einstellung:

<PropertyGroup>
       <UseIISExpress>true</UseIISExpress>
</PropertyGroup>

Diese Einstellung ändert man auf false, speichert die Datei, macht ein Reload der Projektdatei.

Und fertig.

BlogEngine.NET – VS2010 – Master Page error beim öffnen der default.aspx

Beim Versuch die Datei default.aspx im Design Mode aus Visual Studio 2010 heraus zu öffnen wurde die folgendende Fehlermeldung ausgegeben:

Dieses ist nicht unbedingt ein BlogEngine spezifisches Problem und kann auch mit anderen Projekten auftreten.

Das Problem tritt auf, da in der verwendeten Basisklasse „BlogBasePage“ die Methode  OnPreInit vom PreInit Event aufgerufen wird. In dieser Methode wird eine Masterpage benötigt, da diese dort an die Basisklasse.MasterPageFile zugewiesen wird.

Siehe nachfolgenden Code Auszug:

this.MasterPageFile = string.Format("{0}themes/{1}/site.master", Utils.RelativeWebRoot, this.theme);

Nun gibt es die Möglichkeit direkt in der web.config eine default masterpage anzugeben, und genau dies ist auch die Lösung unseres Problems:

Der Eintrag muss wird in der Region „pages“ der web.config vorgenommen.
Dieser Bereich der web.config sieht vor der Änderung wie folgt aus:

<pages
	enableSessionState="false"
	enableViewStateMac="true"
	enableEventValidation="true"
>

Nun gibt es die Möglichkeit über den Parameter masterPageFile in der web.config eine default Master Page anzugeben, und genau dies machen wir, indem wir den Eintrag in der web.config, wie folgt ändern:

<pages
	enableSessionState="false"
	enableViewStateMac="true"
	enableEventValidation="true"
	masterPageFile="~/themes/Standard/site.master"
>

Man beachte den neuen Parameter

masterPageFile=“~/themes/Standard/site.master“

Dieser setzt die Master Page aus dem Standard Theme als Default Master Page, welche dann in der Basisklasse BlogBasePage verwendet werden kann, so dass der hier beschriebene Fehler nicht mehr auftritt.

Man kann natürlich auch jede andere Master Page aus jedem beliebigen Theme verwenden. Am besten verwendet man die Master Page aus dem verwendeten Theme.

Und nachdem diese Einstellung in der web.config vorgenommen wurde, kann man die default.aspx ohne den hier beschriebenen Fehler öffnen.

Visual Studio 2010 – Breakpoint im DateTimePicker Event friert Rechner mit Win7 64 Bit ein

Eigentlich kaum zu glauben, dass ein solcher Fehler, der bereits seit September 2009 bekannt ist noch immer nicht behoben ist. Aber es scheint tatsächlich so zu sein.

Hier nun das Szenario wie der Fehler reproduziert werden kann:

Zuerst die Systemvoraussetzungen

  • Windows 7 64 Bit
  • Visual Studio 2010 (Edition ist nicht entscheidend)
  • Windows Form Projekt

Und hier hier Programmbedingungen:

  • DateTimePicker auf Windows Form platziert.
  • ValueChanged Event hinzufügen.
  • Innerhalb dieses Events ausführbaren Code hinzufügen
  • Breakpoint in diesen Code (im ValueChanged Event) setzen.
  • Programm im Debug Modus starten (Als Solution Plattform muss Any CPU ausgewählt sein, was auch der Standard ist).
  • Mit dem DateTimePicker Control das Datum ändern.
  • Event wird ausgelöst
  • Peng —- Rechner steht

Das es dieses Problem bereits seit 2009 gibt und bekannt ist, kann man hier nachlesen.

Den Workaround die Solution Plattform auf X86 umzustellen, hat in einem Testprojekt funktioniert, aber in einem umfangreichen Projekt waren Unmengen an Fehlermeldungen nach einer Umstellung aufgetreten, so dass die dabei nicht in Frage gekommen ist.

Hallo Microsoft wann können wir mit einer Lösung rechnen?

WebMatrix und DotNetNuke – Noch nie war es einfacher !!!

Am Wochenende habe ich mir etwas Zeit genommen um mir die Installation von DotNetNuke unter Zuhilfenahme von WebMatrix anzuschauen.

Als kurzes Resumé sei gleich am Anfang gesagt:

Es war noch nie einfacher DotNetNuke zu installieren als mit WebMatrix !

Als erstes muss WebMatrix installiert werden. Dazu lädt man sich den WebInstaller von hier herunter und startet den Installer. Die Gesamte Installation kann gut und gerne (je nach Download Geschwindigkeit) eine halbe Stunde oder etwas mehr dauern.

Während der Installation von WebMatrix werden nachfolgend aufgelistete Programme automatisch installiert.

Je nachdem, auf welchem Betriebssystem man WebMatrix installiert und welche anderen Programme man vorher schon installiert hat, ist während der Installation ein Neustart notwendig.

Nachdem WebMatrix installiert ist und der Schnellstart Bildschirm angezeigt wird, wählt man „Website aus Web Gallery“ aus.

In der Web Gallery steht DotNetNuke auch gleich als erstes Programm zur Auswahl zur Verfügung.

Einfach DotNetNuke auswählen und auf den Button Weiter klicken.

Nun werden die für DotNetNuke zu installierenden Programme / Komponenten angezeigt.

Je nachdem welche Programme bereits auf dem Rechner installiert sind, wird nur das DotNetNuke Paket oder noch zusätzlich der SQL Server Express aufgeführt.

Der SQL Server 2008 Express (es würde auch mit einer 2005 er Version gehen) ist notwendig, da mit WebMatrix zusammen nur ein SQL Server Compact installiert wird, dieser aber weder Views und Trigger noch Gespeicherte Prozeduren unterstützt, welche aber für den Betrieb von DotNetNuke zwingend notwendig sind.

Mit dem nächsten Klick auf OK, wird dann DotNetNuke (und  gegebenenfalls der SQL Server Express ) installiert.

Nun noch auf den URL Link  klicken und die DotNetNuke Installationsroutine wird gestartet.

Für den absoluten Neuling würde ich empfehlen beim ersten Kontakt mit DotNetNuke die Installations-Methode Auto zu verwenden (übrigens ist an dieser Stelle ein unfassbarer Übersetzung Klops zu sehen – Auto wird mit manuell übersetzt, ist doch logisch, oder 🙂 ). Bei dieser Option wird alles von der Installationsroutine vorbelegt und nach dem Klick auf Next ist alles getan und DotNetNuke wird mit Standardvorgaben installiert. Wer bereits mehr mit DotNetNuke, der Einrichtung der Anpassung zu tun hatte, kann auch mit den Optionen Typical und Custom arbeiten (experimentieren).

Nachdem DotNetNuke die Installtion abgeschlossen hat, sollten ganz viele Zeilen mit eine grünen Success im Browser erschienen sein und als letzte Zeile sollte ein

Click here to access your portal

erscheinen.

Dann „Click“ und viel Spaß!!


Wer sich die Installation lieber als Video anschaut kann das unter nachfolgendem Link (in Englisch) anschauen.
http://www.dotnetnuke.com/Resources/VideoLibrary/Viewer/TabId/1613/VideoId/174/Installing-DotNetNuke-With-WebMatrix.aspx