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:
Projectwill always start the current project (ignoring theexecutablePathsetting), and supports launching the browser and other options.Executablewill start the executable defined in theexecutablePathsetting, 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 thedotnetcommand 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.jsonitself: 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.jsonfile, 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