Environment Variable Fixup Proposal

MVP

Some traditional applications make use of environment variables. 

  • These are typically added as part of the installation/customization.
  • They may be declared as System or User in scope.
  • Ultimately, they are stored in the registry but added to the process' environment block inside the kernel.

While Microsoft App-V had support for the package declaring environment variables in the manifest, MSIX does not.  The App-V support turned what may have originally been an environment variable of System or User scope into one with an Application-specific scope.

 

I am proposing the creation of a new PSF Fixup called EnvVarFixup.  When included in the package this would allow for a config.json definition of Application-specific scope environment variables.  The configuration would consist of an array of tuple values:

  • name
  • value
  • useregistry

The name parameter would be the name of the environment variable.

 

The value parameter would be the value specified directly, or an empty string if useregistry is specified to true.

 

The useregistry parameter is a boolean, and when set to true it indicates that the application hive registry should be queried for the value. In this case, the current user portion of the application hive is checked first, followed by the machine portion if necessary.

 

The fixup would apply to:

  • GetEnvironmentVariable()
  • SetEnvironmentVariable() - but only if useregistry is specified.  Writing would only be made to the current user portion of the application hive so that the write will succeed.

 

Consideration for ExpandEnvironmentStrings() will also be given, but at this time it is probably out of scope for the project.  It should be able to be added at a later time without the need to change the Json configuration.

 

I am working on the prototype now, and encourage any feedback.

5 Replies

@TIMOTHY MANGAN 

 

I like that idea.  It is aweomse.  I thought MSIX had support for environment variables though?  Or is it only during install time can a package write environment variables?

@Darren_Hoehna I am unaware of any support for environment variables in MSIX. (See post from 2 years ago https://techcommunity.microsoft.com/t5/msix-deployment/no-support-for-virtualized-environment-variab...)

Certainly, even today if I capture an installer that sets either user or system environment variables with the MSIX Packaging Tool, the packaged app doesn't see them. 

 

If there is a Manifest setting needed and the packaging tool just doesn't use it (sort of like Fonts...), please let me know.

@TIMOTHY MANGAN 

 

I was mistaken.  I thought MSIX had something to read and write environment variables.  I was wrong.

 

Before you get too far with your prototype I was wondering if, instead of specifying what Registry keys the user needs to put in the config, why not redirect all registry reads and writes?  That way the user can use this fixup in a plug-and-play style?

 

Cheers,

 

Darren.

@Darren_Hoehna I'm unfamiliar with the "plug-and-play" scenario, so I'm not sure what you mean.  Perhaps you can clarify?

 

However, I'll explain what I have so far.  For a developer building a package, they don't need the registry and can specify the variables using the fixup with definitions in the Json.  The registry option might be useful for developers if they want the app to be able to modify the value at runtime.

 

The registry aspect is primarily intended as an option for repackaged apps that captured an installed environment variable, using the registry based data.  This option is preferred, because while the Json file is immutable, if we pull from the registry the app at runtime may update the setting, allowing for normal MSIX redirection to save off the registry changes (at least for User based environment variables stored under HKCU).

The EnvVarFixup that was described here is now up in the Microsoft GitHub sources in the Develop branch. For those interested, PsfTooling 4.2 is now up in the Microsoft Store and includes support for this new type of intercept-based fixup.