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.

[dasMulli]

I'd be happy to work on this, though i'd need some definitive input on the canonical understanding of launchSettings.json with applicationUrl (multiple semicolon-separated URls, translated to aspnetcore env var) vs launchUrl in relation to launchBrowser.

[akoeplinger]

Bundle and uee a built copy of xdg-open from freedesktop/xdg-utils (MIT License) for linux launches.

xdg-open is usually preinstalled e.g. on Ubuntu, you don't need to bundle it.

[kapsiR]

Would be cool to see such feature, but I'd prefer a richer functionality:

• Support for starting multiple browsers or a specific browser, not just the default
• Support for switches (e.g. -private-window in Firefox or --incognito in Chrome)

[dasMulli]

I guess additional options could go into launchSettings.json in some form as well to be less breaking. dotnet run shouldn't eat too many CLI parameters as the rest is passed to the application.

[dasMulli]

xdg-open is usually preinstalled e.g. on Ubuntu, you don't need to bundle it.

Been browsing around a bit and only found references that it is "mostly" okay but one could bundle it. the open npm package (https://github.com/sindresorhus/open) bundles it for example.

[DamianEdwards]

@pranavkm didn't we do this in 5.0.0?

[maxild]

I have to support #9038 (comment)

Working with Blazor WASM on Linux (where firefox often is the default browser for good reasons: xdg-open will use firefox`) is not easy out of the box, when Chrome is the only supported dev browser (on Linux).

My current solution is to use 2 terminals

Terminal 1

$ dotnet run --no-launch-profile 

Terminal 2

$ google-chrome http://localhost:5000

One strange thing is that I can't seem to get this to work with dotnet watch. That is

Terminal 1

$ dotnet watch run --no-launch-profile 

does use the default launchSettings.json (launchBrowser, inspectUri, applicationUrl etc) config values for the app,
I have no idea why the child dotnet run is not getting the --no-launch-profile switch??? May be my mistake???

REQUEST:

Add new browsers field with possible values firefox, chrome, edge etc. to launchSettings.json

"profiles": {
    "BlazorWasmApp": {
      "commandName": "Project",
      "dotnetRunMessages": "true",
      "launchBrowser": true,
      "browsers": ["chrome"], <---- REQEUST: Please add this feature
      "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}",
      "applicationUrl": "http://localhost:5000",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }

NOTE: Each opened browser should probably also have config values for extra args. I guess this all starts to be a bit platform dependent, but a design should be possible accross windows, macos and the dotnet supported linux distros.

[logcorner]

+1

[janaagaard75]

It seems that this been fixed in version 6.0.201. Can anybody else confirm?

Update: We use dotnet watch run in our run scripts.

[dasMulli]

It should work in dotnet watch for recent versions, the comments in the corresponding code mentions it might not work well on linux though

[boldt]

@janaagaard75 I am on 6.0.201 and the browser is not opening on dotnet run
@dasMulli I can confirm that dotnet watch run opens the browser with the launchUrl

[BluMichele]

Use compounds launch settings in VS Code

"configurations": [
    {
        "name": ".NET Core Launch (console)",
        "type": "coreclr",
        "request": "launch",
        "preLaunchTask": "build",
        "program": "${workspaceFolder}/src/WebApi/bin/Debug/net7.0/YourWebDll.dll",
        "args": [],
        "cwd": "${workspaceFolder}",
        "stopAtEntry": false,
        "console": "internalConsole"
    },
    {
        "name": "Launch Chrome",
        "request": "launch",
        "type": "chrome",
        "url": "https://localhost:5001/swagger/index.html",
        "webRoot": "${workspaceFolder}"
    }
],
"compounds": [
    {
        "name": ".Net Core & Chrome",
        "configurations": [".NET Core Launch (console)","Launch Chrome"]
    }
]

This will run the app and launch chrome at the URL you want.

[nul800sebastiaan]

dotnet watch works fine, but why does it not output any of the helpful colors like when running dotnet run?

[UsmanFarooq-Dev]

This feature is still not added even in .NET 7 :(

[baronfel]

It would be great to add this - the mechanism clearly exists in 'watch' already, we should look at what it would take to reuse it.

I've added the help wanted label to signify that we'd gladly take contributions here - we'd want to keep the behaviors the same between watch and run commands, but if someone took a pass at it the team would love to help get it over the finish line.

[macoslinux]

I use net 6.0

Works for me this way

note in launch.json "uriFormat": "%s/swagger/index.html"

## launch.json
{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": ".NET Core Launch (web)",
            "type": "coreclr",
            "request": "launch",
            "preLaunchTask": "build",
            "program": "${workspaceFolder}/bin/Debug/net6.0/QATesting.dll",
            "args": [],
            "cwd": "${workspaceFolder}",
            "stopAtEntry": false,
            "serverReadyAction": {
                "action": "openExternally",
                "pattern": "\\bNow listening on:\\s+(https?://\\S+)",
                "uriFormat": "%s/swagger/index.html"
            },
            "env": {
                "ASPNETCORE_ENVIRONMENT": "Development"
            },
            "sourceFileMap": {
                "/Views": "${workspaceFolder}/Views"
            }
        },
        {
            "name": ".NET Core Attach",
            "type": "chrome",
            "request": "attach",
            "url": "https://localhost:7006/swagger/index.html"
        }
    ]
}

## launchSetting.json
{
  "$schema": "https://json.schemastore.org/launchsettings.json",
  "iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true,
    "iisExpress": {
      "applicationUrl": "http://localhost:63711",
      "sslPort": 44356
    }
  },
  "profiles": {
    "QATesting": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "browsers": "chrome",
      "launchUrl": "swagger",
      "applicationUrl": "https://localhost:7006;http://localhost:5007",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "launchUrl": "swagger",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }
}

in vscode or linux console
dotnet watch

and launch the bowser on swagger page.

[tmat]

Related issue: dotnet/aspire#3812

@davidfowl Please provide details about how the auth works so that it can be incorporated into dotnet run browser launch design.