NuGet package Id comes through with incorrect case

[ianbattersby]

Minor issue;

Just noticed that the Id of the NServiceBus.StructureMap on NuGet has the incorrect case, despite the nuspec in source having it correct.

Should be -> NServiceBus.StructureMap
It is -> NServiceBus.Structuremap

In packages.config;

<package id="NServiceBus.Structuremap" version="4.0.0-unstable3205" targetFramework="net40" />

Project reference it is capitalised (as per nuspec Id) but physical directory is not;

<HintPath>..\packages\NServiceBus.StructureMap.4.0.0-unstable3205\lib\net40\NServiceBus.ObjectBuilder.StructureMap.dll</HintPath>

The significance of this is the packages directory that gets created and that on a case-sensitive volume causing a reference error.

Might be something you can edit on nuget.org.

[johnsimons]

I have sent a support email to the nuget guys.
Now lets wait and see!

[ianbattersby]

@johnsimons Any news? This is a royal PITA.

[jeffhandley]

The NuGet team is investigating if this can be addressed on the gallery. We've never successfully changed the case of a package before, but we recently made some changes that we believe will allow us to do so.

However, with this specific repro, we need to make sure we don't regress old versions of the package by fixing the new version.

[jeffhandley]

So here’s something strange…

1. If I install through the PowerShell console, I get “NServiceBus.Struturemap” in both my packages.config and my project file.
2. If I install through the dialog, I get “NServiceBus.StructureMap” in both my packages.config and my project file.
3. I cannot reproduce the scenario of getting one casing in one place and the other casing in another place.

We plan to proceed with fixing the casing on nuget.org, but it would be great if we could reproduce the error so that we can verify our fix will correct the repro. Any help with repro steps to get into that bad state would be appreciated.

[SimonCropp]

@jeffhandley it is great that you are looking into the permanent fix for this. In the short term is it possible to fix our package in the back-end database/system that nuget uses?

[jeffhandley]

We are trying to fix only your package at first. But we need to verify we don't completely bust your package while doing so, as this is something we've only once attempted to fix before, and we broke the package we were trying to fix and we had to revert the change.

To verify that we don't bust your package while fixing the data, we would like to reproduce the problem as illustrated above before fixing it, and then make the fix in our staging environment, and ensure we don't regress earlier versions of your package.

[SimonCropp]

@jeffhandley all fair enough. Take as much time as u need not to "completely bust the package" :)

[jeffhandley]

:-) So back to the question at hand... any tips on how to reproduce the behavior shown in the initial report?

Thanks!

[johnsimons]

@ianbattersby can you help @jeffhandley to replicate this issue?

[ianbattersby]

@jeffhandley / @johnsimons

I suspect it's something to do with NuGet targets restore, the only difference I can think from that stated above.

1. New project | Console project
2. Open NuGet and add pre-release versions of NServiceBus/.Interfaces/.StructureMap
3. Enable NuGet restore
4. Close VS and save out

Results:-

Zip is here: https://dl.dropboxusercontent.com/u/795371/NSBNuGetCaseIssue-Example.zip

[johnsimons]

Not sure if it affects the repro but no need for pre-release flag anymore.
V4 is out :)

On Thursday, July 11, 2013, Ian Battersby wrote:

I suspect it's something to do with NuGet targets restore, the only
difference I can think from that stated above.

1. New project | Console project
2. Open NuGet and add pre-release versions of
   NServiceBus/.Interfaces/.StructureMap
3. Enable NuGet restore
4. Close VS and save out

Results:-
[image: image]https://f.cloud.github.com/assets/185776/780888/f07a845a-ea0f-11e2-83ce-ab4f0d6baa21.png

Zip is here:
https://dl.dropboxusercontent.com/u/795371/NSBNuGetCaseIssue-Example.zip

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1271#issuecomment-20801151
.

Regards
John Simons
NServiceBus

[jeffhandley]

I was just able to reproduce the issue against production, which is good!

1. New Console Application
2. PMC: install-package nservicebus.structuremap
3. Enable NuGet Package Restore on the solution
4. Close VS

At this stage, I have the following:

• packages.config: "NServiceBus.Structuremap"
• csproj: ..\packages\NServiceBus.Structuremap.4.0.0.1...
• packages folder: "NServiceBus.Structuremap.4.0.0.1"

But, now with a few more steps it will be broken:

1. Delete the packages folder
2. Reopen the solution
3. Build (which does package restore)

At this point, only one things changes and that's the packages folder. It's now "NServiceBus.StructureMap.4.0.0.1."

However, if between steps 2 and 3, you were to have cleared your NuGet package cache, then this would no longer repro.

Root cause:
When installing a package from cache, we don't have the server's casing of the package Id; instead, we rely on the casing from the nupkg file stored in cache.

If the nupkg has different casing from what the server had when the package was installed, then you'll end up in the mismatch.

Result:
That means that if we change the casing of the package, it will fix the current version, but it will break any past versions where the nupkg had the incorrect casing. It looks like that would only be the first 2 versions of this package.

In order for nuget.org to fix the issue across all versions of a package, that would mean we'd need to start storing the casing of a package's id with each version, allowing it to differ from version to version to match what the nupkg has for that version.

Should we proceed with the change for this package?

[johnsimons]

Hi Jeff,

Yes please go ahead with the case fixing.

Thanks
John

On Friday, July 12, 2013, Jeff Handley wrote:

I was just able to reproduce the issue against production, which is good!

1. New Console Application
2. PMC: install-package nservicebus.structuremap
3. Enable NuGet Package Restore on the solution
4. Close VS

At this stage, I have the following:

• packages.config: "NServiceBus.Structuremap"
• csproj: ..\packages\NServiceBus.Structuremap.4.0.0.1...
• packages folder: "NServiceBus.Structuremap.4.0.0.1"

But, now with a few more steps it will be broken:

1. Delete the packages folder
2. Reopen the solution
3. Build (which does package restore)

At this point, only one things changes and that's the packages folder.
It's now "NServiceBus.StructureMap.4.0.0.1."

However, if between steps 2 and 3, you were to have cleared your NuGet
package cache, then this would no longer repro.

Root cause:
When installing a package from cache, we don't have the server's casing of
the package Id; instead, we rely on the casing from the nupkg file stored
in cache.

If the nupkg has different casing from what the server had when the
package was installed, then you'll end up in the mismatch.

Result:
That means that if we change the casing of the package, it will fix the
current version, but it will break any past versions where the nupkg had
the incorrect casing. It looks like that would only be the first 2 versions
of this package.

In order for nuget.org to fix the issue across all versions of a package,
that would mean we'd need to start storing the casing of a package's id
with each version, allowing it to differ from version to version to match
what the nupkg has for that version.

Should we proceed with the change for this package?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1271#issuecomment-20865932
.

Regards
John Simons
NServiceBus

[bhuvak]

The casing is fixed for NServiceBus.StructureMap package in nuget.org.
Please be noted that it would take up to a day for the changes to reflect.

Let us know if you see any issues with it.

Thanks !

[johnsimons]

@ianbattersby can you please confirm this is fixed?

[ianbattersby]

Thanks guys, that seems to have nailed it 👍 //cc @johnsimons

[jeffhandley]

Glad to hear it. Thanks for your patience on it. It is good to know the limitations of this and the side effects.

[SimonCropp]

@jeffhandley thanks for your help

[psubramanian1582]

The same issue exists with Microsoft.AspNet.Providers.LocalDB 2.0.0 package as well. "DB" is capitalized and the package id in packages.config is . Is it possible to fix this in nuget.org

[jeffhandley]

@psubramanain1582 The owner of the package can "Contact Support" from the package details page. But because of the implications described herein, unless the owners of the package can agree it's the right thing to do, we won't make the change.