Remove support for DotNetCliToolReference

[dsplaisted]

Back in .NET Core 1 and 2, we had a concept called "project tools". These could be declared in the project file using a DotNetCliToolReference. These were effectively replaced by local tools in .NET Core 3, and we made it so that you could not create a project tool targeting anything higher than .NET Core 2.2.

Given that .NET Core 2.2 is long out of support, we should consider removing the code from the .NET SDK which supports creating and consuming these tools. This includes ProjectToolsCommandResolver, tasks and targets supporting creating these packages, and possibly more.

[KalleOlaviNiemitalo]

https://learn.microsoft.com/en-us/dotnet/core/additional-tools/xml-serializer-generator tells users to add both PackageReference and DotNetCliToolReference. Doesn't Microsoft.XmlSerializer.Generator require DotNetCliToolReference any longer?

[baronfel]

Checking out the targets file in this package, they do directly call the generator tool via dotnet tool-name in a way that invokes this resolver (see line 51). However, this is just bad practice. This package should

• directly invoke the dll shipped in it (which would remove the need for this resolver)
• not bundle their dll in the lib folder (which causes consumers of the package to ship the generate in their runtime assets)

We need to poke the owning team (@HongGit - can you or your team chime in?) to get these resolved.

[baronfel]

Added #45251 to track usage of the various resolvers like ProjectToolsCommandResolver.

[KalleOlaviNiemitalo]

Related XmlSerializer doc issue:

• Using depracted DotNetCliToolReference in tools guide docs#26253

[marcpopMSFT]

We need to poke the owning team (@HongGit - can you or your team chime in?) to get these resolved.
@HongGit any thoughts here about changing how the xml tool is called so we can remove this dependency?