Remove dependency on deprecated ref package #74814
Conversation
This removes our dependency on the deprecated Microsoft.NET.Build.Extensions package. This is used under the hood when building a `net461` (or earlier) desktop TFM against `netstandard2.0` references. It contains a number of facade assemblies that bridge the gaps in a few places. There is only one test that dependend on this. I migrated it to a .NET core scenario that should cover the same area.
dotnet-issue-labeler
bot
added
Area-Compilers
untriaged
|
|
||
| solution = AddProjectWithMetadataReferences(solution, "DesktopProject", LanguageNames.CSharp, @" | ||
| solution = AddProjectWithMetadataReferences(solution, "NetCoreProject", LanguageNames.CSharp, @" |
There was a problem hiding this comment.
This changes the test here from being a net461 project referencing a netstandard2.0 to net8.0 referencing netstandard2.0. That actually matches the original issue closer by my reading. It is still under the hood though verifying that we can map symbols between the two projects when the underlying references substantially change and we have to deal with mapped symbols.
Waiting for @sharwell, @jasonmalinowski or @CyrusNajmabadi to sign off on this or let me know if I missed a subtle issue about this test.
There was a problem hiding this comment.
We probably went with testing netstandard and .NET Framework since they'd be most "different" in terms of types being in different assemblies. Is there a reason we can't keep this a .NET Framework ref?
There was a problem hiding this comment.
Is there a reason we can't keep this a .NET Framework ref?
It's difficult to keep the net461 reference because of how the mapping between netstandard2.0 to net461 works under the hood. It effectively downloads / loads a deprecated NuPkg that adds a couple dozen facade assemblies to the build. This is needed because netstandard2.0 was somewhat ret-conned into net461. If there were a lot of tests that did the netstandard -> net461 mapping I'd be inclined to get that all mapped out with basic ref assemblies and use it. But this the only test that does this.
We probably went with testing netstandard and .NET Framework since they'd be most "different" in terms of types being in different assemblies
I assure you they are quite different in netstandard2.0 and any modern .NET core TFM. For example any core primitive type goes from being defined in netstandard.dll to System.Runtime.dll. They are, quite unfortunately, substantially different.
There was a problem hiding this comment.
or example any core primitive type goes from being defined in netstandard.dll to System.Runtime.dll
OK that would worry me less here; as long as we have some test that is asserting that we can handle the cases where System.Object comes from different assemblies, we're probably good.
| @@ -130,10 +130,6 @@ Add-TargetFramework "SystemThreadingTasksExtensions" '$(PkgSystem_Threading_Task | |||
| 'NetStandard20Lib#\lib\netstandard2.0\System.Threading.Tasks.Extensions.dll' | |||
| ) | |||
There was a problem hiding this comment.
The grim reaper advances another door.
This removes our dependency on the deprecated Microsoft.NET.Build.Extensions package. This is used under the hood when building a
net461(or earlier) desktop TFM againstnetstandard2.0references. It contains a number of facade assemblies that bridge the gaps in a few places.There is only one test that dependend on this. I migrated it to a .NET core scenario that should cover the same area.