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. 😉