Fix Error with Uppercase Characters in Version Strings

[JohnHunhoff]

Resolve an issue where versions with uppercase characters (e.g., 1.0.0-Beta, 1.0.0.BETA.1) caused CycloneDX to throw errors. The
problem occurred because the NuGet cache converted version strings to lowercase for path names. This caused the .nuspec file to not be found.

[JohnHunhoff]

To provide additional information, the error message is "Central Directory corrupt," and it originates from the file NugetV3Service.cs. This error occurs in all versions greater than 2.3. To test, you just need a project that depends on a NuGet package with an uppercase character in the version..

[mtsfoni]

Do you happen to have an example at hand of a public package that has an uppercase character in its version?

[ecaisse]

This PR fixes #603, at least when it comes to people having issues with Linux-based build agents.

Do you happen to have an example at hand of a public package that has an uppercase character in its version?

I did not find any public NuGet packages that uses an uppercase in it's version. It may be that the public feed automatically sets all versions to lowercase.

However, for private feeds, those are possible. I have such a case using Azure Artifact feeds, where we use a timestamp as part of the version number for internal prerelease packages, similar to this format: 1.0.0-20240918T123456. Note the capital T as part of the timestamp. However, in the NuGet global cache, the folder name has a lowercase T.

In a Windows environment, that's not a problem since paths are case-insensitive. When NugetV3Service.GetCachedNuspecFilename check if the file exists, it returns true despite casing being different. Since it's in the global cache, nuspecFilename is not null and NugetV3Service.GetNuspec reads the .nupkg file from disk as expected.

That is not the case with Linux. In that case, the file cannot be found because of the casing difference, and the check fails. In NugetV3Service.GetNuspec, nuspecFilename is null, which calls resource.CopyNupkgToStreamAsync. This call fails silently since the return value is not handled (I can ran some tests and this returns false, meaning the operation failed). The stream is not a valid package (most likely empty), which then throws an error when trying to parse the Nupkg archive.

To the best of my knowledge, the NuGet client normalizes versions to lowercase in the global cache when restoring packages. The GlobalPackagesFolderUtility class instantiates a VersionFolderPathResolver with the parameter isLowerCase equal to true (using the default parameter value). The Normalize method for the NuGet version will return a lowercase version to be used as part of the path on disk.

[JohnHunhoff]

I don't have an example, the error occurred to me with private packages self hosted on directory or nexus repository manager in linux. The only public package I know of is https://www.nuget.org/packages/Unity/5.9.0-RC1.

[Bjornej]

I've stumbled upon the same problem as @JohnHunhoff with our private packages (we use nexus on windows as private repository) and I can reproduce the problem and that the fix solves it.

Can this pull request be merged or an example that shows the problem and the solution is needed before?