One of my pet peeves about the way the programming environment has evolved in the last decade or so is this: while there has been an enormous outpouring of creativity, there’s also been a big increase in the amount of gotchas you run into when you try to do seemingly “obvious” things. I suspect this is due to the same shift — the release of programming talent and energy from the confines of release scheduling — but, like so many other things, ya gotta take the good with the bad. There are no first order effects.
Take the nuget package management system. Definitely a boon to Visual Studio software development, freeing you (pretty much) from the need to manage dependencies and versions.
But it has its problems. Like this one…
If you run
nuget pack <some csproj file>
from a project folder, the documentation would lead you to believe it will produce a nupkg file. And it will. It’ll even pay attention to what configuration, debug or release, you’re in.
Unfortunately, where it looks for the configuration and where you set the configuration are two totally different things. It doesn’t honor the Visual Studio setting, even when you launch nuget pack from within the IDE, or as a post-build event.
Instead, it checks something in the bowels of the csproj file… which you cannot edit from within Visual Studio, at least with pre-2017 csproj files. So while you may think it’s generating the nupkg file from the Release build you just did, it’s actually grabbing the files from the last Debug build you did. And if you never did a Debug build? Well, in that case it just fails. But it doesn’t stop the build, so you probably won’t notice (I didn’t).
The solution is reasonably straightforward. Launch nuget like this:
nuget pack $(ProjectPath) -Prop Configuration=$(ConfigurationName)
The -Prop Configuration setting will override nuget’s default behavior of checking that obscure section of the csproj file.
You can read more about why this approach was taken — which strikes me as really, really lame, since it results in the unwary publishing nuget packages based on Debug builds, rather than Release builds — here.
