web-dev-qa-db-fra.com

Déploiement d'une application Angular 2 à partir de Visual Studio 2017

J'utilise Visual Studio 2017 et j'ai développé deux applications Angular 2. Le premier est pur Angular 2 sans code backend (les données proviennent des services wcf). La seconde est une application SPA angulaire 2 hébergée dans une application MVC (.net 4.6). Ils fonctionnent tous les deux très bien et je peux les exécuter et les éditer dans VS2017 sans aucun problème. Le problème vient du déploiement sur un serveur IIS. À l'heure actuelle, je regroupe les composants du répertoire node_modules dans des fichiers .js à l'aide de gulp. Je copie ensuite manuellement tous les fichiers de l'application (y compris les fichiers groupés gulp) sur un serveur. C'est un processus laborieux et j'aimerais trouver un meilleur moyen. J'espérais que Visual Studio aurait fourni des modèles pour créer les deux types d'applications angulaires 2 décrites ci-dessus et également pour publier des fonctionnalités permettant de regrouper l'application, y compris les composants node_module nécessaires d'un simple clic, mais ayant été déçus. Quelle est ma meilleure option pour me rapprocher le plus possible de cette fonctionnalité? S'il vous plaît aider.

visual-studioangularnode-modulesvisual-studio-2017
8
LanceM

Merci à tous pour les bonnes suggestions. J'ai réussi à atteindre cet objectif en suivant l'excellent article que j'ai trouvé ici: http://candordeveloper.com/2017/04/12/how-to-use-angular-cli-with-visual-studio -2017/

Cet article l'a fait assez simple et il fonctionne bien. Espérons que cela aide les autres aussi.

2
LanceM

C’est exactement le même arrangement sur lequel j’ai travaillé, le «Saint Graal» utilisant Visual Studio (2015/2017) pour développer et déboguer un front-end Angular 2 (Interface de conception matérielle), pris en charge par les points de terminaison du service WebAPI dans mon cas, avec une couche de base de données Entity Framework. Comme vous l'avez dit, il n'est pas anodin d'obtenir un régime de travail décent qui réponde à tous les besoins. Cependant, avec Visual Studio 2017, je pense disposer d’une configuration assez confortable, que je peux également déployer sur notre système de génération TFS interne.

J'utilise actuellement la base @ angular-cli, bien que cela ne soit pas nécessaire en soi. Une fois qu'il a été initialisé, vous devriez alors avoir accès aux scripts npm pour effectuer un démarrage (aka ng serve) et une construction. Dans VS2017, vous pouvez utiliser la fenêtre Task Runner (et, si nécessaire, installer l'extension NPM Task Runner Extension pour VS2017) pour configurer l'exécution de la commande "Ng serve" afin d'ouvrir votre projet. Cela va commencer le regroupement de webpack et la surveillance continue des modifications de fichiers; cette dernière partie est importante pour un environnement de débogage et de développement fluide dans VS2017, et son rattachement à l'événement d'ouverture du projet vous permet de prendre une étape supplémentaire.

J'ai ensuite désactivé la compilation TypeScript VS2017 en modifiant manuellement le fichier de projet et en ajoutant la clé suivante juste en dessous de la version TypeScript:

<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>

Je le fais pour deux raisons: avec la surveillance continue assurée par la compilation du paquet Webpack compilée pour moi, VS2017 n’a pas besoin de le faire également, ce qui me permet de garantir la compilation de TS à l’aide de l’installation du package npm de TypeScript sur le outils que VS2017 insiste parfois avec obstination pour utiliser malgré le fait que je remplace le chemin dans le menu Options.

J'utilise Chrome comme navigateur dans VS2017 en raison de la vitesse maintenant supérieure à IE11. Pour une raison quelconque, utiliser IE11 à partir du moteur de débogage de VS est très lent pour le chargement initial; Je pense que cela tient à la manière dont VS doit analyser chaque fichier individuel regroupé dans chaque ensemble Webpack. Chrome semble fonctionner comme un champion. Ironiquement, Edge fonctionne presque à la même vitesse que Chrome, mais même en 2017 avec le tout nouveau VS2017, le débogage Edge n'est pas pris en charge dans VS2017 - allez figure.

Les points d'arrêt dans les fichiers VS2017 sont touchés même lorsque Chrome exécute la navigation, ce qui constitue un bonus supplémentaire. Les seuls problèmes que j'ai rencontrés à ce sujet sont que je dois généralement débuter le débogage dans VS2017, laisser Chrome lancer mon site, puis actualiser la page immédiatement afin que VS2017 puisse analyser correctement les sources. J'ai également remarqué que j'ai tendance à devoir placer mes points d'arrêt dans les copies de mes fichiers TS qui figurent dans le bloc "Moteur de script" de l'Explorateur de solutions qui apparaît lors du débogage actif, car les points d'arrêt dans mes fichiers de solution ne le sont pas directement. semblent se déclencher sous Chrome. Je soupçonne fortement que cela est dû au fait que mes cartes mères ne compilent pas avec le chemin d'accès au fichier d'origine correct. VS2017 n'a donc aucun moyen de savoir que le fichier du "Moteur de script" est lié à un fichier spécifique de ma solution. Je travaille toujours sur celui-ci.

Le dernier casse-tête que j'ai dû résoudre pour cet arrangement est d'activer CORS de sorte que le site Web frontal (Angular) puisse se connecter à mon serveur WebAPI lors du débogage dans VS2017. Étant donné que le serveur Lite intégré de @ angular-cli héberge le serveur frontal et que VS2017 initialise IISExpress pour héberger le serveur principal, ils se trouveront sur des ports différents. J'ai dû ajouter un accès CORS à mon backend (ce que j'ai fait globalement via le fichier global.asax.cs et entouré d'indicateurs de compilation conditionnels pour s'assurer qu'il n'est utilisé que sur les versions de débogage DEV/local) pour permettre au serveur frontal de rendre le service. appels vers l'autre port sur le backend. Fonctionne comme un charme, cependant.

Edit: Pour ajouter quelque chose, j’ai un peu affiné ma pratique pour mieux prendre en charge le débogage dans VS2017. Lorsque je lance le projet CLI angulaire, je laisse généralement VS2017 créer un projet de site Web vide afin que le répertoire du projet soit créé. Je passe ensuite à une invite de commande, entre dans ce dossier et utilise l'outil CLI angulaire pour générer mon application squelette à l'aide de cette commande:

ng new -si -sg -dir . MyApp

Les arguments que j'ai spécifiés ignorent l'installation du package (puisque VS2017 peut le faire une fois que j'ai enregistré le fichier package.json une fois), ignore git (que je n'utilise pas personnellement car je travaille dans une maison TFS qui n'utilise pas git). et cible le répertoire de travail de l’application Angular (car je ne veux pas qu’il crée un niveau supplémentaire de répertoire).

Ensuite, une fois que cela est fait, j'utilise la commande ng eject de la CLI angulaire pour forcer la CLI à "éjecter" le contrôle de l'outil sur le processus de création et de regroupement de packs Web. Cela a l'outil CLI écrire tous les fichiers de configuration qu'il utilise. Je le fais parce que je dois accéder au fichier webpack.config.js pour gérer les cartes source un peu différemment.Pour DEV, dans VS2017, je modifie le fichier webpack.config.js comme suit:.

1) Ajoutez const webpack = require('webpack'); en haut

2) Commentez la ligne "devtool": "source-map"

3) Après le bloc new AotPlugin(..), j'ajoute un plugin supplémentaire:

new webpack.SourceMapDevToolPlugin({ filename: '[file].map', noSources: true, moduleFilenameTemplate: '[absolute-resource-path]', fallbackModuleFilenameTemplate: '[absolute-resource-path]' })

This seems like the magic charm for using IE11 or Chrome in VS2017 debug mode, which active debug breakpoints and Intellisense debugging. It does, however, break being able to debug directly in Chrome, mainly because this changes the path references in the sourcemaps generated by webpack to be absolute file paths on your computer. VS2017 eats that up, so it can find the source perfectly. My current plan is I'll retain the original webpack.config.js and use that for my DEV testing on our DEV webserver and our PRD builds, but use this revision here in a webpack.vs.config.js configuration with proper scripting (maybe a custom npm script) to do all my local machine DEV work with VS2017. So far...it's nearly a perfect environment for me.

10
Londovir

Pour le premier type d’application que vous avez décrit comme «pur Angular 2 sans code d’arrière-plan», vous pouvez utiliser le modèle de projet Angular CLI disponible sur Visual Studio Marketplace.

Le projet est essentiellement un projet personnalisé ASP.NET Core qui partage le dossier racine avec une application CLI Angular. Il constitue un adaptateur au moment du design entre l’expérience de développement traditionnelle dans Visual Studio et l’infrastructure fournie par Angular CLI. 

Le projet prend en charge la fonctionnalité de publication standard fournie par Visual Studio. Seuls les fichiers générés par la CLI angulaire lors de la génération, et aucune DLL, sont publiés dans la destination cible. 

Divulgation: Je suis l'auteur du modèle. Le code est disponible sur GitHub.

3
Andrey

Outre la solution acceptée, j'aimerais ajouter une suggestion à toute personne utilisant le déploiement Web IIS (ou toute autre méthode de l'outil de publication de VS) et disposant de plusieurs environnements à déployer: C'est très pratique d'utiliser les configurations de la solution VS. 

  • Ajoutez une configuration par environnement que vous souhaitez déployer.

  • Editez le fichier .csproj et modifiez la "Commande Exec" en ajoutant "$ (Nom de configuration)" au nom du script:

    <Target Name="NgBuildAndAddToPublishOutput" AfterTargets="ComputeFilesToPublish">
<Message Text=" " Importance="high" />
<Exec Command="npm run build$(ConfigurationName)" />
<ItemGroup>
  <DistFiles Include="dist\**" />
  <ResolvedFileToPublish Include="@(DistFiles->'%(FullPath)')" Exclude="@(ResolvedFileToPublish)">
    <RelativePath>%(DistFiles.Identity)</RelativePath>
    <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
  </ResolvedFileToPublish>
</ItemGroup>
</Target>

  • Editez votre package.json pour qu'il contienne un script appelé buildYourSolutionConfigName:

    {
    "scripts": {
        "buildYourSolutionConfigName": "ng build --someFlagNeeded",
        "ng": "ng",
        "start": "ng serve",
        "build": "ng build",
        ...
    }
    ...
}

Vous avez maintenant tout ce dont vous avez besoin pour que l'application soit construite conformément aux exigences de l'environnement cible. Cela vous permet de sélectionner simplement la configuration correcte dans VS et la publication Push. 

1
Devosaur

Une option consiste à échafauder l'application à l'aide de la CLI angulaire et d'un projet ASP.NET Core.

  1. npm install --global @angular/cli

  2. ng nouveau my-app

  3. Modifiez la variable outDir dans le fichier .angular-cli.json pour qu'elle pointe vers le répertoire /wwwroot de votre projet.

  4. Configurez votre application en tant que serveur de fichiers statique.

    void ConfigureServices(...) {
   app.AddMvc(); // Microsoft.AspNetCore.Mvc
}

void Configure(app) {
   app.UseMvcWithDefaultRoute();
   app.UseDefaultFiles(); // Microsoft.AspNetCore.StaticFiles
   app.UseStaticFiles();
}

  5. Cliquez avec le bouton droit sur le projet et sélectionnez PublishSélectionnez Azure App Service ou IIS/FTP et suivez les instructions à l'écran.

Voici un tutoriel: https://medium.com/@levifuller/building-an-angular-application-with-asp-net-core-in-visual-studio-2017-visualized-f4b163830eaa

0
Levi Fuller