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!
It would be nice if you add IIS Express support too.
@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.
Pingback: Dew Drop - November 9, 2018 (#2841) - Morning Dew
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
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.Managing configurations using puppet eliminates these kinds of issues
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.
Good catch! That seems unintended. I just opened a ticket for making editing environemnt variables possible: https://youtrack.jetbrains.com/issue/RIDER-24419
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.
Hi Max, I just created a feature request for this: https://youtrack.jetbrains.com/issue/RIDER-32154