Environment variables in commandLineArgs

[ghogen]

The behavior of commandLineArgs is inconsistent vs other launch profiles. Eg I can pass an environment variable in the commandLineArgs, like

"profiles": { "arius archive": { "commandName": "Project", "commandLineArgs": "archive -k %ACCOUNT_KEY%" } } However with Docker this yields a different result, in effect "literally" passing %ACCOUNT_KEY% and not its value. I tried getting the environment variable in the container so that echo $ACCOUNT_KEY yields the value, but it doesn't work. Is there a way to "inject" this value?

This doesn't work:

{ "profiles": { "Docker arius archive": { "commandName": "Docker", "commandLineArgs": "arius.dll archive -k %ACCOUNT_KEY%" } } } This doesn't work either:

{ "profiles": { "Docker arius archive": { "commandName": "Docker", "commandLineArgs": "arius.dll archive -k $ACCOUNT_KEY" } } } Originally entered by @woutervanranst as https://github.com/MicrosoftDocs/visualstudio-docs/issues/6146

[fame]

I ran in to the same problem with VS 2022. Please provide a solution asap.

[JohnTheGray]

I ran into the same problem. It seems that VS should substitute the environment variables, e.g. $(pwd), but it does not work in launchSettings.

Does not work (launchSettings.json): "DockerfileRunArguments": "-v $(pwd)/host-folder:/container-folder:ro" Ref https://docs.microsoft.com/en-us/visualstudio/containers/container-launch-settings?view=vs-2019

Does work (.csproj): <DockerfileRunArguments>-v $(pwd)/host-folder:/container-folder:ro</DockerfileRunArguments> Ref https://docs.microsoft.com/en-us/visualstudio/containers/container-msbuild-properties?view=vs-2019

[nickdm26]

I Ran into the same problem with VS 2022. I assume $(Get-Location | Split-Path | Split-Path) should work in place of $(pwd) to traverse up 2 directory's.

[NCarlsonMSFT]

There is a flaw in the documentation. No tokens or expressions are supported in the launch settings as they exist today. If you need support for that you need to use the equivalent msbuild property. We are considering adding support for expanding windows environment variables in the arguments, but that has not been implemented yet.