35

I am trying to start my .net core web api on container tech. using docker.

Environments=Windows 10,Visual Studio

Docker version:

Client:

Version: 17.12.0-ce

API version: 1.35

Go version: go1.9.2

Git commit: c97c6d6

Built: Wed Dec 27 20:05:22 2017

OS/Arch: windows/amd64

Server:

Engine:

Version: 17.12.0-ce

API version: 1.35 (minimum version 1.12)

Go version: go1.9.2

Git commit: c97c6d6

Built: Wed Dec 27 20:12:29 2017

OS/Arch: linux/amd64

Experimental: true

My Nuget.Config file:

<?xml version="1.0" encoding="utf-8"?> <configuration> <packageSources> <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" /> <add key="Private" value="http://My_Private_Nuget_Server" /> </packageSources> <packageRestore> <add key="enabled" value="True" /> <add key="automatic" value="True" /> </packageRestore> <bindingRedirects> <add key="skip" value="False" /> </bindingRedirects> <packageManagement> <add key="format" value="0" /> <add key="disabled" value="True" /> </packageManagement> <apikeys> <add key="https://www.nuget.org" value="Some_Long_Value" /> </apikeys> <disabledPackageSources /> </configuration>

My Dockerfile:

FROM microsoft/aspnetcore-build:2.0 AS build-env WORKDIR /app # Copy csproj and restore as distinct layers COPY *.csproj ./ RUN dotnet restore # Copy everything else and build COPY . ./ RUN dotnet publish -c Release -o out # Build runtime image FROM microsoft/aspnetcore:2.0 WORKDIR /app COPY --from=build-env /app/out . ENTRYPOINT ["dotnet", "MailAlertWebApiWithEF.dll"]

I' am using Linux Container on windows 10 machine. I have .net core project on Visual Studio 17. When ı add docker support and run from VS 17 everything works fine. API stands up inside a container.But don't work when i close the VS. However When ı try to customize my dockerfile to make my image and container independent from VS. It gives error because of a private .dll.

In my project ı have a .dll from my private nuget server. When ı tried without my private .dll ı can create image. But ı need that .dll. Docker give me this error:

MailAlertWebApiWithEF.csproj : error NU1101: Unable to find package WebApi.Utils. No packages exist with this id in source(s): nuget.org

I searched this error. The source of problem seems like Nuget.Config file. But it seems good to me because i can see me private nuget server in there. When ı searched the solutions arrows always on linux machines but ı use windows.

1-)So if i can start my project with VS 17 , then my nuget.config file is in correct form. It can see my private nuget server. Right? Then why not docker don't see it?

Please help

Improve this question
3
  • I found the problem but not solution. 'Dotnet Restore' command don't install one of my private package but install others from my private server. Commented Feb 16, 2018 at 7:52
  • Dotnet Restore' command don't install one of my private package Is that package .NET Framework library? If yes, the command line dotnet restore unable to resolve .NET Framework libraries, you can try to use nuget restore. github.com/dotnet/cli/issues/3199 Commented Feb 16, 2018 at 12:59
  • It was all .net standart library and compatibla with .net core. Commented Feb 20, 2018 at 12:21

6 Answers 6

Reset to default
51

for those who have landed here as they were using private repositories or custom nuget feeds and RUN dotnet restore is failing ,then here is what you can do :

Applicable especially if : your NuGet.Config contains the private repo endpoint and credentials , then

  1. copy your system's NuGet.Config in project folder at same root level where .csproject is.

  2. now in docker file put these statements just before you try to restore package:

    COPY ./NuGet.Config ./

  3. after that , append the config file location in dotnet restore command like this :

    RUN dotnet restore <CS_project_name>.csproj --configfile ./NuGet.Config

  4. Now do rest of the thing which you wanted to do .

  5. just at the end before entry point or before copying to other container(in case of multistage build) , it is good idea to remove NuGet.Config,as we don’t want that to be available in pod/container to be seen

RUN rm ./NuGet.Config

[Update] like mentioned at https://github.com/NuGet/Home/issues/4413#issuecomment-483920015

if we use the following copy command to put it in root of file system

COPY ./NuGet.Config /nuget.config

then we dont need to specify the location of config file during dotnet restore

Improve this answer
Sign up to request clarification or add additional context in comments.

6 Comments

It will be worth noting that RUN rm ./NuGet.Config will not work on windows, instead you will need to use RUN del -f "./NuGet.Config"
@devnsyde , basically we are trying to delete this nuget।config from build container so that even if someone download and do exec inside image he should not be able to know credentials for private repo,thus this rm command actually runs inside Linux container OS and works well without any issue, we are not deleting anything from windows
I know the answer was for someone running linux but I landed on this page when trying to figure out why RM wasn't working in my docker file, it was because I was on a windows container. Now when people from windows land on this answer they can see to use DEL instead.
This answer helped me TREMENDOUSLY thanks to the instruction to append the config file location to the dotnet restore command. I had no idea this was necessary :)
A RUN rm ./NuGet.Config will not remove the file from the image as a whole. It will stay visible at the lower layers. A new RUN layer will add a layer on top with that file removed, but that's it. So this is insecure: the file isn't actually removed.
|
30

In order for a dotnet command running inside a container to find your custom feeds, the nuget.config file must also be copied to the container.

To do this, add a nuget.config file with your private feed to your project folder and add an additional COPY step that copies this file to the container.

Example (Dockerfile):

WORKDIR ... COPY NuGet.Config / COPY ... ...
Improve this answer

3 Comments

COPY NuGet.Config / this fails on mine even though the file is there
For those who have configured Visual Studio to use the PackageReference format where packages are cached at the machine level, the nuget.config file is likely to be in $HOME\AppData\Roaming\NuGet (as a Windows path)
I just discovered that nuget.config (the file name) is case sensitive on Linux, which isn't so surprising really but caught me out!
24

You can add the private nuget through dotnet command, without the need to link to nuget.config file.

COPY *.csproj ./ RUN dotnet nuget add source <source-value-of-nuget> -n <name> RUN dotnet restore
Improve this answer

2 Comments

for some bizarre reason, docker couldn't find my nuget.config file no matter how I would address it but your solution worked very well, thank you for saving my time after spending 2 hours to solve it..
I had the same issue where my copy was not working. Was = " COPY nuget.config . " / IS = " COPY /Source/nuget.config . " Where my solution is in the root directory and my project + nuget.config files are in subfolder "Source"
8

Copying the Nuget.Config to the solution or project folder will work if your 'private nuget feed' is accessible via a url. But if the private feed is a local folder used as a nuget source, this approach will still fail with an error that the folder is outside the build context or simply because the Windows path does not get resolved by the Docker build process.

e.g. if you Nuget.Config has something like this:

 <packageSources> <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" /> <add key="My Local" value="C:\dev\nuget-packages" /> </packageSources>

the Docker context will not resolve C:\dev\nuget-packages

It's tempting to just give up on building within docker and just pre-publish the compiled solution and build the image from that...

But another workaround, requiring a few more steps, is also possible: run dotnet restore before running the docker-compose command, and use the --packages option to save the restored packages to the solution folder e.g.

dotnet-restore C:\slnfolder\myproj\myapp.csproj --packages C:\slnfolder\packages

(This could be wrapped in a single powershell script along with the docker-compose command.)

Then in the Dockerfile (used by docker-compose to build the image), assuming context is the solution folder and WORKDIR is '/src'

COPY packages/. packages/.

and modify the Dockerfile restore line to

RUN dotnet restore "myproj/myapp.csproj" -s /src/packages -s https://api.nuget.org/v3/index.json

Improve this answer

Comments

3

Stumbled across this while looking for another nuget question/answer...

To restore from within docker, as mentioned in this answer copy a nuget.config file to the container first, I'd suggest you place this in /root/.nuget/NuGet folder and use a multistage Dockerfile, that way, you don't need to worry about removing it.

If it helps, this is my setup...

--nuget.config <?xml version="1.0" encoding="utf-8"?> <configuration> <packageSources> <add key="PrivateFeed" value="https://private.nuget.feed.net/" /> </packageSources> <packageSourceCredentials> <PrivateFeed> <add key="Username" value="username" /> <add key="ClearTextPassword" value="plaintext_password" /> </PrivateFeed> </packageSourceCredentials> </configuration>

Multi-stage Dockerfile...

FROM mcr.microsoft.com/dotnet/core/sdk:3.1.201 as sdk-build WORKDIR /app # Skip extraction of XML documentation for nuget packages ENV NUGET_XMLDOC_MODE=skip # We'll copy the nuget config file to the right place # which should mean it doesn't get copied to our deployed containers # and we can just call 'dotnet restore' with specifying a config file COPY ./Nuget.Config /root/.nuget/NuGet/NuGet.Config # Make use of cached layers, by only doing a restore when the config changes COPY ./*.sln ./**/*.csproj ./ # Then within a RUN command to copy them to the right folders. RUN for file in $(ls *.csproj); do mkdir -p ${file%.*}/ && mv $file ${file%.*}/; done \ && dotnet restore # Copy the source code COPY . . # Now do a build/publish here RUN dotnet publish "./project/project.csproj" --output /app/output FROM mcr.microsoft.com/dotnet/core/aspnet:3.1.2 WORKDIR /app COPY --from=sdk-build /app/output ./ ENTRYPOINT ["./project"]
Improve this answer

Comments

1

This problem need not have a complex solution. For your "dotnet publish" to work it needs to be aware of where to look for NuGet packages and the NuGet packages should be available at that location.

So you only need to copy your folder containing NuGet packages to the container and then tell the build utility where to look for using the following command

RUN dotnet nuget add source /repo/nuget-local-source -n local-repo
Improve this answer

1 Comment

Dockerfile commands (simplified for copy-paste): COPY "nugets/" "/var/nugets/" RUN dotnet nuget add source /var/nugets/ I've used something like that in my case to not overcomplicate solution. Snippet was taken from another thread - there you can find more explanation: local-nuget-source-doesnt-exist-when-building-for-docker

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.