DevAudit
DevAudit copied to clipboard
Unusual .Net Core package version strings crash
I have a .Net Core project with a dependency on Swashbuckle.AspNetCore. It just so happens that my dependency is on an old pre-release, but valid (as far as NuGet.org is concerned) version string. This causes DevAudit to crash.
Here's a simplified example of my project file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Swashbuckle.AspNetCore" Version="5.0.0-rc4" />
</ItemGroup>
</Project>
I am running the scan using the following command:
docker run -it -v $(pwd):$(pwd) ossindex/devaudit netcore -d -f $(pwd)/example.csproj
This error occurs:
05:30:36<01> [AUDIT] [ERROR] Error in WaitAll method in GetPackages task.
Caller: Audit
Line: 143
File: /home/vsts/work/1/s/DevAudit.AuditLibrary/Targets/PackageSource.cs
Scanning .NET Core packages...
05:30:36<01> [AUDIT] [ERROR] Exception occurred.
One or more errors occurred. ('5.0.0.rc4.0' is not a valid version string.
Parameter name: value) Inner Exception: '5.0.0.rc4.0' is not a valid version string.
Parameter name: value
Stack trace: at System.Threading.Tasks.Task.WaitAll (System.Threading.Tasks.Task[] tasks, System.Int32 millisecondsTimeout, System.Threading.CancellationToken cancellationToken) [0x001c8] in <1381561d6ee6458bb38456851c867024>:0
at System.Threading.Tasks.Task.WaitAll (System.Threading.Tasks.Task[] tasks, System.Int32 millisecondsTimeout) [0x00000] in <1381561d6ee6458bb38456851c867024>:0
at System.Threading.Tasks.Task.WaitAll (System.Threading.Tasks.Task[] tasks) [0x00000] in <1381561d6ee6458bb38456851c867024>:0
at DevAudit.AuditLibrary.NetCorePackageSource.GetPackages (System.String[] o) [0x00272] in /home/vsts/work/1/s/DevAudit.AuditLibrary/PackageSources/NetCorePackageSource.cs:102
at DevAudit.AuditLibrary.PackageSource.<GetPackagesTask>b__48_0 () [0x00000] in /home/vsts/work/1/s/DevAudit.AuditLibrary/Targets/PackageSource.cs:215
at System.Threading.Tasks.Task`1[TResult].InnerInvoke () [0x0000f] in <1381561d6ee6458bb38456851c867024>:0
at System.Threading.Tasks.Task.Execute () [0x00000] in <1381561d6ee6458bb38456851c867024>:0
Caller: Audit
Line: 143
File: /home/vsts/work/1/s/DevAudit.AuditLibrary/Targets/PackageSource.cs
I can see the issue. I just don't know how to correct it. It appears to be a problem in the Versatile library which is pulled in and used to parse the versions.
- in the case of 5.0.0.rc4.0, it is interpreting the last period as part of the version
- in the case of 1.0.0-rc-00260, it can't interpret the multiple hyphens. I am adding these findings to issues in the https://github.com/allisterb/Versatile repo
Sorry for the delay, and thanks for the help! We have been dealing with a bit of a backlog, and will try to resolve this issue shortly. Thanks for helping with the root cause, that will surely help speed things up!
Hi, I created a pull request on the allisterb/Versatile repo to fix the 2nd case with multiple dashes.
I saw that the public version of Versatile is much older (0.1.14) than the version available in NuGet (0.2.6), but I expect that the fixes also be applicable to the latest version of Versatile for someone who has that code.
Thanks for this. I have finally managed to get back into working the project. I will figure out where this newer version resides and get it patched and merged in. Sorry again for all the delays. We are currently without a full time maintainer, but are working hard on getting that resolved. The chaos caused by Covid has made things a bit more complicated than before :|
I suspect that the code in GitHub just has not have the version incremented, as it was last updated in March 2019 and the 0.2.6 NuGet release was on April 1rst, 2019.
I made a fork and will merge your code in there and draft a release using that code. We can see how that works.
I have linked an unreleased build of DevAudit here. It has an embedded Versatile library with your changes to it. The code is directly from Versatile master with your changes merged on top, as I think the version numbering is handled by an Azure Devops build and the code just doesn't update accordingly.
If you could give this a check and see if it resolves your problem that would be swell. If it doesn't work then I will finish getting a working reproduction of your bug and try and go further.
Thanks for the update. I can confirm that your version 3.4.1.0 not longer crashed on project containing at least one package with complex version number (multiple dashes and dots in the end for example 1.0.0-rc-00260.23). Unfortunately my/our patch does not fix the the issue reported by aidansteele for netcore parsing of csproj.
Update: My patch existed in a fix issue in a dependent library (Versatile) that parses nuget library versions. I did not realize that for netcore the versions are parsed in a different way.
Please update the chocolatey build to version 3.4.1.0, so that we can use this fix in our projects
I (still) have the same issue with the linked version v3.4.1.0 on a scan for netcore:
One or more errors occurred. Inner Exception: '1.0.0.beta2.0' is not a valid version string.