noahfalk
commented
5 years ago There is design doc we can edit here as needed: https://github.com/dotnet/diagnostics/blob/master/documentation/design-docs/dotnet-tools.md
During some discussion today a few issues emerged, but we need to do investigation to see how much we can decouple them:
1) What particular command line syntax do we have? 2) How many executables do we have? 3) How many distinct installation steps are necessary to get everything? 4) How readily can different command-line UI entrypoints share similar functionality in their implementation?
My current understanding is that a top-level verb in the dotnet syntax requires its own executable, for example dotnet foo requires a dotnet-foo executable to exist. I don't know (and Mike was looking into this) whether installations are required to be 1:1 with executables, or if we can pack multiple executables into a single package. If we can only have 1 executable per installer, that would mean for each 'dotnet foo' command the user has to do a corresponding 'dotnet tool install -g foo', and periodically 'dotnet tool update foo'. In terms of sharing functionality, I am not aware of any constraints that prevent us from factoring into libraries however we wish, and using the same libraries from multiple tools. This should mean that we can factor based on size-on-disk for a scenario and good layering without being too concerned about which particular UI commands expose it.
For deployment I'm expecting we've got a few cases: a) collection/export-only scenario that customers might want to have installed by default on every machine. Size on disk needs to be small. b) collect/export/monitor/analyze dev experience that customers would install on their dev machines, or on demand might install onto a production machine. Probably a strict super-set of what is included in the collection/export scenario and size on disk not a big deal as long as we don't go nuts c) Maybe not right away, but we should also keep in mind the scenario where a user hosts portions of the diagnostic functionality in-proc and might even ship it with his app into production. For example if we built a web service library that can visualize trace data from a separate monitoring process, a dotnet dev might want to take that same library and expose the web endpoint from within his own app to create a built-in admin monitoring portal.
mikem8361
KathleenDollard
rrelyea
jonsequitur
Update: dotnet-tools.md has the current design - feedback encouraged
For .Net Core 3.0 we are proposing some related diagnostic experiences that are at least partially on the command-line: 1) Collect and analyze a dump with a command line analysis tool #88 2) Collect perf counters and monitor them live #91 3) Collect a trace that can be analyzed with VS (or PerfView) for memory leaks #86 (CPU), #87 (memory) 4) Install and configure SOS for LLDB #108
In addition to these scenarios this is also a pre-existing dotnet symbol command to gather binaries/symbols/DAC prior to debugging, and in the future we can anticipate more potential command line diagnostic scenarios such as: 1) Capture and print threads/stacks to the console 2) Analyze trace data with a local command line tool 3) Monitor an app until certain trigger conditions are true, then collect dumps/traces/counters 4) Export counter/trace/dump data to an external telemetry aggregation system 5) Monitor an application and display all the results real-time via a tool that hosts a web endpoint + browser
The goal is to design the command-line interface for all the 3.0 scenarios now so that they are: 1) Easy to use 2) Consistent with each other and with pre-existing dotnet CLI conventions 3) Have a reasonable roadmap to add some of the probably future scenarios without feeling convoluted