Queries to NuGet sources should respect case-sensitivity

Description

Paket 5.114.4 queries sources with package name lower-cased, resulting in lookup failure. Package sources can be case-sensitive, and Paket should respect paket.dependencies case.

Repro steps

1. Upload you camel-case named package (like “My.Secret.Package.SDK”) to case-sensitive source, e.g. Artifactory NuGet repository.
2. Create paket.dependencies with your package name, may be direct and transitive at the same time, with constraint like My.Secret.Package.SDK ~> 1.2.3.4.
3. Call paket update --no-install --force to create paket.lock.

Expected behavior

Queries to any sources shall respect the package name casing, either from paket.dependencies or as downloaded (e.g. from nuspec file/package metadata). If there are multiple case versions detected for a package, warning or error should be produced, and in case of choosing a warning, sources should be queried for all the known alternatives.

Actual behavior

Observe the queries generated from STR: they will look like: http://nuget.local/artifactory/api/nuget/nugets/Packages(Id=‘my.secret.package.sdk’,Version=‘1.2.3.4’) and return 404 NotFound. And Paket will fail with `Conflict detected:

• Dependencies file requested package My.Secret.Package.SDK: == 1.2.3.4
• Available versions:
• (2.3.4.5, [http://nuget.local/artifactory/api/nuget/nugets])
• (1.2.3.4, [http://nuget.local/artifactory/api/nuget/nugets])
• (1.2.3.1, [http://nuget.local/artifactory/api/nuget/nugets])`.

Known workarounds

None, paket.dependencies and the package metadata already match the actual package file/name case, and our NuGet repository, Artifactory, is configured as case-sensitive outside of our control.

[vbfox]

So this issue (or a very similar one) broke things for us, with paket having very weird behaviors since a few weeks ago (When we upgraded to a version with the lowercasing). Some changes to dependencies worked in paket install but others produced infinite loops.

From a fiddler trace it seemed that Paket was trying to get the problematic package from our ProGet with the lowercase syntax and never trying the non-lowercase one.

Turns out it was a produced by the fact that one of our package source is a TeamCity feed cached by ProGet (Paket -> ProGet -> TeamCity) :

• TeamCity feed is case-sensitive on nuget Id (I created a new issue on that https://youtrack.jetbrains.com/issue/TW-52167 they had an old one that they closed, let’s hope this one will change their mind)
• ProGet forward requests as-is by default on “connected feeds” except if a package version has been downloaded from it’s UI, then it’s considered local. Local package are handled by ProGet internal search that is case insensitive. So we ended up with some versions downloadable and other not.
• I suspect that paket wasn’t trying a non-lowercased URL a for some versions of the same package or for other packages the lowerased version works so it assumed that it would work for all packages.
• Paket resolver when faced with this case (I didn’t reduce from our full dependencies so I don’t have a repro) entered an infinite loop…

On our side I solved this by going back to paket 5.85.0 and I’ll look into removing TeamCity from the equation.

But I suspect that TeamCity & Artifactory won’t be the only ones having that problem. They obviously need to be fixed but in the mean time paket lowercasing PackageId is creating problems with the existing servers.

If the official client is sending IDs as-is in this case (I didn’t test if they hit this exact URL) maybe doing the same is the most-compatible solution ?

[forki]

nuget package names are case-insensitive. that is an artifactory bug. but we need to work around it