为了对现有 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 的默认模板只包含几个包。
最佳答案
值得注意的是，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 会在几秒钟后完成包恢复。吸取的教训是:始终使用干净的子目录，即使它是一个快速且肮脏的测试容器(理论上)不重要...
关于c# - 在 Docker 中创建新的 ASP.NET Core MVC 应用程序时，NuGet 包恢复速度极慢，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/57749824/