Bereitstellen einer Angular 2-Anwendung von Visual Studio 2017

Danke an alle für die tollen Vorschläge. Ich habe es geschafft, dies zu erreichen, indem ich dem ausgezeichneten Artikel folgte, den ich hier fand: Ссылка

Dieser Artikel hat es ziemlich einfach gemacht und es funktioniert gut. Hoffentlich hilft das auch anderen.

Dies ist genau das gleiche Arrangement, mit dem ich gearbeitet habe. Der "Heilige Gral" verwendet Visual Studio (2015/2017), um ein Angular 2-Frontend (Material Design UI) zu entwickeln und zu debuggen, das von WebAPI unterstützt wird Service-Endpunkte in meinem Fall mit einem Entity Framework-Datenbank-Layer. Wie Sie sagten, ist es nicht trivial, ein anständiges Arbeitsarrangement zu erhalten, das allen Bedürfnissen entspricht. Ich glaube jedoch, dass ich mit Visual Studio 2017 eine recht komfortable Einrichtung habe, die ich auch in unserem hauseigenen TFS-Build-System einsetzen kann.

Ich verwende derzeit die @ angular-cli-Basis, obwohl das an sich nicht erforderlich ist. Sobald es initialisiert wurde, sollten Sie dann Zugriff auf die npm-Skripte haben, um einen Start (auch als "Serving" bezeichnet) und einen Build durchzuführen. In VS2017 können Sie das Fenster Task Runner (und, falls erforderlich, installieren Sie das Fenster NPM Task Runner Extension für VS2017) verwenden, um die Ausführung des Befehls "ng serve" zu konfigurieren, um Ihre Projektöffnung zu öffnen. Das beginnt mit der Bündelung und kontinuierlichen Überwachung des Webpacks für Dateiänderungen. Der letzte Teil ist wichtig für eine reibungslose Debugging- und Entwicklungsumgebung in VS2017, und die Bindung an die Eröffnungsveranstaltung des Projekts nimmt Ihnen einen zusätzlichen Schritt ab.

Ich deaktiviere dann das VS2017 TypScript-Kompilieren, indem ich die Projektdatei manuell bearbeite und den folgenden Schlüssel direkt unter der TypeScript-Version hinzufüge:

Ich mache das aus zwei Gründen: Mit der kontinuierlichen Überwachung durch den Webpack-Bundler, der die Kompilierung für mich durchführt, ist VS2017 nicht nötig, und ich kann damit sicherstellen, dass ich TS mit der npm-Paketinstallation von typescript über die Tools, die VS2017 manchmal hartnäckig darauf besteht, trotz der Überschreibung des Pfades im Optionsmenü zu verwenden.

Ich verwende Chrome als meinen Browser in VS2017 wegen der Geschwindigkeit jetzt über IE11. Aus irgendeinem Grund läuft die Verwendung von IE11 von VS Debugging-Engine wirklich langsam für die erste Belastung; Ich glaube, das liegt daran, dass VS jede einzelne Datei analysieren muss, die in jeder Webpack-Bündelung gebündelt ist. Chrome scheint es wie ein Champion zu führen. Ironischerweise läuft Edge fast genauso schnell wie Chrome, aber selbst im Jahr 2017 mit dem brandneuen VS2017 wird das Edge-Debugging in VS2017 nicht unterstützt - siehe Abbildung.

Breakpoints in VS2017-Dateien werden auch dann getroffen, wenn Chrome das Browsen ausführt, was ein netter Bonus ist. Die einzigen Fehler, die ich dabei gesehen habe, sind, dass ich in VS2017 normalerweise mit dem Debuggen beginnen muss, Chrome meine Website starten lassen und dann die Seite sofort aktualisieren soll, damit VS2017 die Quellkarten ordnungsgemäß analysieren kann. Ich habe auch bemerkt, dass ich meine Haltepunkte in den Kopien meiner TS-Dateien platzieren muss, die im Block "Scripting Engine" des Projektmappen-Explorers angezeigt werden, der beim aktiven Debugging erscheint, da Breakpointing in meinen Projektdateien dies nicht tut scheinen unter Chrome zu triggern. Ich vermute stark, dass dies daran liegt, dass meine Quellkarten nicht mit dem korrekten ursprünglichen Dateipfad kompiliert werden, weshalb VS2017 nicht wissen kann, dass die Datei in der "Scripting Engine" mit einer bestimmten Datei in meiner Lösung verknüpft ist. Ich arbeite immer noch an diesem.

Der letzte Kopfschmerz, den ich für diese Anordnung haben musste, ist die Aktivierung von CORS, damit sich das Frontend der Website (Angular) während des Debuggens in VS2017 mit meinem WebAPI-Backend verbinden kann. Da der integrierte Lite-Server von @ angular-cli das Frontend hostet und VS2017 IISExpress als Host für das Back-End bootet, befinden sie sich an verschiedenen Ports. Ich musste CORS-Zugriff auf mein Backend hinzufügen (was ich global über die Datei global.asax.cs getan habe und in bedingte Kompilierungsflags eingeschlossen wurde, um sicherzustellen, dass es nur für DEV / lokale Debug-Builds verwendet wird), damit das Frontend den Dienst ausführen kann ruft den anderen Port im Backend auf. Funktioniert aber wie ein Zauber.

Bearbeiten: Um das etwas zu ergänzen, habe ich meine Übung ein wenig verfeinert, um Debugging in VS2017 besser zu unterstützen. Wenn ich das Angular CLI-Projekt starte, lasse ich VS2017 normalerweise ein leeres Website-Projekt erstellen, so dass das Projektverzeichnis erstellt wird. Ich blende dann zu einer Eingabeaufforderung, komme in diesen Ordner und benutze das Angular CLI-Tool, um meine Skeleton-Anwendung mit diesem Befehl zu generieren:

Die Argumente, die ich angegeben habe, überspringen Paketinstallation (da VS2017 das tun kann, sobald ich die package.json Datei einmal speichere), überspringe git (was ich persönlich nicht benutze, da ich in einem TFS-Haus arbeite, das nicht funktioniert Verwenden Sie git) und richtet sich an das Arbeitsverzeichnis für die Angular-Anwendung (weil ich nicht möchte, dass es eine zusätzliche Ebene des Verzeichnisses erstellt).

Sobald dies erledigt ist, verwende ich den Befehl ng eject von Angular CLI, um zu erzwingen, dass die CLI die Kontrolle über den Webpack-Bündelungs- und -Build-Prozess ausgibt. Dadurch schreibt das CLI-Tool alle verwendeten Konfigurationsdateien aus. Ich mache das, weil ich in die Datei webpack.config.js gehen muss, um Sourcemaps etwas anders zu handhaben.

Für DEV modifiziere ich in VS2017 die Datei webpack.config.js wie folgt:

1) Fügen Sie const webpack = require('webpack'); nach oben

2) Kommentieren Sie die Zeile "devtool": "source-map"

3) Nach dem new AotPlugin(..) -Block füge ich ein weiteres Plugin hinzu:

Dies scheint der magische Reiz für die Verwendung von IE11 oder Chrome im VS2017-Debug-Modus zu sein, der Debug-Breakpoints und Intellisense-Debugging aktiviert. Es ist jedoch nicht möglich, direkt in Chrome zu debuggen, hauptsächlich weil dadurch die Pfadreferenzen in den Quellkarten, die von Webpack generiert werden, zu absoluten Dateipfaden auf Ihrem Computer geändert werden. VS2017 isst das auf, damit es die Quelle perfekt finden kann. Mein aktueller Plan ist, dass ich die ursprüngliche Datei webpack.config.js beibehalte und diese für meine DEV-Tests auf unserem DEV-Webserver und unseren PRD-Builds verwende, aber verwende diese Revision hier in einer webpack.vs.config.js-Konfiguration mit korrektem Scripting ( vielleicht ein benutzerdefiniertes npm-Skript), um alle meine lokale Maschine DEV arbeiten mit VS2017. Bis jetzt ... es ist fast eine perfekte Umgebung für mich.