Can't create non RID-specific tool package if compiling with RuntimeIdentifier set

[dsplaisted]

In .NET 9, you could have a .NET Tool (PackAsTool set to true in the project file) with a RuntimeIdentifier specified. You would end up with a .NET tool package that only worked correctly on systems that matched the RuntimeIdentifier.

In .NET 10, we added support for RID-specific .NET Tools. This creates RID-agnostic primary package in an outer build and RID-specific packages in inner builds for each RuntimeIdentifier.

As a side effect of this, it's no longer easily possible to create a tool that is compiled for a single RuntimeIdentifier but that creates a normal tool package. When the RuntimeIdentifier is specified in a tool build, the RID-specific tool logic kicks in as it would in a tool inner build and creates a package where the RuntimeIdentifier is part of the ID.

We should add a way to opt out of the RID-specific inner build logic in order to be able to have the same behavior as previously.

We should also update the breaking change notice to cover the RuntimeIdentifier property in addition to RuntimeIdentifiers.

[baronfel]

Closing this as the implementation has been merged for GA, and the issue to update the breaking change notice has been created.