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

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

Maarten Balliauw

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!

#.NET Core #ASP.NET #msbuild #Rider
Comments below can no longer be edited.

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

  1. Saeid says:

    November 8, 2018

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

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

    November 9, 2018

    […] Using .NET Core launchSettings.json to run/debug apps in Rider (Maarten Balliauw) […]

  3. Dan says:

    January 16, 2019

    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

    • Maarten Balliauw says:

      February 12, 2019

      Nothing we can do about launchSettings.json itself: it’s a schema defined in .NET (https://github.com/SchemaStore/schemastore/blob/master/src/schemas/json/launchsettings.json) and supports environment variables.

      However, nothing prevents you from not setting them in the launchSettings.json file, or overriding them when deploying to Kubernetes.

      As for placing your own environment variables in the run configuration: this is currently not supported with a launchSettings.json-based Run configuration. I created an issue for this at https://youtrack.jetbrains.com/issue/RIDER-24419 As a workaround, you could create a regular .NET run configuration where these settings can be edited.

    • Matty Mead says:

      March 5, 2019

      Managing configurations using puppet eliminates these kinds of issues

  4. Robert K. Bell says:

    February 11, 2019

    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:

    August 27, 2019

    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.

  6. Demis says:

    May 6, 2020

    How can I run a dotnet tool? They’re installed at %USERPROFILE%\.dotnet\tools on Windows and $HOME/.dotnet/tools on macOS/Linux.
    https://docs.microsoft.com/en-us/dotnet/core/tools/global-tools#install-a-global-tool

    This post suggests I should use the windows %TEMP% syntax, but this doesn’t work (UI says Invalid exe path):

    %USERPROFILE%\.dotnet\tools\tool.exe

    Neither does VS Code’s: "${env:USERPROFILE}\.dotnet\tools\tool.exe"
    https://code.visualstudio.com/docs/editor/variables-reference#_environment-variables

    I’ve also tried various other syntaxes I’ve seen used, including:

    ${env.USERPROFILE}
$(USERPROFILE)
${USERPROFILE}
{USERPROFILE}

    But nothing works, ideally I’d like to use a standard variable I can use that works in Windows/macOS/Linux (e.g. %HOME%), but I’d settle for OS specific environment variable.

    • Maarten Balliauw says:

      May 6, 2020

      Hi Demis,

      The easy response would be to use them from the command-line in the Terminal tool window.

      I’m assuming you want to be able to quickly run an tools-based command as a run configuration, which would be the less-easy-but-still-doable option. And even there, there are options 🙂

      Option 1 – Adding the tool to your launchSettings.json

      Just gave this a try, and (on Windows), the following works when added to the launchSettings.json file:

      {
  "profiles": {
    // ...
    "EF Core Tools": {
      "commandName": "Executable",
      "executablePath": "%USERPROFILE%/.dotnet/tools/dotnet-ef.exe"
    }
  }
}

      Option 2 – Make it a Rider run configuration

      Making it a Rider run configuration is probably easier to configure. From the Run | Edit configurations… menu, add a new .NET Executable. In the Exe path, specify the path to the tool. This will have to be the full path (no environment variable).

      Option 3 – Configure it as a tool

      Run configurations/launch settings ideally are for running project-related artifacts. Most run configurations provide debugging support and al that, which is probably overkill for an external tool.

      The “Rider way” of adding tools is in the settings/preferences, under Tools | External Tools. Here, you can register the external tool with a name, arguments, and several options on whether you want to see console output or not. More details in our web help, and an example use case here: XamlStyler as an external tool.

      External tools have the nice added benefit that they are actions, and can be added to a menu, quick list, and can even get a keyboard shortcut assigned.

      Hope this helps!

.NET Tools Guide

Latest Tweets

Related posts

Webinar – OOPs, I did it again

Join us Thursday, February 11, 2021, 16:00 - 17:00 CET (10:00 AM - 11:00 AM EST or check other timezones) for our free live webinar, OOPs, I did it again, with João Antunes. Register now and get a reminder, or join on YouTube Object oriented programming is one of the most broadly used programming paradigms. The problem, however, is that most of the time, even if we use a primarily object oriented programming language, we forget to take advantage of everything it can do, resulting in a mostly procedural scenario. In this session, João Antunes will share some ideas about how to improve our code
by Maarten Balliauw

Xamarin, the best way to make NFC Apps – Webinar recording

The recording of our webinar, Xamarin, the best way to make NFC Apps, with Saamer Mansoor, is now available. Subscribe to our community newsletter to receive notifications about future webinars. Learn about NFC technology, potential invention ideas, the NFC capabilities & differences between iPhone & Android apps, and why Xamarin is the best way to make cross-platform NFC Apps. Also, learn about ways to implement security and limitations. (more…)
by Maarten Balliauw
Subscribe

Subscribe to .NET Tools updates