这与我一直在做的安排完全相同，“圣杯”是使用 Visual Studio (2015/2017) 开发和调试 Angular 2 前端（Material Design UI），并由 WebAPI 服务端点支持我的例子是一个实体框架数据库层。正如您所说，获得适合所有需求的体面工作安排并非易事。然而，使用 Visual Studio 2017，我相信我有一个相当舒适的设置工作，我也可以将其部署到我们内部的 TFS 构建系统。
目前，我正在使用 @angular-cli 基础，尽管这本身并不是必需的。初始化后，您应该可以访问 npm 脚本来执行启动（又名 ng 服务）和构建。在 VS2017 中，您可以使用 Task Runner（如有必要，安装适用于 VS2017 的 NPM Task Runner Extension）窗口来配置运行“ngserve”命令来打开您的项目。这将开始 webpack 捆绑并持续监控文件更改；后一部分对于 VS2017 中的顺利调试和开发环境非常重要，将其与项目打开事件联系起来可以让您多走一步。
然后，我通过手动编辑项目文件并在 TypeScript 版本下方添加以下键来禁用 VS2017 typeScript 编译：
<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
我这样做有两个原因：通过 Webpack 捆绑器持续监控为我处理编译，VS2017 也不需要这样做，这使我能够确保我正在使用 npm 包安装来编译 TStypescript尽管我覆盖了“选项”菜单中的路径，但 VS2017 有时仍顽固地坚持使用这些工具。
我在 VS2017 中使用 Chrome 作为浏览器，因为速度现在超过 IE11。由于某种原因，使用 VS 调试引擎中的 IE11 进行初始加载时运行速度非常慢；我相信这是因为 VS 必须解析每个 Webpack 捆绑中捆绑的每个单独文件。 Chrome 似乎运行得很好。讽刺的是，Edge 的运行速度几乎与 Chrome 相同，但即使在 2017 年使用全新的 VS2017，VS2017 也不支持 Edge 调试 - 想想看。
即使 Chrome 运行浏览，VS2017 文件中的断点也会被命中，这是一个很好的好处。我遇到的唯一问题是，我通常必须在 VS2017 中开始调试，让 Chrome 启动我的网站，然后立即刷新页面，以便 VS2017 正确解析源映射。我还注意到，我往往必须将断点放在 TS 文件的副本中，这些副本显示在解决方案资源管理器的“脚本引擎”块中，该块在主动调试时出现，因为直接在解决方案文件中设置断点不会似乎在 Chrome 下触发。我强烈怀疑这是因为我的源映射没有使用正确的原始文件路径进行编译，因此 VS2017 无法知道“脚本引擎”中的文件与我的解决方案中的特定文件相关联。我还在研究这个。
对于这种安排，我必须解决的最后一个难题是启用 CORS，以便网站前端（Angular）可以在 VS2017 中调试时连接到我的 WebAPI 后端。由于@angular-cli的内置lite服务器托管前端，而VS2017启动IISExpress来托管后端，因此它们将位于不同的端口上。我必须向后端添加 CORS 访问权限（我通过 global.asax.cs 文件全局执行此操作，并包含在条件编译标志中以确保它仅在 DEV/本地调试版本上使用）以允许前端提供服务调用后端的另一个端口。不过，它的作用就像一个魅力。
Edit:为了稍微补充一下，我稍微改进了我的实践，以更好地支持 VS2017 中的调试。当我启动 Angular CLI 项目时，我通常让 VS2017 创建一个空的网站项目，以便创建项目目录。然后，我进入命令提示符，进入该文件夹，并使用 Angular CLI 工具使用以下命令生成我的骨架应用程序：
ng new -si -sg -dir . MyApp
我指定的参数跳过包安装（因为一旦我保存了package.json文件一次，VS2017就可以做到这一点），跳过git（我个人不使用它，因为我在不使用git的TFS房子里工作） ，并以 Angular 应用程序的工作目录为目标（因为我不希望它创建额外的目录级别）。
然后，完成后，我使用 Angular CLIng eject命令强制 CLI“弹出”工具对 webpack 捆绑和构建过程的控制。这使得 CLI 工具写出它使用的所有配置文件。我这样做是因为我需要进入 webpack.config.js 文件以稍微不同的方式处理源映射。
对于DEV，在VS2017中，我修改webpack.config.js如下：
1) Add 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]'
})
这似乎是在 VS2017 调试模式下使用 IE11 或 Chrome 的神奇魅力，它可以激活调试断点和 Intellisense 调试。然而，它确实破坏了直接在 Chrome 中调试的能力，主要是因为这会将 webpack 生成的源映射中的路径引用更改为计算机上的绝对文件路径。 VS2017 吸收了它，因此它可以完美地找到源代码。我当前的计划是保留原始的 webpack.config.js 并将其用于我们的 DEV Web 服务器和 PRD 构建上的 DEV 测试，但在具有正确脚本的 webpack.vs.config.js 配置中使用此修订版（也许是一个自定义的 npm 脚本）来使用 VS2017 完成我所有的本地计算机 DEV 工作。到目前为止......这对我来说几乎是一个完美的环境。
