fix(dotnet): Ensure that packages can be updated when referencing .NET workloads

[jeromelaban]

What are you trying to accomplish?

This PR is adding an MSBuild property that will prevent this .NET SDK target to execute in order to continue getting the dependency graph.

Fixes #10117

Anything you want to highlight for special attention from reviewers?

There does not seem to be another way to avoid getting the NETSDK1147 error.

This PR uses two specifics to get around workloads not being installed:

• It uses DesignTimeBuild to skip the workloads validation
• It defines a fake TargetPlatformVersion in order for nuget to still consider the platform-specific target frameworks.

How will you know you've accomplished your goal?

Both tests that are added will succeed, as they reference target frameworks that require the use of .NET workloads.

Checklist

• I have run the complete test suite to ensure all tests and linters pass.
• I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
• I have written clear and descriptive commit messages.
• I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
• I have ensured that the code is well-documented and easy to understand.

[JonDouglas]

lgtm, @brettfo is there a point of contact who manages the .NET dependabot stuff nowadays? I think Stephen P did last I chatted.

[brettfo]

@JonDouglas I'm a good point of contact for the NuGet updater.

@jeromelaban Could you explain more (or links so I can read more) about the $(TargetPlatformVersion) being set to 1.0? Setting $(DesignTimeBuild) to true I'm good with, but I want to make sure I fully understand the other.

[jeromelaban]

@jeromelaban Could you explain more (or links so I can read more) about the $(TargetPlatformVersion) being set to 1.0? Setting $(DesignTimeBuild) to true I'm good with, but I want to make sure I fully understand the other.

Sure! The issue here is that NuGet requires that any target framework with a platform specifier also has an SDK that defines an msbuild property with the currently supported default platform version, when none is defined in the TargetFramework.

For instance in .NET 9.0, net9.0-ios means net9.0-ios18.0 where TargetPlatformVersion is set to 18.0 by default when workloads are installed. When that property is not defined, nuget complains that it can't resolve references, and 1.0 is chosen to allow the resolver to match packages that explicitly define a version (it's generally >= 1.0).

[brettfo]

I requested one test change and you'll also have to update latest from main; there was a rename that will likely cause a conflict.

[brettfo]

Thank you for this! I should be able to get it merged and deployed early next week.