Unable to add versioning Nuget package

[Mdub28]

Hello, when adding the nuget package Microsoft.AspNetCore.Mvc.Versioning 4.0.0 or 4.1.0, we are hitting the following exception:

Part URI cannot start with two forward slashes.

This only happens when we use tools like Nuget Package Explorer to download the nuget. It does not seem to happen when consuming directly from Visual Studios.

It seems this is caused by the same issue as described here: microsoft/onnxruntime#664

Any chance we could get a similar fix? Thanks

[commonsensesoftware]

Are you sure you don't just have an old version of the NuGet Package Explorer? I use this tool all of the time. More specifically, I always double-check the packages before publishing them to NuGet because if I make a mistake, there's no undoing it or updating the same version.

I installed the NuGet Package Explorer through the Windows Store so that it's automatically updated now, but that's not necessarily a requirement. I'm using this version and it works fine.

All of the metadata and packing is done through the build process. I don't craft anything by hand. Just to be sure, I checked the metadata XML extracted from the NuGet Package Explorer and I don't see any single or double slashes in it. I've also used the latest packages with the .NET SDK without issue, which is not quite the same as Visual Studio/MSBuild.

Happy to help, but thus far I'm unable to reproduce your issue. The externally referenced issue doesn't seem to apply. Maybe try updating NuGet Package Explorer?

[nathanmerrill]

All of the metadata and packing is done through the build process. I don't craft anything by hand. Just to be sure, I checked the metadata XML extracted from the NuGet Package Explorer and I don't see any single or double slashes in it. I've also used the latest packages with the .NET SDK without issue, which is not quite the same as Visual Studio/MSBuild.

I still see it in the latest metadata (4.1.0 in [Content_Types].xml line 10)

I'm the one who initially investigated this issue. We internally use a tool that uses the same packing library (System.IO.Packaging) as NuGet Package Explorer, and we are getting the same error. I'll see if there's an update to this library.

[commonsensesoftware]

That would mean that there is a fundamental issue with the MSBuild tooling and likely the NuGet tooling itself. All of these packages are built with dotnet pack.

[nathanmerrill]

Something changed between version 3.1.6 and version 4.0.0. In 3.1.6, that line only has a single slash, but in 4.0.0, there are two.

[commonsensesoftware]

Dunno. I don't poke around in what is auto-generated in the packages. Sounds like there was a change in how NuGet creates packages. This repo and all of its packages have only ever used dotnet pack or msbuild -t:Pack (which is the same thing). I can only presume that it may be a regression in the NuGet APIs or they updated something that may have previously been off-spec. I would expect any package generated though their tooling to produce the same behavior.

The (latest) NuGet Package Explorer doesn't have a problem reading any of these packages - locally or from the feed. Either they did something special to handle this situation or there's something different about what they do versus what you do (if it's not just library references).

[nathanmerrill]

NuGet Package Explorer did move off of it: NuGetPackageExplorer/NuGetPackageExplorer@8ccf236

From the look of things, it looks like this assembly is deprecated :(

Thanks!

[commonsensesoftware]

As I recall, the packaging spec is based on OpenXML, which what's used by System.IO.Packaging, all Microsoft documents now (*.docx, *.xlsx, etc), NuGet, and more. It's quite possible that the NuGet implementation has deviated from the spec. It probably won't help you in the short term, but if you have/find some evidence to support this claim, it's worth reporting to the NuGet team. If it's truly wrong, hopefully they will fix it - at some point.

[commonsensesoftware]

Doesn't seem like there is anything more I can help you with from this repo. As a follow up, if you think (or know) the NuGet packaging implementation has gone off-spec, you can file an issue on their repo. You can probably even find the issue and submit a PR, if you're so inclined. Another option is to check the System.IO.Packaging implementation and/or possibly submit a PR there now that it's open source.

I hope that helps.

[LeadAssimilator]

This is broken in VS2015's NuGet Package Manager. This should be fixed as requested in the OP with reference to microsoft/onnxruntime#664 to preserve compatibility with older toolchains that do not support // in PartName, nor can be updated. The previous package version 3.0.4 with a single / was working ok.

If this is opted not to be fixed, then at the very least minClientVersion should be specified correctly, to block installation of this package by unsupported nuget clients.

Either way, this is definitely a bug in the authoring of this package and should not have been closed. Even if the issue is related to the package authoring tools, a workaround should be put in place until they can be properly addressed, just as others have done.

[commonsensesoftware]

@LeadAssimilator after re-reading the linked issue, I have a better understanding; sorry, I misunderstood. I thought this was about an incompatible packaging API or something.

To recap, the real issue is that NuGet pack does something unexpected when a file has no extension. I always thought that was kind of weird and wondered if it would cause an issue. As I recall, the license file has been completely unchanged since the repo's creation. I'm guessing this issue first manifest when I switched from the legacy license file style to the new license expression style. To be congruent with other packages, I still add the actual license file in the package.

Option 1 would be to simply stop packing this file. Option 2 would be to just rename the file to LICENSE.txt so it has an extension. Looking at the .NET and ASP.NET repos, they now include the .txt extension in the license file so renaming the file seems to be the way to go.

I'll make this change and it will go out in the next patch. Thanks for challenging the closing. 😉

[LeadAssimilator]

Great thanks!

I also discovered that if you set PackagePath="" rather than "\" or "/" for each item you are packing without a file extension, the extra / in PartName disappears. So until nuget can properly fix this bug, that could also be a viable workaround for files that one doesn't want to give an extension to. Too bad the nuget docs have samples with PackagePath="\" that no doubt people will copy/paste and run into this issue with.

FWIW, the original exception comes from System.IO.Packaging.PackUriHelper which validates the PartName attribute of the Override tags inside the [Content_Types].xml of the resulting nuget package, expressly disallowing it to start with //. Any tool that attempts to use the opc package facilities in System.IO.Packaging on an affected nuget package will pretty much die because of it. I'm guessing newer versions of nuget no longer use System.IO.Packaging so they appear to work ok, but that unfortunately ends up hiding the fact that the nuget package authoring tools are actually bugged and can produce non-compliant opc packages sometimes.

[LeadAssimilator]

I don't think nuget is aware of this issue still, so I reported it as NuGet/Home#9097 with reference to your project for reproduction.

[schnitty]

I see there is a PR outstanding from January to fix this. Will this be merged?
I'm currently experiencing this issue in VS2015

[commonsensesoftware]

It will be merged. I was hoping to combine it with real changes as well. Been a bit overwhelmed recently. I'll see if I can't get this pushed out this week.

Does anyone know if there is a manual workaround? I suspect if you use a vCurrent nuget.exe directly, that will unblock you (albeit painfully). This should the same process you use on your build server.

[schnitty]

It works ok, just a blocker in Visual Studio 2015 if I want to do anything with any nuget packages. Unfortunately the client environment I am working in mandates I use Visual Studio 2015 so I have no easy way around it. Thanks for merging it this week, it will be a big help.

[kernelcoredump]

It will be merged. I was hoping to combine it with real changes as well. Been a bit overwhelmed recently. I'll see if I can't get this pushed out this week.

Does anyone know if there is a manual workaround? I suspect if you use a vCurrent nuget.exe directly, that will unblock you (albeit painfully). This should the same process you use on your build server.

Later/current NuGet clients know how to handle the extension-less file in the package.

We have one internal workflow that, likely similar to VS2015, uses NuGet.Core (2.x) which has long been deprecated. We are still in the middle of refactoring this internal process, so the PR for this issue will help for a bit. Otherwise, the workaround we use is to host our custom copies of the packages with package signatures removed and file renamed to LICENSE.txt using Package Explorer.