Add option to enable floating versions in CPM

[jeffkl]

Bug

Fixes: NuGet/Home#10432

Regression? Last working version:

Description

By default, central package management (CPM) does not allow users to specify floating version (i.e. 1.*). CPM is considered an enterprise-level feature and since floating versions can introduce non-deterministic restores we want users to not be able to get situations where restores in different environments could not be identical.

However, the community has left a good amount of feedback that such a feature should be allowed with more details available in NuGet/Home#10432. This change allows a user to enable floating versions by setting an MSBuild property which remains off by default.

The only place the MSBuild property will be documented is at https://learn.microsoft.com/en-us/nuget/reference/errors-and-warnings/nu1011 where users will be encouraged to use non floating versions and educated on the potential issues they could encounter.

Original pull request: #5440
This pull request is a revert of a revert plus a change to set the property so that it won't fail DDRITs this time.

PR Checklist

• PR has a meaningful title

• PR has a linked issue.

• Described changes

• Tests

  • Automated tests added
  • OR
  • Test exception
  • OR
  • N/A

• Documentation

  • Documentation PR or issue filled
  • OR
  • N/A

[nkolev92]

I just reviewed: 6809e89 :D

[zivkan]

GetPropertyValueWithDteFallback should not be used by any new MSBuild properties. As a team, we need to find a way to stop people blindly copy/pasting "old code" that uses the DTE fallback, so we can slowly migrate towards a no-DTE future.

[zivkan]

If you have any ideas on how we can reduce the risk of someone using GetPropertySafe or GetPropertyWithDteFallback the next time anyone adds a new property, then the whole team will benefit.

Unfortunately I don't have any ideas, other then hoping that someone knowledgeable notices during pull requests, which is at high risk of human error.

[jeffkl]

If you have any ideas on how we can reduce the risk of someone using GetPropertySafe or GetPropertyWithDteFallback the next time anyone adds a new property, then the whole team will benefit.

Unfortunately I don't have any ideas, other then hoping that someone knowledgeable notices during pull requests, which is at high risk of human error.

Could we mark the implementation as obsolete and add an exception for existing calls? We could put it in an #if DEBUG so it would only fail our local build if someone tried to use it going forward.

[zivkan]

Could we mark the implementation as obsolete and add an exception for existing calls? We could put it in an #if DEBUG so it would only fail our local build if someone tried to use it going forward.

I don't see how that would work. Consider we already had a block of:

#pragma disable ObsoleteWarning
var featureThing = GetPropertySafe("FeatureThing");
var featureStuff = GetPropertySafe("FeatureStuff");
var featureWhatever = GetPropertySafe("FeatureWhatever");
#pragma enable ObsoleteWarning

Now someone wants to add a property featureAnotherOne. I think they're likely to just copy paste one of the existing lines, where the obsolete warning has already been disabled.

Especially if you consider that the legacy PR project class has dozens of lines getting properties. Unless we have the obsolete warning suppression/re-enable every few lines, then someone modifying code right in the middle of the block is unlikely to even see the obsolete warning being suppressed.

On the other hand, maybe doing it anyway at least has a chance that someone will notice that GetPropertySafe and GetPropertyValueWithDteFallback are marked obsolete. Especially if we also make sure XMLDoc says to use the other method, so mouse hover intellisense is also a way this information can be discovered.

Previously I was letting perfect be the enemy of good. Apologies to @kartheekp-ms who brought up the same idea earlier, and I similarly said at the time I didn't think it would work. It's still an improvement, so better than doing nothing.

I'm happy to do this in another PR if you like.

[naiksujit]

Hi @jeffkl : Can we use this with projects that are compiled with netSDK6?

[jeffkl]

As long as you're building with the latest .NET SDK or Visual Studio, you can still compile applications and libraries for .NET 6 and use this functionality. If you're using an older version of .NET SDK or Visual Studio, this functionality will not exist and can not be used.