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:
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.
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.
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.
From the gutter, we can also run or debug a launch profile.
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 theexecutablePath
setting), and supports launching the browser and other options.Executable
will start the executable defined in theexecutablePath
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 thedotnet
command line tool handles environment variables inlaunchSettings.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!
Saeid says:
November 8, 2018It would be nice if you add IIS Express support too.
Alexander Kurakin says:
November 9, 2018@Saeid, feel free to follow https://youtrack.jetbrains.com/issue/RIDER-11638 request, we are working on it. However, it will happen in 2019.1 release cycle.
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) […]
Dan says:
January 16, 2019I 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, 2019Nothing 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, 2019Managing configurations using puppet eliminates these kinds of issues
Robert K. Bell says:
February 11, 2019I’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.
Maarten Balliauw says:
February 12, 2019Good catch! That seems unintended. I just opened a ticket for making editing environemnt variables possible: https://youtrack.jetbrains.com/issue/RIDER-24419
Max Pavlov says:
August 27, 2019Are 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.
Maarten Balliauw says:
August 27, 2019Hi Max, I just created a feature request for this: https://youtrack.jetbrains.com/issue/RIDER-32154
Demis says:
May 6, 2020How 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:
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, 2020Hi 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: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!