.NET Framework 3.5 und Windows Server 2008

Warum Microsoft manchmal bestimmte Wege beschreitet, bleibt wohl auf ewig ihr Geheimnis. Jedenfalls ist es für einen Anfänger etwas verwirrend, dass ausgerechnet das Framework 3.5 (und keine andere Version) anders auf einem Windows Server 2008 zu handhaben ist, als alle anderen.

Vorbemerkungen

Ich komme auf diesen Artikel, weil ich gerade versuche, einen Windows Server mit Hyper-V zu konfigurieren, dass mir verschiedene kleine Maschinchen mit Build-Agenten für den TFS zur Vefrügung stehen. Ich bin schon den halben nachmittag dabei und es wird wohl auch noch einen Artikel dazu geben.

Kurzer Ausflug: Build-Agenten

Diesen Abschnitt sollten all diejenigen überspringen, die sich nur für das eigentliche Thema interessieren!

Der TFS kann u.a. dazu genutzt werden, Builds auf einem anderen Rechner, als dem des Entwicklers auszuführen. Der Platz hier reicht nicht aus, um das genauer zu erklären aber vielleicht so viel: Bei der Arbeit in Teams wird heutzutage i.d.R. Wert auf agile Methoden gelegt. Das heißt nicht gleich eXtreme Programming oder ähnliche Ansätze. Es heißt erstmal, dass ein Team von Menschen gemeinsam effektiv an einer IT-Lösung arbeitet. TFS unterstützt dieses Team dabei. Ein Teilbereich des Ganzen ist nun, dass bei bestimmten Aktionen (automatisch oder manuell) ein zentraler Prozess gestartet wird, der vielleicht Unit-Tests durchführt, Abhängigkeiten sammelt und einen Build erstellt und bei Erfolg verteilt. Kurzum: Es wird versucht, viele der umständlichen Post-Code-Prozesse zu automatisieren.

Der TFS setzt hier (logischerweise) auf MSBuild. Für viele ist es oft überraschend zu hören, dass z.B. die csproj-Dateien unserer Projekte nichts anderes als MSBuild-Skripte sind, sodass MSBuild eigentlich bereits im VS anfängt. Drückt man F5 startet dieses Skript und benutzt z.B. intern irgendwann die csc.exe zum Kompilieren.

Doch zurück zum TFS. Das Erstellen von Build in komplexen Projekten kann schnell sehr zeitaufwendig werden. Eine logische Folge ist es daher, dass der TFS diesen Prozess einfach auf mehrere Maschinen aufteilt. Genau hier kommen die Build-Agenten ins Spiel. Ein sog. Build-Controller wird pro TFS-Collection angelegt. Dieser wiederum kann beliebig viele Build-Agenten verwalten.

Zurück zum Thema

Während der Installation eines Build-Agenten auf einem sauberen Windows 2008 R2 bekam ich es mit einer Fehlermeldung zu tun, die ich nun schon des öfteren gesehen habe und die unbedarfte Entwickler schnell zur Verzweiflung bringen kann.:

Abb. 1: Fehlermeldung während TFS-Konfiguration

Der erste Reflex: .NET Framework 3.5 laden und installieren. Das aber ist genau das Falsche, denn das Setup zu .NET Framework 3.5 bricht ab und meldet, man soll es mit dem Server-Manager durchführen. Genau hier straucheln einige unbedarfte Halb-Admins aber sehr häufig.

Lösung

Der Trick ist eigentlich der, dass Windows Server 2008 .NET Framework 3.5 bereits als Setup mitbringt. Genauer gesagt handelt es sich hier um ein sog. Feature. Features werden im sog. Server-Manager verwaltet:

Abb. 2: Feature-Verwaltung im Server-Manager

Ein Klick auf „Feature hinzufügen“ und es startet ein Assistent. Gleich das erste Feature ist unser Gesuchtes:

Abb. 3: Feature-Auswahl

Nach einem Kliick auf den Haken bei „.NET Framework 3.5.1-Feature“ erscheint noch ein Bestätigungs-Dialog:

Abb. 4: Feature-Abhängigkeiten bestätigen

den man einfach mit „Erforderliche Features hinzufügen“ verlässt. Wenn man nun den Feature-Assistenten weiter durchläuft, landet man plötzlich bei der Konfiguration für die IIS-Rollendienste.

Wir haben nun den Bereich der Features verlassen und sollen eine sog.Rolle definieren. Rollen sind Aufgaben, die ein Windows-Server übernehmen kann. Es gibt Dateiserver, Hyper-V, Zertifizierungsstelle und viele weitere Rollen. Eine davon ist halt die Rollt Webserver, also IIS. Das .NET-Framework-Feature erfordert nun eben das Einschalten der IIS-Rolle (womit der Sinn dieser seltsamen Konstruktion erklärt wäre).

Ich für meinen Teil möchte das absolute Minimum installieren und belasse daher alle weiteren Konfigurations-Schritte, wie sie sind. Klickt man auf der Besätigungsseite des Feature-Assistenten auf „Installieren“, gehts los:

Abb. 6: Featue-Installation

Wenn ich nun den Link für die erneute Bereitschaftsprüfung im Konfigurations-Assistenten aus Abb. 1 erneut anklicke, läuft alles:

Abb. 7: Jetzt ist alles korrekt

Eine Antwort auf „.NET Framework 3.5 und Windows Server 2008“

  1. Der Artikel ist leicht falsch, denn Server 2008 bringt nur das Setup für .NET Framework 3.0 mit.
    Das Setup für 3.5, wie auch auf den Screenshots aufgeführt, gibt es erst bei Server 2008 R2.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.