Von den beiden Treffen in Köln und Düsseldorf findet ihr anbei die Folien zu den Vorträgen.
Einleitung zu Infrastructure as Code von Andrej Doms
Infrastructure as Code by Jason Bourne – IaC mit dem Microsoft Technologiestack von Denis Buco
Von den beiden Treffen in Köln und Düsseldorf findet ihr anbei die Folien zu den Vorträgen.
Einleitung zu Infrastructure as Code von Andrej Doms
Infrastructure as Code by Jason Bourne – IaC mit dem Microsoft Technologiestack von Denis Buco
Nun ist es (endlich) da: Visual Studio 2017!
Entsprechend dem Motto “Cloud First” gibt es auch nur einen Web-Installer zum Download und nicht wie früher alternativ auch ein ISO-Image.
Wenn man aber mehrere Rechner hat, die man mit Visual Studio beglücken will, dann wäre es ja doch praktisch, das ganze nur einmal herunter zu laden und dann mehrfach z.B. von einem lokalen File-Share aus zu installieren.
Glücklicherweise geht das!
Zunächst also einmal die Web-Installer herunterladen. Entweder von den öffentlichen Seiten oder wenn man ein MSDN-Abo hat, dann kann man das auch über seine MSDN-Benefits laden (aber auch hier bekommt man nur einen Web-Installer).
Danach kann man auf der Kommandozeile mit
vs_enterprise.exe –layout d:\vs2017offline
sich die komplette Installation herunterladen. Das wird einen entsprechenden Client starten, der alle notwendigen Pakete herunterlädt.
Ich habe mal direkt nur die Sprachen Deutsch und Englisch heruntergeladen
vs_enterprise.exe --layout C:\vs2017offline --lang en-US de-DE
Aber Achtung: dieser Download sind schon knapp 20GB!
Ansonsten: happy Visual Studio 2017 Coding!
Mehr Infos:
Vor einiger Zeit wurde ich gefragt: “Wie kann ich eigentlich eine SharePoint(-Hosted) App debuggen?”.
Die erste Antwort ist natürlich: Developer Tools! Alle Browser verfügen heute über Developer-Tools, die das Debugging von JavaScript Anwendungen erlauben.
Wenn ich die Anwendung im Browser ausführe kann ich in den Quellcode springen und dort – wie in Visual Studio – Breakpoints setzen. Anschließend muss ich die Seite ggf. noch einmal laden, damit der JavaScript-Code noch einmal ausgeführt wird und mein Breakpoint erreicht wird.
Anschließend kann ich den Wert von Variablen ansehen oder den Call-Stack betrachten und natürlich kann ich durch meinen Code-Steppen und genau die Ausführung meines Codes untersuchen.
Es gibt aber auch noch einen andere Weg: Visual Studio!
Wenn ich den IE als Browser für meine Anwendung verwende, dann kann ich meine Breakpoints auch direkt in Visual Studio in meinem JavaScript Code setzen. (Wenn man mehrere Browser installiert hat, habe ich in einem früheren Beitrag beschrieben, wie ich in einem SharePoint-App-Projekt den zu verwendenden Browser festlegen kann).
Anschließend kann ich meine Anwendung direkt in Visual Studio starten und sobald ich meinen Breakpoint erreiche kann ich meinen JavaScript Code in Visual Studio debuggen – mit alle Debugging-Funktionen die ich in Visual Studio zur Verfügung habe.
Ein Vorteil bei der Verwendung von Visual Studio ist, dass ich nicht zunächst die JavaScript Datei einmal im Browser geladen haben muss um den Breakpoint zu setzten.
Als Web-Entwickler bin ich es inzwischen gewohnt, dass ich in Visual Studio beim Starten meiner Web-Anwendung auswählen welcher Browser für die Anzeige verwendet werden soll.
Leider sieht das Start-Button bei einem SharePoint-Projekt ein wenig anders aus.
Es wird immer der Browser verwendet, den ich als Default-Browser in Windows eingestellt habe. Schade wenn ich die Anwendung mal mit einem anderen Browser testen will – dann muss ich den Browser manuell starten und die URL per Copy & Paste dort einfügen; insbesondere weil die URL bei SharePoint-Hosted Apps ja nun auch nicht gerade intuitiv ist.
Aber es gibt eine Lösung. Wenn ich die Projekteigenschaften anzeige, dann kann ich bei SharePoint-Projekten auswählen welcher Browser beim Starten verwendet werden soll.
Super!!