Angular 和 ASP.NET Core

Angular CLI提供了一种使用 Angular 开发前端应用程序的方法，它隐藏了许多细节。例如，无需了解Webpack或SystemJS 的工作原理。

事实上，如果你对 Webpack（用于构建最新版本 Angular 应用的工具）不太了解，那么 CLI 看起来简直就像魔法一样。你只需要执行一些简单的命令ng new，ng serve --open就能在浏览器中打开一个可运行的 Angular 应用。

CLI 隐藏了所有底层细节，这可能会导致诸如“如何将 Angular 与 ASP.NET Core 结合使用？”之类的问题。

我希望读完这篇博文后，您能清楚地了解如何回答这个问题（不仅限于 ASP.NET Core，而是无论您想用哪种技术来运行您的 Angular 应用）。

你看，Angular 应用本身就是一个应用，它需要通过某种方式由 Web 服务器“提供服务”。

编译Angular应用程序时，你会生成一组JavaScript文件、CSS文件和一个index.html文件。仅此而已。

这些“工件”默认复制到的文件夹是yourApplicationFolder/dist。您可以通过访问您的 Angular 应用程序并执行 来查看它ng build。

请继续，我等你。

这样做时，ng serve --open你实际上是在使用一个独立的 Web 服务器（webpack-dev-server）来提供 dist 文件夹中的 index.html 文件。

本文余下部分将介绍几种将 Angular 与 ASP.NET Core 结合使用的方法。第一种方法是让 ASP.NET Core 来提供 Angular 文件。

第二种方法是将 Angular 和 ASP.NET Core 作为两个独立的应用程序。例如，使用 Nginx 时，Angular 和 ASP.NET Core 都使用 80 端口；而使用 IIS 时，每个应用程序都使用各自的端口。

文章的最后一部分描述了一种我认为非常理想的设置，在这种设置下，你可以ng serve在开发过程中使用 Angular 的功能。

这篇文章篇幅较长，但各部分内容相对独立。如果您只对最后一部分感兴趣，并且您使用的是 Windows 系统，我建议您也阅读一下关于如何在 IIS 中配置 Angular 的部分。

使用 ASP.NET Core 来运行 Angular 应用程序

有人认为，在 ASP.NET Core 中运行 Angular 应用会造成资源浪费。毕竟，Angular 应用本质上只是一组静态文件，没有必要让对这些文件的请求经过 ASP.NET Core 中间件管道。

这样做或许有一些很好的理由，而且了解如何这样做也无妨，由于这似乎是一种常见的做法，熟悉它可能会很有用。

要了解如何将 ASP.NET Core 和 Angular 应用程序一起运行，需要了解 ASP.NET Core 中如何处理请求。

运行 ASP.NET Core 应用程序时，您的请求会经过一系列中间件“管道” 。每次收到请求时，它都会按照中间件定义的顺序依次经过，然后再按相反的顺序依次经过。

每个中间件都有两次机会修改请求或响应：一次是在其他中间件执行之前，另一次是在其他中间件执行之后。这使得位于管道顶端的中间件可以处理例如由管道下游的中间件设置的 401 响应。

例如，身份验证中间件会将 401 响应更改为 302 重定向到登录页面。

Startup.cs您可以在文件中的方法里找到此管道的定义Configure。例如，以下是您执行以下操作时得到的管道dotnet new mvc：

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Home/Error");
    }

    app.UseStaticFiles();

    app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=Home}/{action=Index}/{id?}");
    });
}

每次有请求到达这个 ASP.NET Core 应用程序时，最多会经过三个中间件。首先是DeveloperExceptionPage/ExceptionHandler中间件，具体取决于 ASP.NET Core 应用程序是否运行在开发模式下。然后是StaticFiles中间件，最后是Mvc中间件。

这里关键的中间件是 `<filename> StaticFiles`。这个中间件负责处理文件夹中的文件wwwroot，例如，如果收到对 `index.html` 的请求，而该文件夹中存在 `index.html` 文件，那么wwwroot/index.html该文件就会被发送给客户端。` StaticFiles<filename>` 中间件之后不会再调用它下面的中间件（在本例中应该是 `<filename> Mvc`）。

你可能已经能想象出它在 Angular 应用中的运作方式了。只需将其放在wwwroot.

完全正确，但是有一个细节StaticFiles需要注意。它StaticFiles不会尝试为你做任何猜测，也就是说，如果你的请求是针对某个特定类型的/，StaticFiles它不会去查找对应的中间件/index.html。它会直接认为这个请求不应该由它处理，然后调用管道中的下一个中间件，在本例中是针对某个特定类型的中间件Mvc。

要使这种方法奏效，您需要另一个名为 `<middleware_name>` 的中间件，它必须在管道中DefaultFiles位于 `<middleware_name>` 之前：StaticFiles

//...
app.UseDefaultFiles();
app.UseStaticFiles();
//...

DefaultFiles这将导致需要StaticFiles查找index.htmlURL 是否以 . 结尾/。

现在唯一要做的就是配置 Angular CLI，使其编译到 ASP.NET Core 应用程序的 wwwroot 文件夹中。

在 Angular 应用程序文件夹中，你会找到一个 .angular-cli.json 文件。在该文件中查找以下outDir属性：

...
"apps": [
{
    ...
    "outDir": "dist",
...

将其从“dist”更改为 ASP.NET Core 的 wwwroot 文件夹路径。ng build在您的 Angular 应用程序中运行，现在如果您运行 ASP.NET Core Web 应用程序，您应该会在浏览器中看到您的 Angular 应用程序。

一个不错的开发工作流程是使用 Angular CLI 的监视模式运行构建：在控制台窗口中执行 `ng build`ng build --watch或 ` ng build -wng build`（如果您想节省一些按键操作），然后让它运行。现在，每次您对 Angular 应用程序进行更改时，只需刷新浏览器即可看到更改（您还需要运行 ASP.NET Core 应用程序）。

不过，这种方法缺少一个关键功能：深度链接支持。也就是说，如果你的 Angular 应用使用了路由，并且你向用户发送了一个包含有效 Angular 路由的 URL（例如http://yourapplication.com/products/5），接收用户将无法打开该 URL。尝试访问该路由会返回 404 Not Found 错误。

这是因为请求会一直经过 ASP.NET Core 应用程序的管道，当它到达 MVC 中间件时，MVC 中间件不知道该如何处理它，并将响应的状态代码设置为 404 页面未找到。

我们可以在流程的顶端查找即将发送的 404 响应，并将其路径更改为我们的 Angular 应用的 index.html 文件（这样，最终提供的是 Angular 应用，它知道如何根据路由处理该 URL）。之后，我们让请求再次通过流程：

//add this at the start of Configure
app.Use(async (HttpContext context, Func<Task> next) =>
{
    await next.Invoke();

    if (context.Response.StatusCode == 404)
    {
        context.Request.Path = new PathString("/index.html");
        await next.Invoke();
    }
});

这样虽然解决了深层链接的问题，但也引入了一个新问题。如果你的 Web API（已在 ASP.NET Core 应用程序中实现）需要发送 404 响应该怎么办？这种情况完全可以理解。在这种情况下，服务调用将收到包含 index.html 的 200 响应，而不是 404 响应。

解决方法是查看 URL，判断它是指向 Web API 还是 Angular 路由。通常，对 Web API 的调用会/api在 URL 中包含 `/web/api ...

//add this at the start of Configure
app.Use(async (HttpContext context, Func<Task> next) =>
{
    await next.Invoke();

    if (context.Response.StatusCode == 404 && !context.Request.Path.Value.Contains("/api")))
    {
        context.Request.Path = new PathString("/index.html");
        await next.Invoke();
    }
});

关于这种方法，最后一点需要说明。我见过一些示例，其中 Angular 应用程序和 ASP.NET 应用程序位于同一个 Visual Studio 解决方案中。Visual Studio（不是 VS Code）会尝试编译 TypeScript 文件。如果您正在使用这种方法，ng build -w则需要确保 Visual Studio 不会修改您的 TypeScript 文件。为此，请打开您的项目.csproj并添加任何PropertyGroup：

<TypescriptCompileBlocked>true</TypescriptCompileBlocked>

Nginx

Nginx是一款 Web 服务器，可以作为 ASP.NET Core 应用程序的反向代理，并且非常擅长提供静态内容。

在 Nginx 中，让 Angular 应用与 ASP.NET Core 协同工作的配置要简单得多。您只需要类似这样的配置：

server {
    listen 80;        

    location / {
        root /pathToYourAngularApplication/dist;
        index index.html;
        try_files $uri $uri/ /index.html;
    }

    location /api/ {
        proxy_pass http://localhost:5000;
    }
}

这就是一个典型的 Nginx 配置文件。如果您不熟悉 Nginx 和 ASP.NET Core，我推荐您阅读我的博客文章：《从零开始在 ASP.NET Core 中实现 HTTPS》。文章中有一个章节详细介绍了如何使用 Nginx 安装和配置网站。

这种配置允许 Angular 和 ASP.NET Core 应用程序都使用 80 端口。让我们来看看其中的重要部分。

该listen 80声明表明，Nginx 将响应通过 80 端口传入的请求。

这些location配置块用于定义我们如何为两个应用程序（Angular 和 ASP.NET）提供服务。每次收到请求时，Nginx 都会检查 URL 并尝试找到最匹配的location 配置块。在这种情况下，location 配置块的 URL 匹配类似于“前缀匹配”，也就是说，第一个配置块会匹配所有以 `.` 开头的 URL /。第二个配置块则匹配以 `.` 开头的 URL /api/。

Nginx 会选择最“具体”的位置块，因此即使对的请求/api/users与两个位置块都匹配，但由于第二个位置块（/api/）更具体，因此将使用第二个位置块来处理该请求。

在第一个位置块（/）：

root /pathToYourAngularApplication/dist设置静态内容查找路径，该路径为已编译的 Angular 应用程序文件所在的位置（dist是 CLI 的默认输出文件夹）。

index index.html指定对于以“.”结尾的 URL 应该提供哪个文件/。

try_files $uri $uri/ /index.html可以这样理解：检查是否存在与规范化 URL 匹配的文件（例如http://www.yourwebsite.com/assets/image.jpg -> /assets/image.jpg），如果该文件不存在，则尝试规范化 URL 加上一个前缀/（例如http://www.yourwebsite.com/documents -> /documents/ -> /documents/index.html，因为存在该index规则）。如果以上方法均失败，则提供该文件/index.html。

/index.html如果找不到匹配项，则提供默认服务，这使得我们可以使用深度链接。例如，如果一个 URLhttp://www.yourwebsite.com/documents文件中不包含任何数学公式，则会提供 Angular 应用的 index.html 文件。index.html 文件Index.html会加载 Angular 应用运行所需的所有文件，特别是路由模块。路由模块随后会检查该 URL，并根据 Angular 应用中定义的路由来决定加载哪个组件。

最后是最后一个 location 配置块。它指示 Nginx 将以 `/example.com` 开头的请求转发/api/到监听 `/example.com` 端口 5000 的 Web 服务器localhost。这将是您的 ASP.NET Core 应用程序。

关于 Nginx 的语法，需要注意一点。应用程序 URL末尾是否proxy_pass带有 `\` 非常重要。如果 URL包含 Nginx 文档中描述的“可选 URI” （可选 URI 这个名称并不恰当，因为 URL 本质上就是 URI），则其处理方式会有所不同。/proxy_pass

带有可选 URI 的 URL 示例为：http://localhost:5000/optionalURI/。如果位置路径为/api/，则对的请求http://yourwebsite.com/api/users将作为转发到您的 ASP.NET Core 应用程序http://localhost:5000/optionalURI/users。

这就是为什么不要/在末尾添加 `\ proxy_pass` 如此重要的原因，因为如果你这样做（例如：`\ proxy_pass http://localhost:5000/;`），它就属于“可选 URI”类别（它将被解释为空的可选 URI），并且对 `\` 的请求http://yourwebsite.com/api/users在你的 ASP.NET Core 应用程序中将被视为对 `\` 的请求http://localhost:5000/users。

如果您不在/末尾添加（例如：）proxy_pass http://localhost:5000;，则对的请求http://yourwebsite.com/api/users在 ASP.NET Core 应用程序中将被视为对的请求，http://localhost:5000/api/users这可能正是您想要的。

如果您需要一个更完整的示例来解释如何在开发时场景之外实现此功能（例如，即使出现异常，也能让您的 ASP.NET Core 应用程序自动启动并保持在线），请查看《从零开始编写 ASP.NET Core 中的 HTTPS》，其中有一个示例描述了如何使用Supervisor来保持 ASP.NET 应用程序在发生错误时也能运行（通过自动重新启动）。

信息系统

使用 IIS 时，要实现类似于 Nginx 的配置（即 Angular 和 ASP.NET Core 应用程序都在 80 端口上运行）会变得非常麻烦。

为了理解这一点，我们需要先了解 IIS 中的网站和应用程序概念。创建网站时，您需要定义（除其他设置外）网站运行的端口（例如 80）。一个网站内部可以包含多个应用程序，所有这些应用程序共享网站配置（因此使用同一个端口）。

例如，我们可以将 Angular 应用程序放在“默认网站”中，将 ASP.NET Core 应用程序作为其下的 IIS 应用程序，并将其命名为“api”。

如果“默认网站”的响应地址是http://localhost，那么 ASP.NET Core 应用程序的地址可以是http://localhost/api 。这似乎正是我们想要的。但是，在 ASP.NET Core 中，对http://localhost/api的请求URL 中不会包含 api。

据我所知，没有办法改变这种行为。

这意味着您的 ASP.NET Core 应用程序在 IIS 中运行时与直接执行（无论是在 Visual Studio 中还是使用 dotnet run）时的行为会有所不同。

更糟糕的是，ASP.NET Core 应用程序需要发布（dotnet publish）才能在 IIS 中运行。它不像非 Core 的 ASP.NET 应用程序那样，可以直接将 IIS 应用程序指向包含 ASP.NET 应用程序文件的文件夹。

因此，在使用 IIS 时，合理的选择要么是让 ASP.NET Core 为 Angular 应用程序提供服务（如本文第一节所述），要么是拥有两个独立的网站。

让我们逐步了解创建两个独立网站的过程。首先是 Angular 项目的网站，然后是 ASP.NET Core 项目的网站。

IIS 中的 Angular

我们将在 80 端口上添加一个名为MyNgWebSite的网站。这意味着，如果您有一个“默认网站”（您很可能有一个），则需要停止它或更改其绑定，因为它的默认端口是 80。

但在此之前，我们需要为 Angular 应用程序创建一个应用程序池。在 IIS 管理器中右键单击“应用程序池”：

Angular 应用程序的应用程序池不需要托管代码（我们只需要提供静态文件）。我们应该在 .NET CLR 版本中选择“无托管代码”：

现在我们可以添加一个新的 IIS 网站，并将我们创建的新应用程序池设置为该网站的应用程序池：

物理路径应该设置为 Angular 项目编译到的位置，通常是dist项目文件夹。

如果您现在尝试访问http://localhost（假设您已停止“默认网站”或使用了 80 以外的端口），则会收到权限错误。这是因为创建应用程序池时会创建一个“虚拟”用户。该用户是本地用户，必须拥有访问包含您尝试提供的文件的文件夹的权限。

该用户名是IIS AppPool\ApplicationPoolName，在本例中是IIS AppPool\ApplicationPoolForAngular。

转到包含已编译的 Angular 项目的文件夹，右键单击该项目并选择“属性”，转到“安全”选项卡，单击“编辑”，然后单击“添加”，最后添加应用程序池用户：

现在，如果您访问 .，我们应该能够访问您的 Angular 应用程序http://localhost。

不过我们还需要做最后一件事：启用深度链接支持。

如果你的 Angular 应用中包含路由，那么当有人尝试从 Angular 应用“外部”访问这些路由时，它们将无法正常工作。这意味着，如果访问http://localhost/documents在 Angular 应用内部有效，而你将该 URL 发送给其他人，那么当其他人点击该链接时，他们会看到 IIS 返回的 404 页面。

这是因为该 URL 中既没有文档文件夹，也没有索引文件，所以 IIS 无法提供服务。我们需要告诉 IIS，index.html当有人尝试访问一个不存在的 URL 时，它必须提供该文件。

我们将使用与自定义 404 页面相同的机制，但不是显示 404 页面，而是提供 Angular 应用程序。

为了实现这一点，我们需要创建一个web.config文件，并将其放在 Angular 应用程序的 src 文件夹中，内容如下：

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <httpErrors errorMode="Custom" existingResponse="Replace">
            <remove statusCode="404"/>
            <error statusCode="404" responseMode="ExecuteURL" path="/index.html"/>
        </httpErrors>
    </system.webServer>
</configuration>

简单解释一下发生了什么。我们使用了httpErrors` errorMode="Custom"and`参数existingResponse="Replace"。这会指示 IIS 将默认错误页面替换为我们即将指定的页面。

remove statusCode="404"如果已存在 404 页面的自定义设置，则会将其删除。

error statusCode="404" responseMode="ExecuteURL" path="/index.html"配置 IIS 在/index.html出现 404 错误时执行该 URL。这将有效地运行您的 Angular 应用程序，并且不会更改客户端看到的 URL。

现在我们需要编辑该.angular-cli.json文件，以便web.config在应用程序编译时将其作为资源复制到输出文件夹。资源部分位于“app”目录下，以下是一个示例：

{
"$schema": "./node_modules/@angular/cli/lib/config/schema.json",
"project": {
    "name": "your-app"
},
"apps": [
    {
    "root": "src",
    "outDir": "dist",
    "assets": [
        "assets",
        "favicon.ico", 
        "web.config"
    ],
    "index": "index.html",
...

IIS 中的 ASP.NET Core

在 IIS 中配置 ASP.NET Core 应用程序的过程类似，只是我们需要选择不同的端口。

但在开始之前，您需要确保已安装适用于 IIS 的ASP.NET Core 模块。如果您已安装 .NET Core SDK，则该模块可能已经安装，但最好的确认方法是转到 IIS 管理器，查看它是否在模块列表中：

如果你还没有安装，可以点击这里查看更多信息，也可以点击这里直接下载。

该模块负责启动和保持 ASP.NET Core 应用程序运行。

在 IIS 中创建网站之前，我们需要已发布的 ASP.NET Core 应用程序版本。您可以通过命令行完成此操作dotnet publish，或者在 Visual Studio 中，右键单击项目并选择“发布”，然后单击“发布到文件夹”。

创建一个新的网站，并将其指向 ASP.NET Core 项目的发布文件夹，为其指定一个不同的端口号（例如 8080），并为其创建一个应用程序池。

ASP.NET Core 应用程序的应用程序池也是非托管的（没有托管代码）。虽然这看起来可能很奇怪，但这是因为IIS 实际上只是充当反向代理。

在能够使用 IIS 运行 ASP.NET 项目之前，我们需要更改已发布文件夹的权限，以便应用程序池用户可以访问它。否则，您将收到以下不太有用的错误消息：

HTTP 错误 500.19 - 内部服务器错误
由于页面的相关配置数据无效，无法访问请求的页面。

如果你查看该Config Error部分，你会看到“由于权限不足，无法读取配置文件”，这基本上说明了一切。

转到已发布的文件夹，并将应用程序池用户添加到对该文件夹具有权限的用户列表中。

您的 ASP.NET Core 应用程序现在应该可以通过您在 IIS 中创建网站时选择的端口访问。但是，如果您尝试从 Angular 应用程序调用它，则会收到以下错误：“加载失败...请求的资源上不存在‘Access-Control-Allow-Origin’标头...”。以下是开发者工具控制台选项卡中该错误的示例：

这是因为，尽管我们的 Angular 和 ASP.NET Core 应用程序都在同一个域中，但它们位于不同的端口上，这足以使除 IE 以外的所有浏览器将该请求判定为跨域资源共享 (CORS) 请求。

我们需要在 ASP.NET Core 应用程序中启用 CORS。为此，我们需要添加包Microsoft.AspNetCore.Cors并在添加ConfigureServices(IServiceCollection services...方法中执行以下操作：Startup.csservices.AddCors()

public void ConfigureServices(IServiceCollection services)
{
    //...
    services.AddCors();
    //...
}

在Configure方法中，我们需要创建一个“策略”，表明我们预期会收到来自某个来源的请求http://localhost。我们应该在 MVC 中间件之前完成这一步：

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    //...
    app.UseCors(builder => builder.WithOrigins("http://localhost"));
    app.UseMvc();
}

应该一切就绪了。你的 Angular 和 ASP.NET Core 现在应该都能正常工作了。

平台无关的开发设置

Angular 和 ASP.NET Core 应用程序都提供了检测当前运行模式（开发模式或生产模式）的方法。利用这一点，可以创建同时适用于 Linux、Windows 和 Mac 的系统配置。

运行 Angular 应用程序最简单的方法是使用 run 命令ng serve。该命令会启动一个webpack 开发服务器，默认情况下会在 4200 端口上运行 Angular 应用程序。

这样做还有一个好处，就是支持热模块替换，这意味着你可以在对 Angular 应用程序进行更改后立即看到更改效果，而无需刷新浏览器。

所以理想情况下，我们希望以这种方式运行 Angular 应用程序。

对于 ASP.NET Core 应用程序，我们希望在不发布的情况下运行它，但如果它由 IIS 提供服务，则必须发布它。

这是理想的开发场景，ng serve可以在 Visual Studio 中运行 Angular 或dotnet runASP.NET Core，而无需发布。

在理想的开发场景中，我们可以让 Angular 应用程序运行在 4200 端口（通过ng serve），而 ASP.NET Core 应用程序运行在 5000 端口。在生产环境中，Angular 应用程序通常会通过 80 端口提供服务，而 ASP.NET Core 应用程序则会通过 8080 端口提供服务（或者通过 80 端口上的另一个服务器提供服务）。

在 ASP.NET Core 方面，我们需要配置 CORS，使其在开发环境下接受来自 4200 端口的请求，在生产环境下接受来自 80 端口的请求。在 Startup.cs 文件中，配置如下：

public void ConfigureServices(IServiceCollection services)
{
    services.AddCors();
    //...        
}

// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    //...
    if (env.IsDevelopment())
    {
        //...
        app.UseCors(builder => builder.WithOrigins("http://localhost:4200"));
    }else 
    {
        app.UseCors(builder => builder.WithOrigins("http://localhost"));
    }

    app.UseMvc();
}

这样就处理完了 ASP.NET Core 应用程序。

对于 Angular 项目，我们需要使用 environemnt.ts 和 environemnt.prod.ts 文件。您可以在 Angular 项目文件夹environemnts下的某个文件夹中找到它们。src

environment.ts 中的内容在开发模式（默认）下运行 Angular 项目时可用，而 environment.prod.ts 中的值将在生产环境中使用。要使用生产环境编译 Angular 项目，请使用标志--env=prod（例如ng build --env=prod）。

以下是一个简单的示例，说明如何配置环境文件以支持我们的假设场景，示例文件为 environment.ts：

export const environment = {
    production: false,
    apiBaseUrl: "http://localhost:4200/"
};

environment.prod.ts：

export const environment = {
    production: true,
    apiBaseUrl: "http://localhost/"
};

在 Angular 服务中，要获取环境变量值，只需导入环境变量（始终是 environment，而不是 environment.prod）：

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { environment } from '../environments/environment';

@Injectable()
export class MyServiceService {

    constructor(private httpClient: HttpClient) { }

    getStuff(){
        return this.httpClient.get(`${environment.apiBaseUrl}/api/suff`);
    }  
}

即使您使用 Nginx 或 IIS 进行托管，这种方法也适用，因此如果您需要/想要支持开发人员使用不同的平台，或者只是想比较它们之间的性能，这可能是最佳选择。