Home: NuGet.exe replaces '+' with '%2B' in assembly name

[spy008]

Details about Problem

NuGet product used (NuGet.exe | VS UI | Package Manager Console | dotnet.exe): NuGet.exe

NuGet version (x.x.x.xxx): v4.3.0

OS version (i.e. win10 v1607 (14393.321)): Win10

Detailed repro steps so we can see the same problem

1. Take a C++ project and compile it. Let's say the resulting assembly has a name like this: C++Adapter.dll

2. Create a .nuspec file for the project. At this point, I know that <id> does not accept special characters like '+'

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2011/08/nuspec.xsd">
  <metadata>
    <id>CPlusPlusAdapter</id>
    <version>$version$</version>
  </metadata>
  <files>
    <file src="..\bin\*.dll" exclude="**\*.pdb;**\*.dll.metagen" target="MyFolder" />
  </files>
</package>

1. Run command-line to create package:
   C:\Tools\NuGet\v4.3.0>nuget pack "C:\C++Adapter.nuspec" -outputDirectory C:\packages -version 1.0.0.0

2. Look inside the package: C%2B%2BAdapter.dll

This is only happening with the command-line. NuGet Package Explorer handles this test case just fine.

[mishra14]

@rohit21agrawal is this expected?

[spy008]

No. I expect NuGet.exe to keep filenames intact when creating a package.

[rohit21agrawal]

@spy008 the question was directed to me, I will look into this as soon as I can early next week and post an update and a workaround, if any.

[spy008]

I tested and if the target value has a '+' that it will also get replaced with '%2B' after running nuget pack. For example:

<files>
    <file src="..\bin\*.dll" exclude="**\*.pdb;**\*.dll.metagen" target="C++Adapter" />
  </files>

[sandyarmstrong]

Any update on this? I haven't been able to determine a workaround. Even if I use explicit paths (instead of globs) in src and target, my spaces still get escaped.

I'm using NuGet 4.4.1.4656 on Mono 5.4.1.7, macOS 10.13.1.

[rohit21agrawal]

we are investigating this issue as we speak, will post details when we have an update.

[sandyarmstrong]

It looks like this behavior may be intentional. Although my file names are URI-escaped when I manually unzip, actually installing the package reverses the process.

[rohit21agrawal]

@sandyarmstrong would you be willing to test out this fix on macOS and mono please? would love validation on cross-plat

[sandyarmstrong]

@rohit21agrawal if the build for that PR generates a nuget.exe I can download, I'll happily test it.

[rohit21agrawal]

NuGet.zip

@sandyarmstrong attached nuget.exe with the fix. waiting for your validation before merging

[sandyarmstrong]

@rohit21agrawal sorry it took me awhile to get around to testing.

I can confirm that the file names look correct if I manually unzip now. They also continue to look correct if I extract via package installation.

There is a separate issue, and again this may be intentional: executable files are not marked executable if I manually unzip, but do retain the executable bit when extracted via package installation.