Today I struggled again with my setup. I needed to build and run a simple application (using .NET Core on Windows) with .NET Core on my Mac. Actually, its the same system - just one hop away thanks to Parallels / Coherence.
Nothing easier than that, right? Of course, I have already installed .NET Core and whatnot, however, I then struggled to restore the required packages that came from a private NuGet feed. My struggle was going on for 30+ minutes when I realized the following.
The Nuget.Config that I had (sitting in some root directory) looked as follows:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="Sample" value="..." />
</config>
<packageRestore>
<add key="enabled" value="True" />
</packageRestore>
</configuration>
To me that looked perfectly fine, right? Also I swear this worked in the past. I know it worked, because back then the authentication against the private feed was terrible and would certainly be worth its own article, wouldn't it be fixed right now.
Anyway, after a while I discovered that the template engine of dotnet ships with a template for a NuGet config. Let's just create one to see if there are differences!
dotnet new nugetconfig
To my surprise there was quite a difference to the "original" one. I entered my options and everything went flawless. Why didn't the command line tooling tell me about the invalid NuGet.config? Why can't this be debugged simpler?
Here's how the new nuget.config looks like...
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<!--To inherit the global NuGet package sources remove the <clear/> line below -->
<clear />
<add key="Sample" value="..." />
<add key="nuget" value="https://api.nuget.org/v3/index.json" />
</packageSources>
</configuration>
Hopefully this will spare one or the other person the trouble I went through.