Support .env files

[tmeschter]

Summary

Update the handling of Launch Profiles to support supplementing or overriding the environment variables specified in a launch profile with those in a .env file.

We generally expect launchSettings.json files, when present, to be checked in to source control. This make them unsuitable for storing private information, such as access tokens, usernames, passwords, etc., that may be needed during the development process. In the VS Code ecosystem this need is met through .env files which specify environment variable names and values. OmniSharp, for example, will automatically read this file and update the environment of the application on launch.

We should consider supporting .env files as well.

Open Questions

• Do we really need this, or is the need already being met by some other tooling?
• Do we require the path to the .env file be specified, or do we support a default location (e.g. next to the solution file)?
• If we allow specifying the .env file, should that be on a per-profile basis, or in a global setting in the launchSettings.json?

See Also

• Definition in the launch.json schema
• .env file processing in omnisharp-vscode
• #8189 (Note the request there is broader than what is covered by this issue.)

[tmeschter]

FYI @kvenkatrajan, this is another one to consider for future planning.

[DanielHabenicht]

nice to find an issue about this here to. I filed an issue here from the current perspective of the secrets management. But also came to the conclusion that supporting it in launchSettings.json might be the best way forward.

Do we require the path to the .env file be specified, or do we support a default location (e.g. next to the solution file)?

I would like a customizable solution like docker has:

{
 "profiles": {
   "EnvironmentsSample": {
     "commandName": "Project",
     "dotnetRunMessages": true,
     "launchBrowser": true,
     "applicationUrl": "https://localhost:7152;http://localhost:5105",
     "environmentVariables": {
       "ASPNETCORE_ENVIRONMENT": "Development"
     },
    // Add another Option for reading .env Files
    "environmentFiles": [".env", "development.env"]
   },
}

And maybe a default support for .env files in the project root directory (for dotnet commands issued with a --configuration=Development)

[aayani]

Now this is a real good issue from my perspective. Is there a timeline around it? It would be really awesome to be able to use a relative or absolute path to the .env file in the launchSettings.json.

[tmeschter]

There are some open design questions.

1. Do we support multiple .env files as in @DanielHabenicht's example?
2. Support for both absolute and relative paths seems desirable. For relative paths: relative to what? The launchSettings.json file, or the project file? There would be some opportunity to use MSBuild properties to dynamically vary the path, like $(Configuration)/.env to pick a .env file tied to the configuration, or (maybe) $(SolutionFolder)/.env to pick a .env file next to the .sln file. But we should still have a reasonable default for just .env by itself.
3. How would we handle missing .env files? That is, do we just ignore them, block the build/run with an error message, or something else?
4. When multiple .env files are specified, or a .env file and environmentVariable, how do they compose? I lean toward:

• .env files later in the list override matching entries from earlier in the list
• environmentVariables overrides all .env files, since the launch profile is "more specific"

Design aside, there are also the usual issues with properly handling automatic file save on launch. We don't handle it properly for launchSettings.json right now (meaning changes might not be saved and applied correctly on F5/Ctrl+F5), but we should fix that problem and certainly not repeat it for .env files. :-D

[stefan-schweiger]

4. When multiple .env files are specified, or a .env file and environmentVariable, how do they compose? I lean toward:

• .env files later in the list override matching entries from earlier in the list

• environmentVariables overrides all .env files, since the launch profile is "more specific"

Just my two cents on this, dotenv for example does not override envvars already set and the order of the files is the order in which envvars get set.

This allows you to always override the configuration of a command/script/program from the outside with existing envvars. Also for most build tools that support .env files the order usually is (without overriding)

1. envvars
2. .env.(configuration).local
3. .env.(configuration)
4. .env.local
5. .env

Not sure if some automatic configuration detection is needed if you can just specify the order of .env files yourself in launchSettings.json.

But for being able to use .local files I don't think the build should fail if some files are not found. So you can just specify the order as [".env.my-config.local", ".env.my-config", ".env.local", ".env"].

Of course you could also define it in such a way that .local files are automatically detected but not specified.

[Bjego]

I would love this feature - thank you @tmeschter for linking the problems around dotenv files when working with containers and also the pain of manual copying and pasting from my VS Code DotnetTools issue!

It's a real productivity issue to not have the opportunity to reuse a .env file from running a docker image in my launchsettings (in VS and VSCode).

See all the manual steps in my awnser here: https://github.com/microsoft/vscode-dotnettools/issues/584#issuecomment-1784617264

[cyraid]

Another question would be asked, would the configuration be able to expand variables inside the .env files?

[darrelmiller]

I want to second @aaronpowell 's comment here https://github.com/microsoft/vscode-dotnettools/issues/584#issuecomment-1758878704 about feature being important for supporting the use of AZD. I just spent hours trying to figure out how to make C# dev kit work well with azd environments. Going back to using coreclr has been the only thing I have found that works so far.