CODEWITHSUNDEEP
c#dockerasp.net-coredocker-composedockerfile
Lion
Lion

Reputation: 17878

NuGet package restore extremely slow when creating new ASP.NET Core MVC app in Docker

For troubleshooting an existing ASP.NET Core 2.1 MVC application, I want to host a simple hello world ASP.NET Core MVC application on the same server using Docker. So I created a small 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"]

But the container hangs on restoring NuGet packages:

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...

Those restore doesn't get finished even after minutes of waiting. The default template of ASP.NET Core MVC contains only a few packages.

Upvotes: 2

Views: 3880

Answers (2)

Charles Owen
Charles Owen

Reputation: 2850

I experienced this issue in Docker on a Windows 2019 Container Host. It was taking over 10 minutes to do a restore that would take about 5 seconds on my own machine. I found out that the MsMgEng.exe (Defender) process was scanning the dockerd.exe (Docker daemon). CPU usage was 98%.

I'm pretty sure it was just the Docker daemon but I also added docker.exe and gitlab-runner.exe on the Exclusion List.

And 13-minute restores are a thing of the past! That fixed it. You don't need any special params, conditions or flags on your dotnet restore.

Upvotes: 1

Lion
Lion

Reputation: 17878

It was noticeable that dotnet uses CPU ressources continuily and another project that refers multiple NuGet ressources got restored after 10 seconds. So it's not a network issue and it indicates that NuGet is doing something.

I found this question where a large project folder seems slowing down NuGet because it scans the entire folder. This seems applying to me too, since my quick test was done in the root file system of the container. So the fix was to simply create a sub-directory for the project: 

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

Now NuGet is finished with package restoring after a few seconds. The lesson learned is: Always use a clean sub directory, even when it's a quick & dirty test container where it (theoretically) shouldnt matter...

Upvotes: 2

Related Questions