Nie wieder Ärger mit NuGet!

Vielleicht hast du das auch schon erlebt, wenn du NuGet und TFS verwendest:

Das Updaten eine NuGet Pakets erzeugt völliges Chaos in der Projektmappe:

Im Projektmappen-Explorer sieht alles gut aus. Die Ansicht „Ausstehende Änderungen“ im Team Explorer zeigt ein anderes Bild: Nur ein paar Dateien sind geändert, und viele Dateien sind gelöscht, obwohl sie ebenfalls geändert sein sollten.

Durch Einchecken wird das Projekt dann defekt: Dateien werden fälschlicherweise gelöscht, obwohl sie noch in den Projekten verwendet werden, und die Builds schlagen fehl.

TL; DR: Das Problem tritt nur bei lokalen Arbeitsbereichen (Local Workspace) auf. Benutze einen Serverarbeitsbereich (Server Workspace) zum Aktualisieren von NuGet Content-Paketen (Kurzanleitung siehe Ende des Artikels).

Was ist das Problem?

Das Problem tritt nur mit NuGet Paketen auf, die Dateien in das Projekt hineinkopieren, wie z.B. JavaScript Bibliotheken, Views, etc. Ich nenne diese Pakete „Content-Pakete“. Pakete, die nur DLLs referenzieren, sind nicht betroffen.

Beim Installieren eines Content-Pakets kopiert NuGet die Content-Dateien in dein Projekt und fügt die Dateien korrekt der Versionskontrolle hinzu.

Beim Update eines Content-Paketes geht NuGet vor wie immer:

Zunächst werden das Paket und alle dazugehörigen Dateien gelöscht; auch die in das Projekt kopierten Content-Dateien und alle DLL-Referenzen zu dem Paket entfernt. Daraus ergibt sich dann eine Anzahl von „Ausstehenden Löschungen“.

Im nächsten Schritt installiert NuGet dann die neue Version vom Paket, als wäre es die Erstinstallation: Das Paket landet im Paket-Verzeichnis, DLL-Referenzen werden hinzugefügt, und die Content-Dateien werden in das Projekt kopiert und als neue Dateien der Versionskontrolle hinzugefügt.

Hier fangen die Probleme an:
Die Content-Dateien sind immer noch als „Ausstehenden Löschungen“ in deinem Workspace markiert. Wenn NuGet versucht, genau diese Dateien wieder dem Projekt hinzuzufügen, stolpert der Team Explorer: Er erlaubt nicht, eine Datei der Versionskontrolle hinzuzufügen, für die im gleichen Workspace noch eine ausstehende Löschung besteht, sondern erwartet, dass man die Löschung erst eincheckt, und anschließend die Datei als neue Datei eincheckt. Sinnvoller wäre es, wenn der Team Explorer die ausstehende Löschung automatisch in eine ausstehende Änderung umwandelt.

Daraus entsteht das nächste Problem:
NuGet scheint von dem Fehler im Team Explorer nichts mitzubekommen, und kopiert die aktualisierten Content-Dateien auf die Festplatte und fügt sie dem Projekt hinzu (und meldet keine Fehler). Deshalb sieht im Solution Explorer alles gut aus: Alle Dateien sind dort wo sie hingehören, das Projekt kompiliert. Der Team Explorer sieht das anders: In der Ansicht „Ausstehende Änderungen“ sind die ausstehenden Löschungen immer noch vorhanden. Wenn man diesen Umstand nicht bemerkt und die offenen Änderungen eincheckt ist das Projekt für Alle defekt.

Falls man das Problem noch rechtzeitig bemerkt und versucht die ausstehenden Löschungen rückgängig zu machen, hat man auch verloren: Der Team Explorer weigert sich, die Löschungen rückgängig zu machen, da dadurch bestehende Dateien überschrieben werden würden… die Dateien die NuGet beim Update versucht hat in das Projekt hinzuzufügen!

Das Chaos manuell wieder aufzuräumen, und dabei sicherzustellen, dass man auch die aktuellen Versionen der Dateien an der richtigen Stelle hat, macht keine Freude.

Lösung

Die Problemlösung ist einfach: Benutze einen Server Arbeitsbereich zum Aktualisieren von Content- Pakete;, nur die lokalen Arbeitsbereiche sind betroffen (zumindest in der aktuellen NuGet Version 2.8.60318.667). Für meine tägliche Arbeit bevorzuge ich einen lokalen Arbeitsbereich, daher benutze ich einen zweiten Arbeitsbereich zur Aktualisierung von Content-Paketen.

Anlegen eines neuen Server Arbeitsplatzes in Visual Studio

  1. Datei > Quellcodeverwaltung > Erweitert > Arbeitsbereiche > Hinzufügen > Erweitert
  2. Sprechenden Namen eingeben, z. B. “Server Arbeitsbereich für Content-Package Updates”
  3. “Server” bei “Speicherort” auswählen
  4. OK

clip_image002

Neues zu TouchDevelop (jetzt auch für Minecraft)

Über TouchDevelop haben wir nicht nur hier, sondern auch auf Entwicklerkonferenzen berichtet. Wir haben gezeigt, wie einfach es ist, damit Anwendungen und Spiele auf sämtlichen Devices für sämtliche Devices zu entwickeln und als besonderes Highlight eine eigene (in TouchDevelop entwickelte) Bibliothek vorgestellt, mit der sich sogar ein Lego MindStorms Roboter programmieren ließ.

Mittlerweile nimmt aber die Aussage “für sämtliche Devices” ganz neue Dimensionen an. Statt einfach nur noch als HTML5 Anwendung in allen Browsern zu funktionieren, oder als App exportiert in den Windows (Phone) Store exportiert zu werden, sind inzwischen folgende Möglichkeiten hinzugekommen:

  • Export to App Studio (Windows, Windows Phone)
  • Export to Cordova Apps (iOS, Windows, Android)
  • Export to Azure Web Apps (Node.JS)
  • Export to Raspberry PI (Node.JS)
  • Export to Web App or Office Mix

Es gab vor längerem bereits Tutorials, die gezeigt haben, wie sich für den Arduino programmieren lässt (inkl. Simulation auf dem Touchdisplay eines Smartphones). Ganz neu hinzugekommen ist die Unterstützung für das BBC Projekt micro:bit.

Nachdem zurzeit allerdings Minecraft in aller Munde ist (es scheint sich seit dabei zu einem Signature-Game für Microsoft zu entwickeln), ist folgendes besonders interessant: Mit MinecraftEDU und MinecraftPI werden Versionen angeboten, die es möglich machen, Scripte für Minecraft mittels TouchDevelop zu entwickeln.

Hier ein Beispiel für den Bau einer Pyramide:

PyramidCraft

 

Ich würde sagen: Das klingt doch mal nach einem spannenden Wochenend-Projekt, oder? Hier der Link zur Dokumentation.

Und nun viel Spaß!

KEIN Aprilscherz: Visual Studio 2015 Enterprise

Gestern hat Microsoft bekannt gegeben, dass mit der neuen Version 2015 geplant sei, die SKUs Premium und Ultimate zusammenzufassen. Die neue Edition wird Enterprise heißen. Obwohl sie damit faktisch alle Ultimate Features enthält (wie z.B. Intellitrace), bedeutet das nicht, dass alle Premium Abonnenten tiefer in die Tasche greifen müssen.

Im Gegenteil: Der Neuerwerb einer Enterprise Lizenz wird sogar günstiger sein, als zuvor Visual Studio Premium 2013. Die jährlichen Kosten für die Erneuerung sind identisch.

Visual Studio 2013 (New / Renewal in USD)

Visual Studio 2015 (New / Renewal in USD)
Ultimate mit MSDN 13.299,00 / 4.249,00 1)
Premium mit MSDN 6.119,00 / 2.569,00 2)
Professional mit MSDN 1.199,00 / 799,00 3)
Enterprise mit MSDN 5.999,00 / 2.569,00
Professional mit MSDN 1.199,00 / 799,00

 

 

Auch Mitglieder des Microsoft Partner Networks profitieren von dieser Änderung. Im Oktober diesen Jahres wird sie automatisch im MPN Partner Licensing ausgerollt!

Kleine Freuden, die das Leben erleichtern

Manchmal sind es die einfachen Dinge, die uns am meisten begeistern, und oft brauchen sie auch gar nicht viele Wort, um beschrieben oder angekündigt zu werden. Deswegen also auch ganz kurz und bündig und ohne viele Umschweife:

Es wird im Team Foundation Server 2015 möglich sein, in allen Queries mit dem Parameter @CurrentIteration auf den aktuellen Sprint zu referenzieren!

TFS CurrentIteration

 

Das mag im ersten Moment nicht nach viel klingen, aber ich bin mir sicher, dass eingefleischte TFS Benutzer wenigstens einmal laut “Hurra” gerufen haben. Vorbei sind die Zeiten in denen Queries nach jedem Sprint angepasst werden mussten um eine aktuelle Übersicht zu haben, oder in denen alternative Werte herangezogen werden mussten um den gegenwärtigen Sprintstatus zu sehen.

Die Änderung wurde zusammen mit einigen weiteren Anpassungen im Bereich Kanban Karten, der Anzeige von Bugs im Taskboard und Syntax Highlighting für XML, Sass, Objective-C und R im Webeditor, in einem vor kurzen veröffentlichen Blogeintrag bekannt gegeben. Die weiteren Änderungen werden vorerst im Visual Studio Online (VSO) eingepflegt, aber sollten auch in die finale Version des TFS 2015 Einzug erhalten.

Einfaches Buildmanagement gibt es nicht! Oder doch?

Man kennt es ja: Nach langer schwerer Arbeit ist das Design endlich abgenommen, die Architektur fest geklopft, der Code (fast) vollkommen fehlerfrei und der Kunde ist vorerst zufrieden. Nur noch “schnell” den Build konfigurieren und endlich ist man für die nächsten Jahre des Lebenszyklus der Anwendung gerüstet.

Doch leider ist es in der Praxis nicht ganz so einfach. Skripte müssen erstellt und gepflegt werden, verschiedene Konfigurationen gilt es zu berücksichtigen und wenn alles funktioniert hat und man zum nächsten Projekt übergegangen ist, fragt man sich nach fünf Monaten, wer die Änderungen am Buildprozess gemacht hat, die dafür sorgen, dass der Output für Windows 95 kompiliert und in den Papierkorb geschrieben wird und vor allem: Warum?

Mit dem TFS 2015 und in Zukunft auch Visual Studio Online (VSO) wird es auf diese und weitere Fragen eine Antwort geben. Microsoft baut das Buildmanagement so um, dass nicht mehr nur die Windows Workflow Engine (XAML) verwendet werden kann, sondern, gerade im Bezug auf die Cross-Plattform-Fähigkeit von .NET Core, auch Builds für andere Platformen, wie zum Beispiel Android, Mac OSX oder Linux gebaut werden können.

Einige der Highlights sind:

  • Einfache Anpassbarkeit durch Erstellung eigener Build-Tasks oder dem Import von Community-Tasks
  • Eine Liveansicht des Buildlogs im Browser
  • Builds für verschiedene Plattformen
  • Historie und Changelog für Builddefinitionen

Die bisher genutzte Workflow-Engine wird auch in Zukunft unterstützt und die bereits existierenden Builddefinitionen funktionieren 1:1 weiterhin. Hinzu kommen allerdings noch eine ganze Reihe neuer Möglichkeiten, Buildsysteme anzusprechen:

TFS2015 Build Tasks

 

Für die glücklichen unter uns, die bereits Zugriff auf das neue Build-System in VSO haben, findet man hier den Build-Agent und hier die bereits existierenden Tasks.

Der Team Foundation Server wird also auch in diesem Bereich offener und damit noch attraktiver für alle Entwickler.

In den Schulen unterrichten sie Latein. Warum kein VBA?

Zugegeben, die Überschrift wirkt auf den ersten Blick provokant. Handelt es sich bei Latein doch um eine Sprache, die als Basis aller romanischen Sprachen mindestens die Einstiegshürde zum Erlernen dieser deutlich erleichtert. Heutige Redewendungen und auch viele Wortbedeutungen lassen sich aus der Kenntnis der Sprache Cäsars genauso ableiten, wie die Tatsache, dass die Rolle des “Kaisers” eben auf den Namen desselben Herrschers zurückzuführen ist. Achja… und für das Jura-Studium sowie das Studium der Medizin benötigt man es auch.

Und VBA? Eine tote Sprache? Genau wie Latein?

Mag sein. Nichts desto trotz haben nicht einmal Office Apps, Visual Studio Tools for Office oder selbst OLE Automation dazu geführt, dass VBA vollends in Vergessenheit geraten ist. Warum auch? Leichtgewichtiger geht es kaum: Der Visual Basic Editor (VBE) ist in die Office Produkte integriert, der Zugang ist extrem leicht, es werden keine zusätzlichen Lizenzen benötigt und sämtliche Belange von Word, Excel und Access lassen sich damit programmieren. Zudem benötigt es keine komplexen Installationssysteme und technisch gesehen auch keine Rollout-Gremien, um zeitnah Problemlösungen innerhalb einer Fachabteilung an den Start zu bekommen (was die IT Abteilung davon hält sei einmal dahingestellt).

Trotzdem. Ein ungutes Gefühl bleibt.

  • Es gibt keine integrierte Quellcodeverwaltung.
  • Unter modernen Gesichtspunkten sind viele Verhaltensweisen zunächst nicht nachvollziehbar.
  • Es gibt zwar Klassen und Interfaces (tatsächlich!), aber keine echte Polymorphie oder Funktionsüberladung.
  • Die Arbeit mehrerer Entwickler an einem Projekt gestaltet sich als sehr aufwändig.
  • Aufgrund der nur eingeschränkten Verwaltungsmöglichkeiten sind komplexe Projekte langfristig nur schlecht wartbar.
  • Die Fehlerbehandlung ist auf den ersten Blick wenig intuitiv.
  • etc.

Stellen wir uns aber der harten Realität: In großen sowie kleinen Unternehmen wird VBA innerhalb von speziell Excel und Access noch immer flächendeckend von den Fachabteilungen eingesetzt. Das Phänomen lässt sich nicht einmal auf bestimmte Branchen einschränken. Und so schnell wird sich das auch nicht ändern.

Daher liegt es in unserer Verantwortung, dafür zu sorgen, dass die Entwicklung (und damit auch unsere Dienstleistung) auch in diesem Kontext einem hohen Anspruch an Qualität gerecht wird. Quellcodeverwaltung, Nachvollziehbarkeit, Testing, Requirements-Engineering & Co sind dabei nur einige Stichworte. Und der Einsatz von VBA ist kein Grund, die modernen Prozesse zur Softwareentwicklung links liegen zu lassen.

Im Gegenteil.

Als Einstieg für die Interessierten hier ein paar Querverweise, die zeigen, dass da auch mehr geht:

In Projekten, in denen auch bei uns dann und wann mal VBA genutzt wird, verwenden wir übrigens selbstverständlich den Team Foundation Server für die Requirements, das Work Item Tracking und auch die Quellcodeverwaltung.

Neugierig? Sprechen Sie uns an!

Für 2015 schon Zertifizierungen geplant?

Training and Certification Guide screen shot 0Wer sich wie wir u.a. im Fahrwasser von Microsoft bewegt, kennt natürlich die Zertifizierungen, die sich hier erwerben lassen. Besonders spannend sind dabei für uns die Titel, die mittels unterschiedlicher Zertifizierungen zu erreichen sind. Beispielsweise der MCSD Application LifeCycle Management, bestehend aus Prüfungen zu Themen wie der Konfiguration und Administration des Team Foundation Servers, Testing und der Optimierung einer Wertschöpfungskette im Bereich der Softwareentwicklung.

Für einen Überblick über sämtliche Pfade, Möglichkeiten und auch zur Planung gibt es historisch bedingt die verschiedensten Möglichkeiten. Da Poster aber ziemlich 2010 sind, hat Microsoft mittlerweile eine eigene Windows Store App nachgelegt. Obwohl simpel gestaltet, ist sie immerhin interaktiv und ermöglicht definitiv einen hervorragenden Überblick.

Die App bekommt hier hier.

Viel Spaß dabei und viel Erfolg in 2015!

P.S.: Du bist bereits MCSD: ALM und hast Spaß dabei, Kunden auf dem Weg zu stabilen Geschäftsanwendungen zu unterstützen? Bewirb Dich jetzt!

Stabile Developer Workstation mit Server-Ambitionen

Kennt ihr das noch aus Zeiten von Windows 2000: Bei Microsoft gab es noch die Unterscheidung zwischen einem Client- und einem Server-Kernel. Bekannterweise war der Windows 2000 Server Kernel stabiler als der von Windows 2000 Workstation. Der Grund war u.a. der, dass es im Workstation Produkt diverse Shims gab, die u.a. für Kompatibilität auch zu älteren Produktversionen verantwortlich waren. Auf einem Server kommt es in erster Instanz aber auf Stabilität und Geschwindigkeit an. Entsprechend gab es seit jeher unterschiedliche Kernel, die Microsoft später aber doch zusammengefasst hat. Für die Client-Benutzer ein Segen, denn auch sie kamen nun in den Genuss so richtig stabiler Betriebssysteme.

Für die Server-Benutzer sollte das aber nicht dazu führen, dass sie statt einer aufgeräumten, performanten Serverumgebung sich nun auf einmal auch in einer "Klicki-Bunti" Welt zurecht finden sollten. Daher werden seitdem verschiedene Features der Client-Versionen in den entsprechenden Serverprodukten abgeschaltet, bzw. gar nicht erst installiert.

Für uns Entwickler wiederum aber interessant sind Serversysteme dennoch. Denn sie gelten weiterhin als stabile Systeme, die darüber hinaus natürlich auch über Rollen verfügen, die dann und wann für uns in der Entwicklung gerade von Business Applikationen wichtig sein können. Was läge also näher, als sich ein System zurechtzukonfigurieren, das auf einem Windows Server Produkt basiert, sich aber "anfühlt" wie ein Client-System?

Windows Server 2012 Workstation

Den Gedanken hatten auch andere und so gibt es seit Windows 2000 Anleitungen, wie man ein Server-OS derart konfiguriert, dass es das vom Client her bekannte Look&Feel besitzt. Inklusive Klicki-Bunti. :)

Während uns Windows 2000 eher nicht mehr interessiert, findet sich entsprechend auch für Windows Server 2012 eine entsprechende Anleitung, die ihr hier findet: http://www.win2012workstation.com/.

Darin wird Schritt für Schritt erklärt, wie sich folgende Features nachinstallieren, bzw. konfigurieren lassen:

  • Treiber, Sprache, Computername und Informationen zu dem Besitzer des Systems
  • WLAN Konfiguration und Sound
  • Deaktivieren von STRG-ALT-ENTF beim Login, der Passwort Restriktionen und des eher lästigen Shutdown-Event-Trackers
  • Deaktivieren der IE Enhanced Security (ESC)
  • Konfiguration des Systems für performante Apps (standardmäßig liegt der Fokus im Server OS eher bei performanten Systemdiensten)
  • Themes, Aero Cursors (Endlich! Klicki Bunti!)
  • Windows 8 Modern UI Apps, die Default Apps und der Windows 8 IE
  • Ausschalten der Data Execution Prevention (DEP) und Structured Exception Handling Overwrite Protection (SEHOP)
  • u.v.m

Converter

Falls der Aufwand für den einen oder anderen zu hoch ist, gibt es gute Neuigkeiten: Ein Team von Enthusiasten hat einen Converter entwickelt, mit dem sich die Schritte automatisieren lassen. Somit ist ein Windows Server 2012 nach der Initialinstallation (die ja selbst nur noch ein Klacks ist) im Nu in ein Workstation-artiges System verwandelt: http://www.win2012workstation.com/converter/.   

Frustfreie Web.config auch im Team

Eine sehr nützliche Funktion im Visual Studio und MSBuild ist die Möglichkeit, bei der Veröffentlichung von Webseiten die Web.config entsprechend der gewählten Zielkonfiguration automatisch anpassen zu lassen. Der Vorgang nennt sich Transformation und beschreibt im Prinzip nichts weiter als anhand von Transform-Dateien die Web.config zu verändern. Das Prinzip ist identisch mit der bekannten Xml Transformation mittels XSLT (in Visual Studio heißt nur alles wieder mal anders).

Während das Konzept beim Web-Publishing bereits sinnvoll ist (um z.B. für Debug, Release, Stage, etc. unterschiedliche Konfigurationen parat zu haben), wäre der Einsatz während der Entwicklung selbst allerdings genauso praktisch. Beispielsweise könnten einzelne Teammitglieder unterschiedliche lokale Entwickler-Datenbankinstanzen haben, die sich auf die ConnectionStrings in der Web.config auswirken. Das Problem, das daraus i.d.R. entsteht, ist, dass jeder Entwickler die Web.config bei sich lokal anpasst und dadurch auscheckt. Sollte sie dann “aus Versehen” mal mit eingecheckt werden, klappt bei anderen Entwicklern im Zweifelsfall die Datenbankverbindung nicht mehr, sobald sie ihren Workspace aktualisieren. Im schlimmsten Fall werden dadurch Basisänderungen an der Web.config überschrieben wenn man nicht aufpasst.

Die Lösung für dieses Problem wäre, jedem Entwickler eine eigene Transform-Datei bereitzustellen und dafür zu sorgen, dass personenabhängige Einstellungen ausschließlich darin stattfinden. Dazu muss die Web.config allerdings zur Compilezeit generiert werden und darf zudem nicht mehr Teil der Quellcodeverwaltung sein.

Wie das im Einzelnen funktioniert zeigt folgende Schritt für Schritt Anleitung:

Das Publishing Target und die Config Transformation lokal konfiguriert

Kostenlose Aufzeichnungen der #msts14 - Jetzt weiterbilden!

Nur kurze Zeit nach der Microsoft Technical Summit 2014 wurden auf Channel 9 wie versprochen die Aufzeichnungen zu den Sessions veröffentlicht. Sowohl die Videos als auch die Präsentationen sind übersichtlich in der Agenda zu der Veranstaltung verlinkt.

Unseren Beitrag zum Microsoft Fakes Isolation Framework gibt es dort ebenfalls zu sehen. Viel Spaß beim Anschauen (wir hatten auf jeden Fall Spaß beim Halten der Session)! 

Über die Autoren

Christian Jacob ist Leiter des Geschäftsbereiches Softwarearchitektur und -entwicklung und zieht als Trainer im Kontext der .NET Entwicklung sowie ALM-Themen Projekte auf links.

Marcus Jacob fokussiert sich auf die Entwicklung von Office-Addins sowie Windows Phone Apps und gilt bei uns als der Bezwinger von Windows Installer Xml.

Martin Kratsch engagiert sich für das Thema Projektmanagement mit dem Team Foundation Server und bringt mit seinen Java- und iOS-Kenntnissen Farbe in unser ansonsten von .NET geprägtes Team.

Aktuelle Kommentare

Comment RSS