Describe the bug
Today, creating a 'pointer' package for a multi-RID .NET Tool results in a tool settings XML file at tools//any/DotnetToolSettings.xml, which means that the TFM check will fail on SDKs/platforms that are lower than that TFM.
The point of this file is to be read all the time, and the contents of the file determine compatibility. We should write these files at the any TFM instead so that all consumers can at least find and read the manifest.
Steps to reproduce
Compare/contrast the pointer packages for dotnet-inspect and Azure.Mcp.
dotnet-inspect is the model we want to follow here
Expected behavior
SDKs less than 10 can find and read the manifest for a RID-specific tool package, even if they can't execute the tools themselves.
Actual behavior
The CLI emits an error about not being able to find the tool settings file.
Is this a regression?
No response
Are there any workarounds?
No response
dotnet --info output
IDE version
No response
Other details
No response
Describe the bug
Today, creating a 'pointer' package for a multi-RID .NET Tool results in a tool settings XML file at tools//any/DotnetToolSettings.xml, which means that the TFM check will fail on SDKs/platforms that are lower than that TFM.
The point of this file is to be read all the time, and the contents of the file determine compatibility. We should write these files at the
anyTFM instead so that all consumers can at least find and read the manifest.Steps to reproduce
Compare/contrast the pointer packages for dotnet-inspect and Azure.Mcp.
dotnet-inspect is the model we want to follow here
Expected behavior
SDKs less than 10 can find and read the manifest for a RID-specific tool package, even if they can't execute the tools themselves.
Actual behavior
The CLI emits an error about not being able to find the tool settings file.
Is this a regression?
No response
Are there any workarounds?
No response
dotnet --info output
IDE version
No response
Other details
No response