Provide a way to launch the browser when running `dotnet run`

[danroth27]

It would be great if there was a way to run an ASP.NET Core app from the command line using dotnet run and have the default browser launch at the right URL. CLIs for other platforms let you do this. For example, with the Angular CLI you can do ng serve --open to both run the app and open the default browser.

This would be particularly useful for projects that you created using VS, which generate random ports for the server URLs.

There are already launchBrowser and launchUrl properties the launch profiles in launchSettings.json that let you specify that you want this behavior in VS.

We would also want this to work with dotnet watch without having the browser pop up multiple times, which may require some coordination.

@mlorbetske @natemcmaster @livarcocc @KathleenDollard

[livarcocc]

I imagine the idea here is to add the capability for dotnet run to understand this portion of the launchSettings.json?

Should it again be similar to what we have in VS? This was one of the reasons why when we talked about this I wanted VS to provide us with a shared library between the CLI and VS.

We started the conversation with supporting just a subset of what VS did and now we are adding more and more features to it regarding launchSettings.json.

Is it time to re-hash our conversation about having a shared library for launchSettings.json?

[natemcmaster]

Here is my idea for what we could add to dotnet-watch to make this work well: aspnet/DotNetTools#387 - would require dotnet-run to change launch behavior when started by dotnet-watch.

[reyou]

I also opened SO thread related to this issue
https://stackoverflow.com/questions/50284452/asp-net-core-launchsettings-json-does-not-launch-browser?noredirect=1

As a developer, my expectation for dotnet run --launch-profile dev to totally support & validate every single entry in launchSettings.json. I don't get the idea behind settings are partially supported between VS and CLI. IMO, they should have two separate configs, or different fields in same config.

[livarcocc]

Adding @vijayrkn and @mlorbetske who added the original support to launchsettings.json to the CLI.

launchsettings.json was originally added to the CLI because we needed it to support HTTPS and a couple other features of ASP.NET that would not work without it. There are many different details on launchsettings.json that will take a while to bring to parity. Besides, as it was originally developed to VS, there are things that don't directly translate to the command line experience that we need to discuss and find an alternative for.

[dasMulli]

The recently demonstrated HTTP CLI for Web APIs would add to that..

[dasMulli]

But until "full" launchSettings party, even something as "simple" as opening the URL would be cool - similar to what @natemcmaster's dotnet-serve does
https://github.com/natemcmaster/dotnet-serve/blob/dac796c44c1c4b7ef101763c60e4d7ddfc3cd2d6/src/dotnet-serve/SimpleServer.cs#L154-L175

[mlorbetske]

The current handling for launch settings ends before the app actually starts running. Spawning another process or thread to launch the browser once the port for the app opens (and terminating that thread or process in the event that the app fails to start) seems like it’d be the thing to do here.

[szalapski]

Definitely agree.

Another idea I had was to build a "callback" command line into "dotnet run" that could execute after the run has fully started. Such would remind me of CMD /C e.g:

dotnet run --after-init "start http://localhost"

To be clear, I called it after-init but maybe there's a better term for "run this after the initial steps are done and the executable is running." This would be more flexible than starting a browser directly.

[danroth27]

@KathleenDollard Many of the users that we tested the Blazor getting started experience with expected dotnet run to launch the browser automatically. This is a very common behavior for other web CLIs, like the Angular or Vue CLIs. When the browser didn't launch, multiple users thought the app hadn't run successfully even once console output was shown that the app server was listening for requests. Can we get this issue prioritized for .NET 5?

[dasMulli]

Do the Blazor templates create a launchUrl / launchBrowser in launchSettings.json? This could be used unless a user runs dotnet run --no-launch-profile.
I guess it would be good for templates to decide if they should render this property. WebAPI and grpc templates would then maybe not create this property, but MVC / RazorPages / Angular would.

[danroth27]

@dasMulli I believe pretty much all of the ASP.NET Core templates set launchBrowser: true in launchSettings.json, which is honored by VS but not on the CLI. Even for API projects it's often convenient to test the API using the browser, but you're right that this mechanism should allow projects to opt out of the browser launching behavior.

[dasMulli]

Quick prototype tells me that there is already logic that looks for aa launchUrl property in launchSetting.json but then doesn't do anything with it. launchBrowser isn't respected though.

Quick protoype wires it up: dasMulli/sdk@master...dasMulli:prototype/dotnet-run-open-browser

@danroth27 looks like the templates do set applicationUrl to multiple ;-separated URLs but the current logic looks for a launchUrl property (but then does nothing with it).
Do we know what the VS project system behaviour is here?

ToDos / Thoughts for continuing on that prototype:

• Wire up and respect launchBrowser bool flag
• Bundle and uee a built copy of xdg-open from https://github.com/freedesktop/xdg-utils (MIT License) for linux launches.
• Discuss alternatives for INotifyingCommand - current command infrastructure is built on synchronous executions, not start/wait or lifecycle hooks.