Monthly Archives: September 2020

The Disambiguator (A KeePass Plugin)

0
Filed under Uncategorized

I’ve used the password manager KeePass for a very long time. Excellent, simple, clean install, low resource usage and fast.

The AutoType support, while possibly not quite as simple as some full out commercial packages, is quite flexible and has never let me down.

Well, almost never.

More to come

Automation Virtual Conference

0
Filed under Uncategorized

Ok. I’m not one to typically post notices Re: my employers, but I thought I might make the few readers I have, aware of an upcoming virtual conference that Worksoft is having on testing and robotic process automation on Oct 28.

Click here to learn more.

Troubles with Nuget v5.7

0
Filed under nuget
Tagged as

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:

  1. 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$.
  2. 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!