If you are passing the data via configuration files(or parameters) at deployment and accessing it via code using Context.CodePackageActivationContext.GetConfigurationPackageObject("Config")
, the right way should be using <Parameter Name="StorageConnectionString" Value="[ENVVARIABLE]" />
(note that it is encolsed by [ ]) and have a configuration file with a variable called ENVVARIABLE
and set the overrides to your service. You should not need to set environment variables, environment variables is other thing.
Please take a look at this SO question to check if will solve the problem.
If your plan is getting an environment variable already set in the machine, unfortunately SF does not support Environment Variable Replacement using tokens like %ENVVARIABLE%
.
even though running SET on cmd prompt did show that variable exists.
The other process that changes the environment variable, if it just use the default set, it will set their own process environment variables, to be available to other processes, it has to update environment variable on Machine or User scope(assuming they run on same user), this is why you can't see from command running SET variablename
...
Assuming the variable is set correctly and it is a machine scope variable...
When the Environment Variable is set before the process start, I would suggest you setup an EntryPoint Script to set it at startup, like you would do to a guest executable.
See a NodeJs example here
You could maybe also do write to file and read from your app as Loek suggested, but I think it would be too complicate for too litle.
In case the environment variable is set after the process started, or if it changes later, you should get it from within your application directly instead, you could just use:
System.Environment.GetEnvironmentVariable(variableName,EnvironmentVariableTarget.Machine);
And you pass the variable name via config.
In both cases your user\process must have permission to read Environment Variable from Machine Scope