Description
Description
Previously we were calling the ResolvePackageDependencies Target in order to generate PackageDependencies and PackageDefinitions but this data was already available from a different Target. Instead we now add those two items from PreprocessPackageDependenciesDesignTime into our design time build cache and don't call the prior target.
Version
.NET 7
Previous behavior
We were calling an existing .NET SDK Target to get information on packages that we already had available.
New behavior
dotnet/sdk#28405
With the two items being included in the design time cache, customers who were depending on PackageDependencies and PackageDefinitions in their builds will see build errors: dotnet/sdk#30809
This change was introduced in 7.0.200
Type of breaking change
- Binary incompatible: Existing binaries may encounter a breaking change in behavior, such as failure to load or execute, and if so, require recompilation.
- Source incompatible: When recompiled using the new SDK or component or to target the new runtime, existing source code may require source changes to compile successfully.
- Behavioral change: Existing binaries may behave differently at run time.
Reason for change
Performance in some situations was particularly slow for the prior Target. Solutions with very large NuGet dependency graphs will see faster IntelliSense after solution loads, branch switches, or when making solution-wide changes while using the Central Package Management feature.
Recommended action
Add <EmitLegacyAssetsFileItems>true</EmitLegacyAssetsFileItems> to your project to return to the legacy behavior if your build depends on this. We expect this to only impact a small number of users.
Feature area
SDK
Affected APIs
No response