私はVisual Studio 2017を使用して、2つのAngular 2アプリケーションを開発しました。1つ目は、純粋なAngular 2で、バックエンドコードなしです(データはwcfサービスから取得されます)。 2番目はAngular 2 MVCアプリケーション(.net 4.6)でホストされているSPAアプリケーションです。どちらも問題なく動作し、VS2017で問題なく実行および編集できます。問題は、 IISサーバー。現時点では、node_modulesディレクトリのコンポーネントをgulpを使用して.jsファイルにバンドルしています。次に、アプリケーションのすべてのファイル(gulpバンドルファイルを含む)を手動でコピーしています。 )をサーバーに送信します。これは骨の折れるプロセスであり、より良い方法を見つけたいと思います。VisualStudioが上記の2つのタイプのangular 2アプリケーションを作成するためのテンプレートを提供することを望んでいました。また、ボタンをクリックするだけで必要なnode_moduleコンポーネントを含むアプリをバンドルする機能を公開しますが、失望しました。この機能は可能な限り?助けてください。
素晴らしい提案をしてくれた皆さんに感謝します。私はここで見つけた優れた記事に従ってこれを達成することができました: http://candordeveloper.com/2017/04/12/how-to-use-angular-cli-with-visual-studio- 2017 /
この記事はそれをかなり単純なものにし、それはうまく機能しています。うまくいけば、これは他の人にも役立ちます。
これは、私が取り組んできたまったく同じ配置であり、「聖杯」はVisual Studio(2015/2017)を使用してAngular 2フロントエンド(マテリアルデザインUI)、私の場合はWebAPIサービスエンドポイントによってサポートされ、Entity Frameworkデータベースレイヤーを備えています。あなたが言ったように、すべてのニーズに合った適切な動作構成を取得することは簡単ではありません。しかし、Visual Studio 2017では、快適なセットアップ作業。社内のTFSビルドシステムにも展開できます。
現在、@ angular-cliベースを使用していますが、それ自体は必須ではありません。初期化が完了すると、npmスクリプトにアクセスして、開始(別名ng serve)とビルドを実行できるようになります。 VS2017では、タスクランナー(および必要に応じて、VS2017用のNPMタスクランナー拡張機能をインストール)ウィンドウを使用して、プロジェクトの開始を開く "ng serve"コマンドを実行するように構成できます。これにより、Webpackバンドルとファイル変更の継続的な監視が開始されます。後者の部分はVS2017での円滑なデバッグと開発環境にとって重要であり、それをプロジェクト開始イベントに結び付けることで、もう1つの手間が省けます。
次に、プロジェクトファイルを手動で編集し、TypeScriptバージョンのすぐ下に次のキーを追加して、VS2017 TypeScriptコンパイルを無効にします。
_<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
_
これを行う理由は2つあります。コンパイルを処理するWebpackバンドラーによる継続的な監視により、VS2017もそれを実行する必要がなく、これにより、TypeScript
を使用します。
私はChromeをブラウザーのVS2017で使用しているため、現在IE11を上回っています。何らかの理由で、VSのデバッグエンジンからIE11を使用すると、初期ロードが非常に遅くなります。これは、VSが各Webpackバンドルにバンドルされているすべての個々のファイルを解析します。Chromeはそれを大胆に実行しているようです。皮肉なことに、EdgeはChromeとほぼ同じ速度で実行されますが、2017年でも新しいVS2017 、エッジのデバッグはVS2017ではサポートされていません。
Chrome=ブラウジングを実行しても、VS2017ファイルのブレークポイントにヒットします。これは素晴らしいボーナスです。これについて私が見た唯一のグリッチは、通常、VS2017でデバッグを開始する必要があることです、= Chrome私のサイトを起動し、VS2017がソースマップを適切に解析するためにすぐにページを更新します。また、次のようなTSファイルのコピーにブレークポイントを配置する必要があることに気づきましたソリューションファイルのブレークポイントがChromeで直接トリガーされていないように見えるため、アクティブにデバッグしているときに表示されるソリューションエクスプローラーの「スクリプトエンジン」ブロックに表示されます。これは、ソースマップが正しい元のマップでコンパイルされていないためと考えられますファイルパスなので、VS2017では、「スクリプトエンジン」のファイルがソリューション内の特定のファイルに関連付けられていることを知る方法がありません。
この構成で解決しなければならない最後の頭痛の種は、COSを有効にすることです。これにより、VS2017でのデバッグ中にWebサイトのフロントエンド(Angular)がWebAPIバックエンドに接続できるようになります。 @ angular-cliの組み込みliteサーバーはフロントエンドをホストし、VS2017はIISExpressを起動してバックエンドをホストするため、異なるポートに配置されます。バックエンドにCORSアクセスを追加する必要があり(global.asax.csファイルを介してグローバルに実行し、条件付きコンパイルフラグにラップして、DEV /ローカルデバッグビルドでのみ使用されるようにする)、フロントエンドでサービスを実行できるようにしましたバックエンドの他のポートへの呼び出し。しかし、魅力のように機能します。
編集:これを少し追加するために、VS2017でのデバッグをより適切にサポートできるように、練習を少し改良しました。 Angular CLIプロジェクトを起動すると、通常はVS2017に空のWebサイトプロジェクトを作成させて、プロジェクトディレクトリを作成します。次に、コマンドプロンプトに移動し、そのフォルダーに移動して、 Angularこのコマンドを使用してスケルトンアプリケーションを生成するCLIツール:
_ng new -si -sg -dir . MyApp
_
私が指定した引数は、パッケージのインストールをスキップします(VS2017は、package.jsonファイルを一度保存するとそれを実行できるため)、gitをスキップします(gitを使用しないTFSハウスで作業するため、個人的には使用しません) 、そしてAngularアプリケーションの作業ディレクトリをターゲットにします(私が追加レベルのディレクトリを作成したくないので)。
次に、それが完了したら、Angular CLIの_ng eject
_コマンドを使用して、Webpackのバンドルとビルドプロセスに対するツールの制御を強制的に「排出」します。これにはCLIツールがあります。使用するすべての構成ファイルを書き出します。これは、ソースマップを少し異なる方法で処理するためにwebpack.config.jsファイルに入る必要があるためです。
DEVの場合、VS2017で、webpack.config.jsを次のように変更します。
1)const webpack = require('webpack');
を先頭に追加します
2)行_"devtool": "source-map"
_をコメント化します。
3)new AotPlugin(..)
ブロックの後に、もう1つのプラグインを追加します。
_new webpack.SourceMapDevToolPlugin({
filename: '[file].map',
noSources: true,
moduleFilenameTemplate: '[absolute-resource-path]',
fallbackModuleFilenameTemplate: '[absolute-resource-path]'
})
_
これは、IE11またはChromeを使用する場合のアクティブなデバッグブレークポイントとIntellisenseデバッグの魔法のようなものです。ただし、Chromeで直接デバッグすることはできません。 webpackによって生成されたソースマップ内のパス参照をコンピューター上の絶対ファイルパスに変更します。VS2017はそれを完全に削除するため、ソースを完全に見つけることができます。私の現在の計画では、元のwebpack.config.jsを保持して使用します私たちのDEV WebサーバーとPRDビルドでのDEVテストのために、適切なスクリプト(おそらくカスタムnpmスクリプト)を使用してこのリビジョンをwebpack.vs.config.js構成でここで使用し、VS2017ですべてのローカルマシンDEVを動作させます遠く…それは私にとってほぼ完璧な環境です。
「純粋なAngular 2)」と記述されている最初のタイプのアプリケーションの場合、Visual Studio Marketplaceで利用可能な Angular CLIプロジェクトテンプレート を使用できます。 。
プロジェクトは基本的に、カスタマイズされたASP.NET Coreプロジェクトであり、Angular CLIアプリケーションとルートフォルダーを共有し、Visual Studioでの従来の開発エクスペリエンスと、 Angular CLI。
プロジェクトは、Visual Studioによって提供される標準の発行機能をサポートしています。ビルド中にAngular CLIによって生成されたファイルのみで、DLLは含まれません。ターゲットの宛先に公開されます。
開示:私はテンプレートの作成者です。コードはGitHubで入手できます。
承認されたソリューションに加えて、IIS Webデプロイ(または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>
Package.jsonを編集して、buildYourSolutionConfigNameというスクリプトを含めます。
{
"scripts": {
"buildYourSolutionConfigName": "ng build --someFlagNeeded",
"ng": "ng",
"start": "ng serve",
"build": "ng build",
...
}
...
}
これで、ターゲット環境の要件に従ってアプリを構築するために必要なものがすべて揃いました。これにより、VSとプッシュパブリッシュで正しい構成を選択するだけで済みます。
1つのオプションは、Angular CLIとASP.NET Coreプロジェクトを使用してアプリケーションをスキャフォールディングすることです。
npm install --global @angular/cli
新しいmy-app
プロジェクトの.angular-cli.json
ディレクトリを指すように/wwwroot
ファイルのoutDir
を変更します
アプリケーションを静的ファイルサーバーとして構成します。
void ConfigureServices(...) {
app.AddMvc(); // Microsoft.AspNetCore.Mvc
}
void Configure(app) {
app.UseMvcWithDefaultRoute();
app.UseDefaultFiles(); // Microsoft.AspNetCore.StaticFiles
app.UseStaticFiles();
}
プロジェクトを右クリックしてPublish
を選択しますAzure App Service
またはIIS/FTP
を選択して、画面の指示に従います
これがチュートリアルです: https://medium.com/@levifuller/building-an-angular-application-with-asp-net-core-in-visual-studio-2017-visualized-f4b163830eaa