Развертывание приложения Angular 2 из Visual Studio 2017

это то же самое расположение, через которое я работал, с "Святым Граалем", использующим Visual Studio (2015/2017) для разработки и отладки углового интерфейса 2 (Material Design UI), поддерживаемого конечными точками службы WebAPI в моем случае, со слоем базы данных Entity Framework. Как вы сказали, это не тривиально, чтобы получить достойную работу, которая соответствует всем потребностям. Однако с Visual Studio 2017 я считаю, что у меня есть довольно удобная настройка, которую я также могу развернуть на нашем внутренняя система сборки TFS.

в настоящее время я использую базис @angular-cli, хотя это само по себе не требуется. После его инициализации у вас должен быть доступ к сценариям npm для выполнения запуска (он же ng serve) и сборки. В VS2017 вы можете использовать окно Task Runner (и, при необходимости, установить расширение npm Task Runner для VS2017) для настройки запуска команды "ng serve" откройте открытие проекта. Это начнет связывание webpack и непрерывное мониторинг изменений файлов; последняя часть важна для плавной отладки и разработки среды в VS2017, и привязка ее к событию открытия проекта занимает один дополнительный шаг от ваших рук.

затем я отключаю компиляцию VS2017 typeScript, вручную редактируя файл проекта и добавляя следующий ключ чуть ниже версии TypeScript:

<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>

я делаю это по двум причинам: при непрерывном мониторинге с помощью компиляции webpack bundler для меня есть нет необходимости в VS2017, чтобы сделать это, а также, и это позволяет мне гарантировать, что я компилирую TS с помощью установки пакета npm typescript над инструментами, которые VS2017 иногда упорно настаивает на использовании, несмотря на мое переопределение пути в меню опций.

Я использую Chrome в качестве браузера в VS2017 из-за скорости теперь над IE11. По какой-то причине использование IE11 из механизма отладки VS работает очень медленно для начальной загрузки; я считаю, что это из-за того, как VS должен анализировать каждый отдельный файл, который в комплекте в каждой Webpack комплектации. Chrome, похоже, работает как чемпион. По иронии судьбы, Edge работает почти с той же скоростью, что и Chrome, но даже в 2017 году с новым VS2017 отладка Edge не поддерживается в VS2017 - go.

точки останова в файлах VS2017 поражаются, даже когда Chrome запускает просмотр, что является приятным бонусом. Единственные глюки, которые я видел, это то, что я обычно должен начать отладку в VS2017, пусть Chrome запустит мой сайт, а затем немедленно обновит страницу по порядку для VS2017 правильно разобрать sourcemaps. Я также заметил, что мне, как правило, приходится помещать свои точки останова в копии моих TS-файлов, которые отображаются в блоке "Scripting Engine" обозревателя решений, который появляется при активной отладке, поскольку breakpointing в моих файлах решений напрямую, похоже, не запускается в Chrome. Я сильно подозреваю, что это связано с тем, что мои исходные карты не компилируются с правильным исходным путем файла, поэтому VS2017 не может знать, что файл в " скриптах Engine " привязывается к определенному файлу в моем решении. Я все еще работаю над этим.

последняя головная боль, которую я должен был разработать для этой договоренности, - это включение CORS, чтобы передний конец веб-сайта (угловой) мог подключаться к моему бэкэнду WebAPI во время отладки в VS2017. Поскольку встроенный lite-сервер @angular-cli содержит передний конец, а VS2017 загружает IISExpress для размещения бэкэнда, они будут находиться на разных портах. Мне пришлось добавить доступ CORS к моему бэкэнду (который я сделал глобально через глобальный.асакс.cs-файл и завернутые в условные флаги компиляции, чтобы гарантировать, что он используется только в dev/локальных отладочных сборках), чтобы позволить интерфейсу совершать вызовы службы к другому порту на бэкэнде. Хотя работает как заклинание.

Edit: чтобы добавить к этому немного, я немного усовершенствовал свою практику, чтобы лучше поддерживать отладку в VS2017. Когда я запускаю проект Angular CLI, я обычно позволяю VS2017 сделать пустой проект веб-сайта, чтобы каталог проекта создан. Затем я перехожу к командной строке, попадаю в эту папку и использую инструмент Angular CLI для создания моего приложения скелета с помощью этой команды:

ng new -si -sg -dir . MyApp

аргументы, которые я указал, пропускают установку пакета (так как VS2017 может сделать это после сохранения пакета.JSON-файл один раз), пропустить git (который я лично не использую, так как я работаю в доме TFS, который не использует git) и нацелен на рабочий каталог для углового приложения (потому что я не хочу, чтобы он создавал дополнительный уровень из каталога).

затем, как только это будет сделано, я использую угловые Кинк-х ng eject команда, чтобы заставить CLI "извлечь" контроль инструмента над процессом связывания и сборки webpack. Это имеет инструмент CLI выписать все файлы конфигурации, которые он использует. Я делаю это потому что мне нужно попасть в webpack.конфиг.JS-файл для обработки исходных карт немного по-другому.

для DEV, в VS2017, я изменяю webpack.конфиг.js следующим образом:

1) Добавить const webpack = require('webpack'); к топ!--9-->

2) закомментировать строку "devtool": "source-map"

3) после new AotPlugin(..) блок, я добавляю еще один плагин:

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

это похоже на волшебный шарм для использования IE11 или Chrome в режиме отладки VS2017, который активирует точки останова отладки и отладку Intellisense. Тем не менее, это нарушает возможность отладки непосредственно в Chrome, главным образом потому, что это изменяет ссылки на пути в исходных картах, генерируемых webpack, чтобы быть абсолютными путями файлов на вашем компьютере. VS2017 ест это вверх, так что он может найти источник идеально. Мой текущий план-я сохраню оригинальный webpack.конфиг.js и используйте это для моего тестирования DEV на нашем веб-сервере DEV и наших сборках PRD, но используйте эту ревизию здесь, в webpack.и конфиг.конфигурация js с правильным сценарием (возможно, пользовательский сценарий npm), чтобы сделать всю мою локальную машину DEV работать с VS2017. Пока ... это почти идеальная среда для меня.

для первого типа приложения, описанного вами как "чистый угловой 2 без бэкэнд-кода", Вы можете использовать угловой шаблон проекта CLI доступно на рынке Visual Studio.

проект по существу подгонянный ASP.NET основной проект, который разделяет корневую папку с приложением Angular CLI и является адаптером времени разработки между традиционным опытом разработки в Visual Studio и инфраструктурой, предоставляемой Angular CLI.

проект поддерживает стандартную функцию публикации, предоставляемую Visual Studio. Только файлы, созданные Angular CLI во время сборки, и никакие библиотеки DLL не публикуются в целевом назначении.

раскрытие: я являюсь автором шаблона. Код доступен на GitHub.

в дополнение к принятому решению я хотел бы добавить предложение для всех, кто использует IIS Web deploy (или любой другой метод в инструменте публикации VS), и имеет более одной среды для развертывания: довольно аккуратно использовать конфигурации решения VS.

• добавьте одну конфигурацию в среду, в которую вы хотите развернуть.

• редактировать .файл csproj и измените "команду Exec", добавив" $(ConfigurationName) " в скрипт имя:

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

• изменить ваш пакет.json содержит скрипт с именем buildYourSolutionConfigName:

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

теперь у вас есть все необходимое, чтобы получить приложение, построенное в соответствии с требованиями целевой среды. Это позволяет просто выбрать правильную конфигурацию в VS и нажать publish.

один вариант ремонтина применение используя Угловое CLI и ASP.NET основной проект.

1. установка npm --global @angular/cli

2. ng новый my-app

3. изменить outDir на .angular-cli.json файл, чтобы указать на/wwwroot каталог

4. настройте приложение как статический файловый сервер.

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

5. Правой Кнопкой Мыши на проекте и выберите Publish Выберите Azure App Service или IIS/FTP и следуйте инструкциям на экране

вот учебник: https://medium.com/@levifuller/building-an-angular-application-with-asp-net-core-in-visual-studio-2017-visualized-f4b163830eaa