it-swarm.com.ru

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

Я использую Visual Studio 2017 и разработал два Angular 2 приложения. Первый - чистый Angular 2 без внутреннего кода (данные поступают из сервисов wcf). Вторым является приложение Angular 2 SPA, размещенное в приложении MVC (.net 4.6). Они оба отлично работают, и я могу запускать и редактировать их в VS2017 без проблем. Проблема заключается в развертывании на сервере IIS. На данный момент я объединяю компоненты из каталога node_modules в файлы .js, используя gulp. Затем я вручную копирую все файлы для приложения (включая файлы в комплекте gulp) на сервер. Это трудоемкий процесс, и я хотел бы найти лучший путь. Я надеялся, что Visual Studio предоставит шаблоны для создания двух типов angular 2 приложений, описанных выше, а также опубликует функциональность для связывания приложения, включая необходимые компоненты node_module, одним нажатием кнопки, но разочаровался. Какой мой лучший вариант, чтобы максимально приблизиться к этой функциональности? Пожалуйста помоги.

8
LanceM

Спасибо всем за отличные предложения. Мне удалось добиться этого, следуя прекрасной статье, которую я нашел здесь: http://candordeveloper.com/2017/04/12/how-to-use-angular-cli-with-visual-studio -2017/

Эта статья сделала это довольно простым и хорошо работает. Надеюсь, это поможет и другим.

2
LanceM

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

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

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

<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>

Я делаю это по двум причинам: благодаря постоянному мониторингу, выполняемому компилятором Webpack для меня, VS2017 также не нуждается в этом, и это позволяет мне убедиться, что я компилирую TS с помощью установки пакета npm из TypeScript поверх инструменты, которые VS2017 иногда упорно настаивает на использовании, несмотря на мои перекрывая путь в меню Options.

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

Точки останова в файлах VS2017 достигаются даже тогда, когда Chrome запускает просмотр, что является приятным бонусом. Единственные глюки, которые я видел, это то, что я обычно должен начать отладку в VS2017, позволить Chrome запустить мой сайт, а затем немедленно обновить страницу, чтобы VS2017 правильно проанализировал исходные карты. Я также заметил, что мне, как правило, приходится ставить точки останова в копиях моих файлов TS, которые отображаются в блоке «Механизм сценариев» обозревателя решений, который появляется при активной отладке, поскольку точки останова в моих файлах решений напрямую не используются. похоже, срабатывает под Chrome. Я сильно подозреваю, что это потому, что мои исходные карты не компилируются с правильным исходным путем к файлу, поэтому VS2017 не может знать, что файл в «Механизме сценариев» связан с конкретным файлом в моем решении. Я все еще работаю над этим.

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


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

ng new -si -sg -dir . MyApp

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

Затем, как только это будет сделано, я использую команду Angular CLI ng eject, чтобы заставить CLI «выбросить» контроль инструмента над процессом объединения и сборки веб-пакетов. Это позволяет инструменту CLI записывать все файлы конфигурации, которые он использует. Я делаю это, потому что мне нужно попасть в файл webpack.config.js, чтобы немного по-другому обрабатывать исходные карты.Для DEV в VS2017 я изменяю webpack.config.js следующим образом:.

1) Добавьте const webpack = require('webpack'); в начало

2) Закомментируйте строку "devtool": "source-map"

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

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

Для первого типа приложения, описанного вами как «чистый Angular 2 без внутреннего кода», вы можете использовать шаблон проекта Angular CLI , доступный на Visual Studio Marketplace.

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

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

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

3
Andrey

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

  • Добавьте одну конфигурацию для среды, в которой вы хотите развернуть.
  • Отредактируйте файл .csproj и измените «Exec Command», добавив «$ (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>
    
  • Отредактируйте ваш package.json, чтобы он содержал скрипт с именем buildYourSolutionConfigName:

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

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

1
Devosaur

Одним из вариантов является создание приложения с помощью Angular CLI и проекта ASP.NET Core.

  1. npm install --global @angular/cli

  2. нг новое мое приложение

  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

0
Levi Fuller