Limit DotNetCliToolReference Tools to .NET Core 2.2 and Below
.NET Core 3 takes the next step in the .NET Core tool strategy with local tools. As part of this process, starting in Preview 4 DotNetCliToolReference tools will be restricted to targeting .NET Core 2.2 and below. DotNetCliToolReference tools can be used in projects targeting .NET Core 3.0, but the tools themselves should target .NET Core 2.2 or below.
Discussion
Please share your thoughts on this change and see what others are saying at:
The suggested approach going forward is to to use .NET Core Local Tools when you want a tool that is specific to a project or repository. At the same time we are removing the need to access local tools by the verbose dotnet tool run <toolname> that was present in earlier previews. You can now access local tools via dotnet <toolname>.
DotNetCliToolReference tools have a flaw in how their dependencies are restored which can create difficult to diagnose bugs when running these tools. This issue would occur much more frequently if targeting .NET Core 3.0 was allowed. Restricting tools to target only .NET Core 2.2 and below means existing scenarios to continue to work (as well as they previously did), regardless of the framework version targeted by the project or the current .NET Core SDK.
The new .NET Core tool strategy avoids this flaw in restore strategy and offers other benefits, like the ability to author one type of tool and install it in different ways depending on project and user needs.
We look forward to your feedback on .NET Core Local Tools, and on challenges you face moving away from DotNetCliToolReference tools.
Limit DotNetCliToolReference Tools to .NET Core 2.2 and Below
.NET Core 3 takes the next step in the .NET Core tool strategy with local tools. As part of this process, starting in Preview 4 DotNetCliToolReference tools will be restricted to targeting .NET Core 2.2 and below. DotNetCliToolReference tools can be used in projects targeting .NET Core 3.0, but the tools themselves should target .NET Core 2.2 or below.
Discussion
Please share your thoughts on this change and see what others are saying at:
dotnet/sdk #3115
Details
The suggested approach going forward is to to use .NET Core Local Tools when you want a tool that is specific to a project or repository. At the same time we are removing the need to access local tools by the verbose
dotnet tool run <toolname>
that was present in earlier previews. You can now access local tools viadotnet <toolname>
.DotNetCliToolReference tools have a flaw in how their dependencies are restored which can create difficult to diagnose bugs when running these tools. This issue would occur much more frequently if targeting .NET Core 3.0 was allowed. Restricting tools to target only .NET Core 2.2 and below means existing scenarios to continue to work (as well as they previously did), regardless of the framework version targeted by the project or the current .NET Core SDK.
The new .NET Core tool strategy avoids this flaw in restore strategy and offers other benefits, like the ability to author one type of tool and install it in different ways depending on project and user needs.
We look forward to your feedback on .NET Core Local Tools, and on challenges you face moving away from DotNetCliToolReference tools.
dotnet/sdk #3057