在 Docker 中创建新的 ASP.NET Core MVC 应用程序时，NuGet 包还原非常慢

Question

为了对现有 ASP.NET Core 2.1 MVC 应用程序进行故障排除，我想使用 Docker 在同一台服务器上托管一个简单的 hello world ASP.NET Core MVC 应用程序。所以我创建了一个小的 Dockerfile：

FROM mcr.microsoft.com/dotnet/core/sdk:2.1 AS sdk-image
run dotnet new mvc
RUN dotnet publish -c Debug -o /publish

FROM mcr.microsoft.com/dotnet/core/aspnet:2.1 AS runtime-image
COPY --from=sdk-image /publish .
ENV ASPNETCORE_URLS=http://0.0.0.0:5000
ENV ASPNETCORE_ENVIRONMENT=Development
ENTRYPOINT ["dotnet", "WebApplication1.dll"]

但容器在恢复 NuGet 包时挂起：

Step 2/9 : RUN dotnet new mvc
 ---> Running in 54b50f10572b
Getting ready...
The template "ASP.NET Core Web App (Model-View-Controller)" was created successfully.
This template contains technologies from parties other than Microsoft, see https://aka.ms/aspnetcore-template-3pn-210 for details.

Processing post-creation actions...
Running 'dotnet restore' on /WebApplication1.csproj...

即使等待了几分钟，这些恢复也没有完成。 ASP.NET Core MVC 的默认模板只包含几个包。

Answer 1

值得注意的是dotnet 持续使用 CPU 资源，另一个引用多个 NuGet 资源的项目在 10 秒后恢复。所以这不是网络问题，它表明 NuGet 正在做某事。

我发现this question，其中一个大型项目文件夹似乎会减慢 NuGet，因为它会扫描整个文件夹。这似乎也适用于我，因为我的快速测试是在容器的根文件系统中完成的。所以解决方法是简单地为项目创建一个子目录：

FROM mcr.microsoft.com/dotnet/core/sdk:2.1 AS sdk-image
RUN mkdir test
WORKDIR /test
RUN dotnet new mvc

现在 NuGet 在几秒钟后完成了包还原。吸取的教训是：始终使用干净的子目录，即使它是一个快速而肮脏的测试容器（理论上）应该无关紧要......