dotnet workload install should normalize pack directory name to lower case
#17438
Comments
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
Context: https://github.com/dotnet/sdk/issues/16946 Copy our template workload pack to a lowercase destination so that it can be detected and used when building and testing on Linux.
|
@DavidKarlas could you look into this? This impacts net6.0 workload work |
|
Sorry I didn’t start looking into this yet, but I plan this week so its ready for Preview 5. |
|
Root cause of problem is that we do NuGet PackageId.ToLower here: https://github.com/dotnet/sdk/blob/cb5b3ff/src/Resolvers/Microsoft.NET.Sdk.WorkloadManifestReader/WorkloadResolver.cs#L215 This should be fixed one of this two ways: Since fix will be in SDK repo, transferring issue there, but keeping assignment on myself since I plan to fix this... @mhutch since you wrote original .ToLower code, and since I assume you are familiar with .nupkg file names casing missmatches, what do you think is preferred way to fix this? |
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
|
The ID in the on-disk path of the nupkg and extracted nupkg is expected to be lowercased to match what NuGet does (see It's expected that whatever installs the pack files (e.g |
|
@dsplaisted @wli3 Is it OK if I close this issue? Do you want to open new one for |
|
@DavidKarlas let me just rename this issue |
wli3
changed the title
dotnet workload install should normalize pack directory name to lower case
|
FWIW I'm not dead set on the lowercasing. If folks have strong opinions otherwise we could consider preserving original case. But either way there should be a consistent policy so that the casing of the paths returned from the manifest reader always matches the casing of the paths installed on disk. |
|
@grendello how did install the package to this directory, was it using the |
|
Maybe it was |
It was installed by our internal code in Xamarin.Android. Until NET6 is released, we build and "install" packages with our runtime in the copy of the current dotnet6 version we're using (also installed by us). The nuget in question was created with CamelCase simply following the convention used for all of our packages. |
|
It sounds like the issue was in temporary code and shouldn't repro with the real workload installer then. Is there any action needed here? |
|
If it is a temporary issue, we can close. |
I think there's a need to fix this. While I noticed it using temporary code, anyone can grab a template pack from the Internet and put it in the |
I imagine we don't want to encourage that scenario anyway. |
|
Agree. That is not a supported scenario. Especially considering dotnet folder could be in program files. |
dotnet workload install should normalize pack directory name to lower case
Original issue:
I discovered that even though the Xamarin.Android templates package (named
Microsoft.Android.Templates.11.0.200-ci.main.216.nupkg) was installed indotnet/template-packs, it wasn't considered bydotnet new. After running dotnet understrace, I found that it checks for the presence of the following packages intemplate-packs(apparently hardcoded?):Copying our package to the
dotnet/templates/directory or renaming it to all lower case indotnet/template-packsmadedotnet newshow the templates defined there.I think for the best cross-platform support,
dotnet newshould perform a case-insensitive check for the presence of template packages.The text was updated successfully, but these errors were encountered: