Package ecosystem
Nuget
Package manager version
The version shipped with the .NET 6 Preview 3 SDK.
Language version
C# latest (C# 9 or 10 I do not remember which one) But yes it's set to always use the latest version of C# so I can refactor to the new syntax features constantly.
Manifest location and content prior to update
I would check for every *.props file under the root of the repository and the Sdk/ sub-directory of the project for the files that use PackageReference. Yes the Project files themselves do not directly reference the packages to try to keep them short and clean.
Also the pull requests failed on the CI, so my github actions workflow to auto merge the github native dependabot pr's resulted in them not getting merged so the "manifest" files was left unchanged for now.
dependabot.yml content
https://github.com/Elskom/Sdk/tree/main/.github/dependabot.yml
Updated dependency
GenericPluginLoader from *-* -> -* (invalid version pattern to nuget which breaks dotnet restore or even dotnet build)
What you expected to see, versus what you actually saw
I expected dependabot to not open an PR to change *-* to -* which the nuget package manager does not support or like (to nuget it's a by design unsupported version pattern).
Native package manager behavior
I use nuget and I later froze my own projects (inside of my Sdk.props file) to *-* because * only includes stable releases, while *-* also includes stable, and latest prereleases (if there are any published that is). I also froze common analyzer packages within that file as well too. The version freeze was because of the number of times dependabot wanted to update them and if I hard coded the versions of the other things would result in endless tagging and releases that do no benefit but changing versions on the SDK not to mention cluttered tags and it then all becomes a mess.
Images of the diff or a link to the PR, issue or logs
Elskom/Sdk#177
🕹 Bonus points: Smallest manifest that reproduces the issue
I think the smallest manifest to reproduce this is as simple as adding a PackageReference to a new .NET console application then changing the fixed version number to *-* and provide the xml attribute that the .NET SDK uses to flag it as an implicit reference (oddly rider does not support this since forever but VS2019 does) 🤣. For .NET Console applications System.CommandLine can be used to reproduce it.
Package ecosystem
Nuget
Package manager version
The version shipped with the .NET 6 Preview 3 SDK.
Language version
C# latest (C# 9 or 10 I do not remember which one) But yes it's set to always use the latest version of C# so I can refactor to the new syntax features constantly.
Manifest location and content prior to update
I would check for every *.props file under the root of the repository and the Sdk/ sub-directory of the project for the files that use
PackageReference. Yes the Project files themselves do not directly reference the packages to try to keep them short and clean.Also the pull requests failed on the CI, so my github actions workflow to auto merge the github native dependabot pr's resulted in them not getting merged so the "manifest" files was left unchanged for now.
dependabot.yml content
https://github.com/Elskom/Sdk/tree/main/.github/dependabot.yml
Updated dependency
GenericPluginLoaderfrom*-*->-*(invalid version pattern to nuget which breaksdotnet restoreor evendotnet build)What you expected to see, versus what you actually saw
I expected dependabot to not open an PR to change
*-*to-*which the nuget package manager does not support or like (to nuget it's a by design unsupported version pattern).Native package manager behavior
I use nuget and I later froze my own projects (inside of my Sdk.props file) to
*-*because*only includes stable releases, while*-*also includes stable, and latest prereleases (if there are any published that is). I also froze common analyzer packages within that file as well too. The version freeze was because of the number of times dependabot wanted to update them and if I hard coded the versions of the other things would result in endless tagging and releases that do no benefit but changing versions on the SDK not to mention cluttered tags and it then all becomes a mess.Images of the diff or a link to the PR, issue or logs
Elskom/Sdk#177
🕹 Bonus points: Smallest manifest that reproduces the issue
I think the smallest manifest to reproduce this is as simple as adding a
PackageReferenceto a new .NET console application then changing the fixed version number to*-*and provide the xml attribute that the .NET SDK uses to flag it as an implicit reference (oddly rider does not support this since forever but VS2019 does) 🤣. For .NET Console applicationsSystem.CommandLinecan be used to reproduce it.