I’ve worked with Nuget for quite some time, both consuming published Nugets as well as creating Nugets to be published.
But I ran into a pretty vexing series of issues today, that, from what I can tell from the posts I found by Googling, might be affecting a lot of other users.
To begin with, I was running an older version of nuget.exe, ver 4.9. So, I dutifully updated to v5.7 and still had the same issues.
My first problem was this lovely message:
Illegal characters in path. System.ArgumentException: Illegal characters in path.
After far far too much experimentation, I discovered that putting the project filename, the nuspec filename or the output directory filename in double quotes, was the problem.
In other words, this:
nuget pack ".\myapp.csproj" -Verbosity Detailed -OutputDirectory ".\bin\Release\"
won’t work. But this:
nuget pack .\myapp.csproj -Verbosity Detailed -OutputDirectory .\bin\Release\
works just fine.
Unfortunately, if your project’s path happens to contain spaces, you won’t be able to specify the path properly. I haven’t investigated any way around that.
But wait, there’s more!
That got me past the “Illegal characters in path” error, only to be greeted by this:
Authors is required. Description is required. System.Exception: Authors is required. Description is required.
In my case, I was using a pretty standard nuspec file, something like this:
<?xml version="1.0" encoding="utf-8"?> <package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd" > <metadata> <id>$id$</id> <version>$version$</version> <title>$title$</title> <authors>$author$</authors> <owners>$company$</owners>
It turns out there were two issues here:
- Ignore the error message. It’s terrible because, first, the xml element is <authors>, not <Authors> as the message implies. And second, the token is actually $author$ (singular), not $authors$ or $Authors$ or even $Author$.
- But much weirder was that it failed like this because I was actually specifying a relative path to nuget.exe, like so:
.\nuget\nuget pack blah blah
Yeah, you read that right. Believe it or not, that relative path somehow causes nuget to fail to resolve tokens in the nuspec file!
I put the nuget.exe in the same folder as my nuspec file and it worked!
So I moved nuget.exe to a folder that was on my PATH, and that worked as well!
So then I tried to fully specify the drive, folder and filename to the nuget.exe and that failed also.
Very bizarre.
I did come across a number of nuget bug reports indicating that it has problems if you rename the exe. That in and of itself is concerning and just plain weird.
But my guess is it’s trying to open the assembly via reflection, failing, an d short circuiting execution, skipping some very necessary code in the process. Regardless. Back in operation finally!