Dependency drift across .NET 8 and .NET 9 packages

[baronfel]

Product

dotnet CLI (dotnet new)

Describe The Bug

Chatted with @sayedihashimi and @phenning today about if/when VS should update to 9.x Template Engine packages, and we saw some discrepancies that are concerning.

.NET 8 package:

.NET 9 package:

The big problems I see are:

• the .net framework TFM has floated to something VS can't use - net481. VS requires net472 currently. This comes from the Arcade NetFrameworkCurrent property I think?
• the NS2.0 dependencies dropped the System. deps, which may require work from Phil to consume (he mentioned missing deps in the past)

Were these on purpose? Do we need to have tests to pin the expectations of the VS host so we don't unwittingly violate them?

To Reproduce

N/A

dotnet Info

N/A

Visual Studio Version

No response

Additional context

No response

[marcpopMSFT]

So is the simple fix to just switch back to 472 and add back the System* dependencies? Do we have a pointer to when those got removed?

[baronfel]

maybe? I don't know when/why they were removed, so maybe it was a CG thing?

[phenning]

I looked through history and found it was first floated here, with no context other than "Fix incompatibility", but in actuality broke our ability to update later versions to Visual Studio. Since then, there have been updates to how this is controlled, and it has floated to 4.8.1.

d8b8f75

Note that this means that for at least Visual Studio 2022, we will be limited to the 8.0.xxx template engine updates unless it's framework dependency is updated during servicing. If Visual Studio vNext is still built against 4.7.2, we will likewise be limited to Template Engine 8, unless we can move to the net standard library or run in service hub or similar workaround.