Allow disabling the AssetTargetFallback dependency resolution via an environment variable

[nkolev92]

Bug

Fixes: NuGet/Home#11564

Regression? Last working version:

Description

Some users have been affected by the recent bug fix to start resolving the dependencies via AssetTargetFallback. In particular, https://github.com/NuGet/NuGet.Client/pull/4372/files is the change.

NuGet/Home#11564 has testimonials about it, and as a response we will:

• Disable the behavior in 17.3/6.3/6.0.400.
• Remove the fallback in 17.4/6.4/7.0.100.

This should ease the transition for the more severely affected customers.

Normally the most convenient way of disabling this would be a property in the project, but that change creates a bunch of public API changes that we'd need to keep.
Current NuGet does a lot of heavy caching when running restore, to ensure that we don't do multiple assets selections for a package id/version/framework. In order to ensure correctness, we'd have to account for this extra variable as well, whether ATF dependency resolution is enabled or not.
I'd argue this is risky and especially given that we'd want to revert this in 17.4, I think the cost would be too high to do it on a project level.
For reference this is how the other change would look like: https://github.com/NuGet/NuGet.Client/compare/dev-nkolev92-ATFDependenciesBehaviorFallback?expand=1.

The env var name is NUGET_USE_LEGACY_ASSET_TARGET_FALLBACK_DEPENDENCY_RESOLUTION and only the true case ignored value will be considered.

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 - TBD. Waiting on approval from @aortiz-msft on this.
  • OR
  • N/A

[jeffkl]

In my opinion, having to set an environment variable is a little rough. Say my entire repository isn't working with ATF yet, I can't expect everyone who clones and builds it to set an environment variable. It would be much better if it was an MSBuild property I could set instead but of course that's a lot more work for us 🤕

[nkolev92]

In my opinion, having to set an environment variable is a little rough. Say my entire repository isn't working with ATF yet, I can't expect everyone who clones and builds it to set an environment variable. It would be much better if it was an MSBuild property I could set instead but of course that's a lot more work for us 🤕

Yeah, it creates maintainability issues down the line if we did properties :(

Fortunately, I don't expect this to be used heavily.

[jeffkl]

An env var is better than nothing but I still think a property would be best