MyGet no longer seems to work from docker build

softwareguy741 · May 16, 2020, 9:25pm

Not sure when this changed or what is causing it but here is the repro:

Create new ASP.NET Core App from Visual Studio with Docker support enabled
Run locally: Succeeds
Select: Publish container to AWS…
Succeeds
Add a ServiceStack service
Run locally: Succeeds
Publish to AWS Container Service…
Fails with following:

… docker build: /src/ProxyApp1.ServiceInterface/ProxyApp1.ServiceInterface.csproj : error NU1102: Unable to find package ServiceStack with version (>= 5.8.1) [/src/ProxyApp1/ProxyApp1.csproj]
… docker build: /src/ProxyApp1.ServiceInterface/ProxyApp1.ServiceInterface.csproj : error NU1102: - Found 185 version(s) in nuget.org [ Nearest version: 5.8.0 ] [/src/ProxyApp1/ProxyApp1.csproj]

I tried to follow this article:

But it didn’t fix the problem. The strange thing is is that MyGet is working just fine, but when you go to run docker build it bombs out like it doesn’t know what MyGet is. And like I said, this used to work just fine.

Any suggestions?

mythz · May 16, 2020, 11:49pm

You may have a local issue with connecting to MyGet as all packages are definitely available on MyGet, which you can tell from the MyGet feed:

https://www.myget.org/F/servicestack/api/v2/Packages

You can test it by clearing your NuGet cache locally, then restoring it again which will fetch the latest packages on MyGet, if all packages are restored it means the MyGet feed has the packages and isn’t the issue.

I’m assuming you’ve previously used the v5.8.1 MyGet pre-release packages and your Dockerfile is restoring from a solution that contains a local NuGet.config.

softwareguy741 · May 17, 2020, 12:19am

That’s just it. I don’t think MyGet itself is the problem as I can fire up a brand new project and get your packages without a problem, even after clearing the local cache. It’s only during Docker build that it seems to be falling.

Even stranger is I know this used to work. I did recently install Visual Studio 2019 Preview (But this example is using current Visual Studio 2019) so I’m not sure if that threw something off with the whole system.

I’ll try this on a different machine that doesn’t have Visual Studio 2019 Preview.

mythz · May 17, 2020, 12:24am

The error message suggests it’s unable to locate the v5.8.1 packages (which are on MyGet), like it’s only looking at nuget.org packages since it only finds the latest v5.8.0 release on NuGet. IMO I’d be looking at why it’s no longer looking for the v5.8.1 packages on MyGet.

softwareguy741 · May 17, 2020, 12:57am

Right but so far all attempts at fixing that “problem”, as per the referenced article, have failed, suggesting something deeper. If MyGet is correctly referenced in the NuGet.Config file and Docker is using that, then why is it falling? It’s blowing my mind.

mythz · May 17, 2020, 1:17am

That’s exactly what you need to find out, what has changed since the last time it worked? Have you tried referencing NuGet.config directly?

softwareguy741 · May 17, 2020, 1:18am

Yep, I used your x mix myget tool and put this in the dockerfile:

RUN dotnet restore "WebApplication16/WebApplication16.csproj" --configfile ./NuGet.Config

Now it says:

… docker build: Step 8/17 : RUN dotnet restore “WebApplication16/WebApplication16.csproj” --configfile ./NuGet.Config
… docker build: —> Running in 685786205d57
… docker build: /usr/share/dotnet/sdk/3.1.202/NuGet.targets(536,5): error : File ‘/src/NuGet.Config’ does not exist. [/src/WebApplication16/WebApplication16.csproj]
… docker build: The command ‘/bin/sh -c dotnet restore “WebApplication16/WebApplication16.csproj” --configfile ./NuGet.Config’ returned a non-zero code: 1

mythz · May 17, 2020, 1:21am

This indicates the opposite, that it does not exist in your Docker build.

softwareguy741 · May 17, 2020, 1:22am

Right, so after adding NuGet.Config to the project and referencing it with --configfile, why does it think it’s not there? Doesn’t running your x mix myget tool put the file there?

mythz · May 17, 2020, 1:25am

That’s what you need to figure out, why isn’t your COPY task copying it with the rest of your src? what have you changed since it worked?

Why aren’t you copying your local NuGet.config along with the rest of your project?

softwareguy741 · May 17, 2020, 1:32am

Nothing, that I’m aware of. And again this is even with a brand new project. It used to be you just Right click → Add Docker Support… and bam, it worked. Now it only seems to work when not using packages from MyGet. Even though MyGet packages still work locally.

So… I just fixed it with this right before the donet restore command in dockerfile:

COPY ./NuGet.Config ./

Not sure why I’m having to manually do that now where before I definitely did not need to do that. But I guess I’m happy it works now. Just really strange and seems a bit hacky to me especially since docker should have been copying it along with:

COPY ["WebApplication16/WebApplication16.csproj", "WebApplication16/"]

since it should be part of the project already.

mythz · May 17, 2020, 1:40am

I’ve not used the auto Add Docker Support but I’d expect it would just be following the rules defined in your .csproj where any files you want copied over should be marked as Content files that should be copied, e.g:

<ItemGroup>
    <Content Include="NuGet.config">
      <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
    </Content>
</ItemGroup>

I expect that’s what’s changed, go through your .csproj history to see what the rules it was using before.

mythz · May 17, 2020, 1:43am

Although this look like it’s already the default for .config files:

Maybe different .csproj types have different defaults.

softwareguy741 · May 17, 2020, 1:44am

I never had to use a local copy of NuGet.config in the project file before. Shouldn’t it just pull from the system defined NuGet.config file in %AppData%? The Add Docker Support in VS just creates a dockerfile, that’s it. It has no knowledge of NuGet.config. But now it seems I’m having to explicitly add NuGet.config to both the dockerfile and the project for MyGet to work, even though Nuget still works. Doing some Googling to try and figure out why that’s the case now.

softwareguy741 · May 17, 2020, 1:44am

Yes, adding NuGet.config via x mix myget correctly sets it as Content type but yet it doesn’t copy over. So something somewhere is screwy.

mythz · May 17, 2020, 1:46am

This doesn’t have anything to do with NuGet.config, it’s due to however Add Docker Support works and what rules it follows, typically publish tools are just following the rules in your MSBuild .csproj file, whether they’re implicit from the inherited project type or explicit in your project.

Docker isn’t magic and doesn’t have any preconceived notion of .NET Core, it runs whatever commands you tell it and requires access to the same config files the dotnet tools have always required, if there’s no NuGet.config then there’s no way that the executing dotnet tool can know that it should be fetching the packages from an external source.

softwareguy741 · May 17, 2020, 1:53am

So then when excluding any reference to NuGet.config, how does it know how to restore packages from NuGet proper? I can fire up a new project, add Docker Support, and bam it restores files for NuGet, but not MyGet. So something somewhere is telling Docker how to get those packages from NuGet.

mythz · May 17, 2020, 1:54am

Again this has nothing to do with Docker, all it’s doing is running the dotnet tool which is following its default pre-defined behavior when no external configuration is provided.

softwareguy741 · May 17, 2020, 1:54am

I see. So are you suggesting it’s the dotnet tool itself that has knowledge of NuGet?

mythz · May 17, 2020, 1:55am

Of course, it’s the default package manager for .NET.