Using .NET Core launchSettings.json to run/debug apps in Rider

A .NET Core application can have a file called launchSettings.json, which describes how a project can be launched. It describes the command to run, whether the browser should be opened, which environment variables should be set, and so on. This information can then be used by dotnet to run or debug our application.

The latest Rider 2018.3 Early Access Preview (EAP) build adds support for generating Rider run/debug configurations from launchSettings.json. This makes the launch profile portable between the command-line dotnet tools and Rider. Let’s see how this works!

Generating Rider run configurations based on launchSettings.json

When first opening a project that contains one or more launchSettings.json files, Rider will auto-import the launch profiles defined in it and create run/debug configurations for them.

For example, after cloning and opening the Orchard CMS, we will see the following run configurations in Rider – all originating from the launchSettings.json files:

Run configurations generated on project load

Rider only generates run/debug configurations automatically when no user-defined run configurations were created before. If that’s the case, we can use the Generate Configurations context menu on a launchSettings.json file to import the launch profile(s) into Rider. Using the Run project context menu will also pick up these settings.

Run from launchSettings.json

Tip: when removing all existing run configurations in Rider and re-opening the project, launchSettings.json files will be imported again as run configurations.

Editing a generated run configuration

Run/debug configurations that are generated from a launchSettings.json file can be edited. Via the toolbar or the Run | Edit Configurations… menu, we can look at the imported configuration and make some changes to it when needed.

Editing a run configuration generated from launchSettings.json

Some options are editable, for example the target framework to use, as well as .NET runtime arguments, while options that come from launchSettings.json are read-only here.

Editing launchSettings.json

Rider comes with editor support for launchSettings.json files as well. There is syntax highlighting and code analysis, and code completion, too.

Code completion for launchSettings.json

From the gutter, we can also run or debug a launch profile.

Run from editor - gutter actions

Supported commands and options

Launch profiles in a launchSettings.json support a number of configuration options. For example, there is the command that will be executed when running it. Right now, Rider supports the Project and Executable commands:

  • Project will always start the current project (ignoring the executablePath setting), and supports launching the browser and other options.
  • Executable will start the executable defined in the executablePath setting, but does not support browser options.
  • The IISExpress command is not supported in Rider yet.

We can make use of environment variables, as well as MSBuild variables in many parameters (executablePath, workingDirectory, environmentVariables, applicationUrl and launchUrl).

  • To inject an environment variable, we can use the percent syntax, e.g. %TEMP%. This syntax should also be used on Mac OS X and Linux, which corresponds to how the dotnet command line tool handles environment variables in launchSettings.json.
  • For MSBuild variables, we can use the $(variable) syntax, e.g. $(ProjectDir).

In our launchSettings.json file, we can also define whether the browser should be started or not. The launchUrl setting will be opened in the browser when enabled.

The applicationUrl setting is added to the ASPNETCORE_URLS environment variable so that an ASP.NET Core app can bind to that URL. To disable this behavior, a setting "externalUrlConfiguration": true can be added to the launch profile.

Executable paths defined in launchSettings.json will be resolved in two ways: relative to the working directory, and using the system PATH environment variable.

Download Rider 2018.3 EAP and give it a try! We would love to hear your feedback on these updates!

About Maarten Balliauw

Maarten Balliauw is a Developer Advocate at JetBrains, working on .NET tools. He focuses on .NET, Azure, web technologies and application performance. Maarten is a frequent speaker at various national and international events. In his free time, he brews his own beer. Follow him on Twitter or check out his personal blog.
This entry was posted in How-To's and tagged , , , . Bookmark the permalink.

10 Responses to Using .NET Core launchSettings.json to run/debug apps in Rider

  1. Saeid says:

    It would be nice if you add IIS Express support too.

  2. Pingback: Dew Drop - November 9, 2018 (#2841) - Morning Dew

  3. Dan says:

    I find the existence of environment variables inside of the launchSettings.json to be rather silly. Typically we don’t want to update our source code and push to support a new destination environment.

    Think of this use case, I develop an app that needs to be deployed in kubernetes. The discovery location for my database is totally different than something I’d access locally or for integration tests. The fqdn’s differ significantly.

    This seems to be an anti-pattern to me! Having a location that registers environment variables sounds great, but placing those values into a file sort of negates the whole environment variable thing.

    Rider should allow me to place my own environment variables into a run/debug configuration just like webstorm/rubymine… Why is this so different? How can I override this behaviour?

    Thanks

  4. Robert K. Bell says:

    I’m in agreement with Dan; it’s suprising in a bad way that I can appear to add environment variables to the run config (with Alt+Insert), there’s no error on save, but they were just discarded.

  5. Max Pavlov says:

    Are there plans to support “commandName”: “Docker”? As it seems like you are basically ready to do a lauchSettings.json to run/debug Configuration conversion as the run/debug part is ready to service the functionality, it’s just the logic that generates run/debug configurations doesn’t work with Docker command yet.

Leave a Reply to Maarten Balliauw Cancel reply

Your email address will not be published. Required fields are marked *