Add design for dotnetclitool v3#370
Open
richlander wants to merge 2 commits into
Open
Conversation
jkotas
reviewed
Jun 18, 2026
| - Rename the file as `manifest.json`. | ||
| - Store the manifest at the top of the tools directory, at `tools/manifest.json`. | ||
|
|
||
| Note: There is a desire to make it easier to write standalone tools to install .NET tools packages. It has always been unfortunate that tools installation required the SDK. With BYOR tools, that situation becomes untenable. A recent effort with [dotnet-install](https://github.com/richlander/dotnet-install) went down just this path. Tools like that are part of the reason to move to JSON. Many tools already have a System.Text.Json dependency and JSON serialization works with NAOT while XML serialization doesn't. |
Member
There was a problem hiding this comment.
This is a weak argument. Reading Xml with a simple schema it - like the one used for package - is trivial to handroll in fully AOT compatible way, without any Xml serializer.
xml vs. json is a cosmetic implementation detail. It should not be part of the leading design point. It should be in remarks towards at the end.
Member
Author
There was a problem hiding this comment.
You are right. JSON vs XML is not a strong argument. My main point about format is that tools are more likely to have a JSON dependency already, however, that is speculative. The key point is that it will be easier to right standalone tools because the format is simpler.
I'll clean it up.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a draft design for dotnetclitool v3, a successor to #333.
The basic challenge is that v2 is based on a runtime-dependency model. v2 is a major step forward, however, it is an evolution of v1. That's why the runtime-dependency is so strong. The intent of this proposal to start with NAOT (and self-contained friends) as the primary form factor and then make runtime-dependence the fallback. It also comes with the realization that v2 is very similar to what the container community did with the manifest list format. It does not however do what the community did with the OCI format to make it a simple format that welcoming to multiple readers and writers. v3 offer analogous improvements.
Containers are basically manifests and
.tar.gzfiles. NuGet packages are manifests and zip-compressed.nupkgfiles. Very similar. This design takes advantage of NuGet where it provides value and removes it where it doesn't. There is an element of similarity to that process to the OCI one as well.Design for: