Don't create tool manifests in a .config subfolder by default

[Copilot]

This change removes the automatic creation of .config subdirectories when creating new tool manifests. Previously, when using dotnet tool install --create-manifest-if-needed or similar commands, the CLI would create manifests at .config/dotnet-tools.json. Now, manifests are created directly as dotnet-tools.json in the target directory.

Changes Made

• ToolManifestFinder.cs: Updated WriteManifestFile() method to create manifests directly in the target folder instead of in a .config subdirectory
• Template: Moved the tool manifest template from .config/dotnet-tools.json to dotnet-tools.json
• Tests: Updated test expectations to reflect the new creation behavior while maintaining backward compatibility validation
• Integration tests: Updated approval test expectations

Backward Compatibility

The change maintains full backward compatibility for reading existing manifests:

• Existing .config/dotnet-tools.json files continue to be discovered and used
• The search order still checks both .config/dotnet-tools.json and dotnet-tools.json locations
• Only the creation logic has changed, not the discovery logic

This simplifies the local tools experience by reducing directory clutter while preserving support for existing projects.

Fixes #49296.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[dsplaisted]

@copilot What about the tests for the consumption of the tools manifest file? Do they use the .config subfolder or not? Probably most of them should be changed to not use the .config folder, but we should still have some coverage of the .config folder to ensure backwards compatibility.

[Copilot]

@copilot What about the tests for the consumption of the tools manifest file? Do they use the .config subfolder or not? Probably most of them should be changed to not use the .config folder, but we ...

I've analyzed the test coverage and made the necessary updates. Most consumption tests already use the direct path format (not .config), which is good. The main issues were:

1. TemplateDiscoveryTool.cs was still looking for .config\dotnet-tools.json but dotnet new tool-manifest now creates dotnet-tools.json directly - fixed this
2. Added backward compatibility test in ToolInstallLocalCommandTests to ensure tools can still be installed into existing .config manifests

Current test coverage:

• ✅ Backward compatibility: ToolManifestFinderTests has specific tests for .config discovery + new install test
• ✅ New behavior: Most consumption tests (Install/Update/Run/Restore) already use direct paths
• ✅ Integration: Fixed template discovery test to match new creation behavior

The distribution is now appropriate - most tests use the new direct format while maintaining coverage for .config backward compatibility.

Commit: 5c42f9d

[dsplaisted]

@copilot This test looks good, but can you add additional checks to it to verify that the manifest under the .config folder has been updated, and that no manifest exists in the root folder after the install command is run?

[Copilot]

Added the requested checks to the test. The enhanced test now verifies:

1. ✅ The manifest under the .config folder has been updated (checks file exists, contains the tool, and content differs from original)
2. ✅ No manifest exists in the root folder after the install command runs

All ToolInstallLocalCommandTests continue to pass, ensuring backward compatibility is maintained.

Commit: 9099124

[Copilot]

Pull Request Overview

This PR changes the default behavior for creating new tool manifests to avoid automatically creating .config subdirectories. Previously, dotnet tool install --create-manifest-if-needed would create manifests at .config/dotnet-tools.json, but now they are created directly as dotnet-tools.json in the target directory.

• Simplified manifest creation by removing automatic .config directory creation
• Updated tests to reflect new creation behavior while maintaining backward compatibility
• Preserved discovery logic to support existing .config/dotnet-tools.json files

Reviewed Changes

Copilot reviewed 4 out of 6 changed files in this pull request and generated no comments.

File	Description
src/Cli/dotnet/ToolManifest/ToolManifestFinder.cs	Updated WriteManifestFile() to create manifests directly in target folder
test/dotnet.Tests/ToolManifestTests/ToolManifestFinderTests.cs	Added test to verify new manifests are created without .config directory
test/dotnet.Tests/CommandTests/Tool/Install/ToolInstallLocalCommandTests.cs	Updated test expectations and added backward compatibility test
test/dotnet-new.IntegrationTests/TemplateDiscoveryTool.cs	Updated test to expect manifest in root directory

---

_{You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.}