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

c'est exactement le même arrangement que j'ai travaillé à travers, avec le "Saint Graal" qui utilise Visual Studio (2015/2017) pour développer et déboguer un front-end 2 angulaire (Material Design UI), soutenu par des points finaux de service WebAPI dans mon cas, avec une couche de base de données Entity Framework. Comme vous l'avez dit, ce n'est pas anodin d'avoir un emploi décent qui convient à tous les besoins. Cependant, avec Visual Studio 2017, je crois que j'ai une configuration assez confortable qui fonctionne, que je peux également déployer à notre système de construction TFS maison.

j'utilise, actuellement, la base @angular-cli, bien que cela en soi n'est pas nécessaire. Une fois qu'il a été initialisé, vous devriez alors avoir accès aux scripts npm pour effectuer un démarrage (alias ng Server) et une construction. Dans VS2017, vous pouvez utiliser la fenêtre Task Runner (et, si nécessaire, installer L'Extension npm Task Runner pour VS2017) pour configurer l'exécution de la commande "ng serve" ouvrir l'ouverture de votre projet. Qui va commencer le webpack bundling et continue surveiller les changements de fichiers; cette dernière partie est importante pour un débogage et un environnement de développement en douceur dans VS2017, et la lier à l'événement d'ouverture du projet prend un pas de plus de vos mains.

je désactive alors la compilation typeScript VS2017 en éditant manuellement le fichier du projet et en ajoutant la touche suivante juste au-dessous de la version TypeScript:

<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>

je le fais pour deux raisons: avec la surveillance continue par le bundler de Webpack qui gère la compilation pour moi, il y a pas besoin de VS2017 pour le faire aussi, et cela me permet de m'assurer que je compile TS en utilisant l'installation du paquet npm de typescript sur les outils que VS2017 insiste parfois obstinément à utiliser malgré le fait que je passe le chemin dans le menu Options.

J'utilise Chrome comme navigateur dans VS2017 en raison de la vitesse maintenant sur IE11. Pour une raison ou une autre, utiliser IE11 du moteur de débogage de VS fonctionne très lentement pour le chargement initial; je crois que C'est à cause de la façon dont VS doit analyser chaque fichier individuel qui est regroupé dans chaque paquet webpack. Chrome semble fonctionner comme un champion. Ironiquement, Edge tourne à peu près à la même vitesse que Chrome, mais même en 2017 avec la toute nouvelle VS2017, le débogage Edge n'est pas pris en charge par VS2017 - go figure.

les points de rupture dans les fichiers VS2017 sont touchés même lorsque Chrome exécute la navigation, ce qui est un joli bonus. Les seuls problèmes que j'ai vu à cela sont que je dois généralement commencer à déboguer dans VS2017, laisser Chrome lancer mon site, puis rafraîchir la page immédiatement afin pour VS2017 de bien analyser les sources. J'ai également remarqué que j'ai tendance à mettre mes points de rupture dans les copies de mes fichiers TS qui sont affichés dans le bloc "moteur de script" de L'Explorateur de solutions qui apparaît lors du débogage actif, car le breakpointing dans Mes fichiers solution ne semble pas se déclencher directement sous Chrome. Je soupçonne fortement que c'est parce que mes sourcemaps ne compilent pas avec le bon chemin de fichier original, donc VS2017 n'a aucun moyen de savoir que le fichier dans le " script Moteur " se lie à un dossier spécifique dans ma solution. Je travaille toujours sur celui-ci.

le dernier casse-tête que j'ai eu à résoudre pour cet arrangement est d'activer CORS de sorte que l'avant du site web (angulaire) peut se connecter à mon serveur WebAPI pendant le débogage dans VS2017. Comme le serveur Lite intégré de @angular-cli héberge la partie frontale, et que VS2017 démarre IISExpress pour héberger la partie arrière, ils seront sur différents ports. J'ai dû ajouter L'accès CORS à mon backend (ce que j'ai fait globalement via le mondial.asax.cs fichier, et enveloppé dans des drapeaux de compilation conditionnelle pour s'assurer qu'il est seulement utilisé sur DEV/locales debug construit) pour permettre à l'avant de faire des appels de service à l'autre port sur le backend. Fonctionne comme un charme.

Edit: pour ajouter à cela, j'ai peaufiné ma pratique un peu pour mieux supporter le débogage dans VS2017. Lorsque je lance le projet de CLI angulaire, je laisse généralement VS2017 faire un projet de site web vide de sorte que le projet le répertoire est créé. Je passe ensuite à l'invite de commande, je rentre dans ce dossier, et j'utilise L'outil CLI angulaire pour générer mon application squelette en utilisant cette commande:

ng new -si -sg -dir . MyApp

les arguments que j'ai spécifiés sautent l'installation du paquet (puisque VS2017 peut le faire une fois que j'ai sauvegardé le paquet.JSON file once), sauter 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 pour l'application angulaire (parce que je ne veux pas qu'il crée un niveau supplémentaire de répertoire).

puis, une fois que c'est fait, j'utilise des CLI's angulaires ng eject commande pour forcer le CLI à "éjecter" le contrôle de l'outil sur le processus de empaquetage et de compilation webpack. Cela a le CLI outil d'écrire tous les fichiers de configuration qu'il utilise. Je fais ça parce que j'ai besoin d'entrer dans le webpack.config.fichier js pour gérer sourcemaps un peu différemment.

pour DEV, dans VS2017, je modifie le webpack.config.js comme suit:

1) Ajouter const webpack = require('webpack'); pour le top

2) en Commentaire la ligne "devtool": "source-map"

3) Après le new AotPlugin(..) bloquer, j'ai ajouter un plugin:

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

cela semble être le charme magique pour utiliser IE11 ou Chrome en mode de débogage VS2017, qui active les points de rupture de débogage et le débogage Intellisense. Il ne, cependant, casser la possibilité de déboguer directement dans Chrome, principalement parce que cela change les références de chemin dans les sourcemaps générés par webpack pour être des chemins de fichier absolus sur votre ordinateur. VS2017 eats pour trouver parfaitement la source. Mon plan actuel est de conserver le webpack d'origine.config.js et utilisez cela pour mes tests DEV sur notre serveur web DEV et nos constructions PRD, mais utilisez cette révision ici dans un webpack.vs config.configuration de JS avec script approprié (peut-être un script npm personnalisé) pour faire tout mon travail de développement de machine locale avec VS2017. Jusqu'à maintenant...c'est presque un environnement parfait pour moi.

Pour le premier type d'application que vous l'avez décrite comme "pur Angulaire 2 avec pas de backend code", vous pouvez utiliser le Angulaire de la CLI modèle de projet

le projet est essentiellement un ASP.NET projet Core qui partage le dossier racine avec une application de CLI angulaire et est un adaptateur de temps de conception entre L'expérience de développement traditionnelle dans Visual Studio et l'infrastructure fournie par CLI angulaire.

en plus de la solution acceptée, j'aimerais ajouter une suggestion pour toute personne qui utilise IIS Web deploy (ou l'une des autres méthodes de L'outil de publication VS) et qui a plus d'un environnement à déployer: c'est plutôt pratique d'utiliser les configurations de la solution VS.

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

• modifier le .fichier csproj et modifier la commande "Exec", en ajoutant "$(ConfigurationName) " au script nom:

  <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>
  

• modifier votre paquet.json doit contenir un script appelé buildYourSolutionConfigName:

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

Maintenant, vous avez tout ce dont vous avez besoin pour obtenir l'application construit selon les exigences de l'environnement cible. Cela vous permet simplement de sélectionner la configuration correcte dans VS et de pousser publier.

une option est de scafold l'application en utilisant le CLI angulaire et un ASP.NET projet de base.

1. npm install --global @angular/cli

2. ng nouveau mon application

3. Changer outDir dans le .angular-cli.json le fichier de point de votre projet /wwwroot répertoire

4. configurer votre application comme un serveur de fichiers statique.

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

5. clic-Droit sur le projet et sélectionnez Publish Sé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