search

dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.73k stars 1.07k forks source link

[Epic] Various quality of life issues when running a hackathon experiment #43526

Open JonDouglas opened 2 months ago

JonDouglas commented 2 months ago

I recently did a hackathon effort over the weekend in which I tested the latest LLM tech with dotnet. Here are a handful of issues that I believe are important to help people adopt these tools more easily and are generally known in the community.

I did this experiment with .NET 8, macOS Sequoia 15.0, and a can of diet coke handy.

From a fresh install after nuking everything, here is what was suggested just to get dotnet to run in various contexts throughout this experiment:

export PATH=$PATH:/usr/local/share/dotnet
export DOTNET_ROOT="/usr/local/share/dotnet"
export PATH=$PATH:$DOTNET_ROOT
export PATH="$PATH:/Users/jondouglas/.dotnet/tools"
export PATH="$PATH:/usr/local/share/dotnet/x64"

My expectation would be to only have to add one single path which all of these infer from. I had to do 5 different ones just to get a typical ASP.NET Core, EF, Tools, etc setup. I'm on a ARM machine and have no idea why x64 is here either, but I needed it to get SOMETHING to work.

Wanting to adopt CPM from the beginning led to a major challenge where I cannot add a dotnet test template nor "fix" it to be able to work with CPM due to implicit pkg references coming from the SDK (I believe).

My expectation is that I could easily on-board ANY .NET SDK template to CPM as a best practice.

While the default is mixed in various ecosystems, my expectation of dotnet run was to visually see something. I think there might be potential to give both defaults with two different verbs. dotnet serve or dotnet dev seem like good opportunities to provide a "user-friendly" mode. Other potential opportunities to these verbs might be default hot reload/watch and debugging capabilities.

My expectation is to have a single CLI command that enables the inner-development loop by launching a browser that I will stay in while I am constantly manipulating files and wanting to see these changes show up on save.

While pulling down various repositories to mimic behavior from, I'd often be stuck unable to compile nor run their code because they included a global.json with a specific version in it.

When I remove this file, their projects happily compiled with my .NET 8 SDK anyway as I was unwilling to go download .NET 6 or something else.

I propose that .NET SDK has a better management experience of these "environments". A good concept in python land is the concept of virtual environments. A new command like dotnet environment could use a .dotnet-version (akin to global.json) which can infer the .NET SDK/Runtime requested by the project and ensure compatibility with the global environment. If there is no compatibility, a "virtual environment" can be created in which some helpful CLI management commands like dotnet environment install 6.0.XXX may install the required tooling in the background and a user can set their global environment via dotnet environment global 8.0.XXX or similar

My expectation was that the latest stable version of .NET SDK/Runtime would allow me to run virtually any project, and that is true if I remove global.json

Not many of the CLI commands support great "piping" nor empowered error messages that help you resolve the issue at hand. An extremely helpful tool in these cases is machine-readable output which isn't always there for various commands.

My expectation is that just about every command could be utilized with piping and provide helpful output that a LLM can take in to resolve a future problem.

This may be a controversial one, but having used these tools for about a decade, I've been unsure why Entity Framework commands could not be integrated into the dotnet CLI formally? Having to download separate tools to use the premiere ORM is a strange experience. Just about every command could be folded into dotnet SDK and put behind some type of reference conditional to work? dotnet migrations add, dotnet database update, etc. To ensure this isn't a standardization/favortism thing, a flexible model for tools that would like to extend this pattern might make sense.

My expectation is that I can use common database commands directly in dotnet without having to install separate tools and follow additional steps/tutorials just to get those to work out of the box.

...More to come, these are fresh!

(I do not expect any answers or explanations, just logging these things down as I encounter them)

akoeplinger commented 2 months ago

From a fresh install after nuking everything, here is what was suggested just to get dotnet to run in various contexts throughout this experiment:

you shouldn't need this at all, the installer already puts dotnet in the PATH (after restarting your shell). where did you get the installer from?

JonDouglas commented 2 months ago

https://dotnet.microsoft.com/en-us/download/dotnet/8.0

ARM64 installer.

I almost always have to do the following to get a PATH to append:

i.e. nano ~/.zshrc or nano ~/.bash_profile -> export PATH="$PATH:/usr/local/share/dotnet" -> source ~/.zshrc or source ~/.bash_profile

Here's a quick search on the same issue, it suggests to me others run into this regularly too. I don't even have a terminal open when installing in most cases.

i.e. https://stackoverflow.com/questions/53030531/dotnet-command-not-found-in-mac

https://www.reddit.com/r/dotnet/comments/101103m/i_cant_figure_out_how_to_get_dotnet_running_on_my/

https://developercommunity.visualstudio.com/t/macos-dotnet-cli-path-for-global-tools-is-bad/1574652

My expectation is to use an installer of some sort(official website, brew, etc) and be able to use dotnet after a terminal restart/refresh if it is even open. I am unsure why I have to manually intervene here.

Aside the default installer experience, when using dotnet tools and other CLI commands, I had to add all these additional paths when it feels like I shouldn't have to do that as a user. It really interrupts the flow.

akoeplinger commented 2 months ago

The installer drops a file in /etc/paths.d/dotnet that adds /usr/local/share/dotnet to PATH for the dotnet CLI so that shouldn't be necessary.

It looks like there is indeed an issue for /etc/paths.d/dotnet-cli-tools to add the tools directory to PATH in zsh: https://github.com/dotnet/sdk/issues/23165

DamianEdwards commented 1 month ago

dotnet run doesn't open a localhost browser by default. While the default is mixed in various ecosystems, my expectation of dotnet run was to visually see something. I think there might be potential to give both defaults with two different verbs. dotnet serve or dotnet dev seem like good opportunities to provide a "user-friendly" mode. Other potential opportunities to these verbs might be default hot reload/watch and debugging capabilities.

My expectation is to have a single CLI command that enables the inner-development loop by launching a browser that I will stay in while I am constantly manipulating files and wanting to see these changes show up on save.

dotnet watch is this command today. Aliasing something like dotnet dev to it might be an improvement, but I'm not sure it's anymore discoverable.

JonDouglas commented 1 month ago

dotnet run doesn't open a localhost browser by default. While the default is mixed in various ecosystems, my expectation of dotnet run was to visually see something. I think there might be potential to give both defaults with two different verbs. dotnet serve or dotnet dev seem like good opportunities to provide a "user-friendly" mode. Other potential opportunities to these verbs might be default hot reload/watch and debugging capabilities.

My expectation is to have a single CLI command that enables the inner-development loop by launching a browser that I will stay in while I am constantly manipulating files and wanting to see these changes show up on save.

dotnet watch is this command today. Aliasing something like dotnet dev to it might be an improvement, but I'm not sure it's anymore discoverable.

instead of dotnet watch run, could we alias that to something with a single verb i.e. dev/etc?

fwiw the LLM did not suggest anything around watch, just dotnet run and would constantly hallucinate that it opens up a browser window until having to need to intervene and add a launch profile.

DamianEdwards commented 1 month ago

instead of dotnet watch run, could we alias that to something with a single verb i.e. dev/etc?

Today, dotnet watch run implies dotnet watch. It is the inner-loop command you're suggesting. We could certainly alias it to dotnet dev but I'm not sure that's any more discoverable. Perhaps it needs more prominent placement in our docs and dotnet CLI help.