Votes from Connect: 10

Original Date Submitted: 5/9/2012 10:46:55 PM

Description:
********Contact Information********
Handle: Kirk Munro
Site Name: PowerShell
Feedback ID: 741367
***************************************

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
This is a request for v.Next (post v3). More and more admins have been asking how they can store modules in a central repository so that they can centrally manage them while making them available to all systems where they use PowerShell. This is easy to do, however they need to be careful because some modules are designed to store configuration/state information in their own module folder. That won't work if the end user doesn't have rights to the location where the module is stored. It's also not a good practice to follow because there are specific locations where application data should be stored (Isolated Storage, for example).

I would like to see an enhancement made such that modules either have access to a new automatic variable ($PSModuleLocalStorage) with methods that facilitate writing/reading module configuration data to/from disk in the right location for each user of that module, or a small set of cmdlets specific to modules that are designed to facilitate the same thing. This feature should use the module GUID as part of the path automatically so that changes in module names don't affect the location where configuration/state information is stored.

There are other possibilities for this feature that could be considered as well, such as:
1. Storing the version of the module with the data so that module authors can detect the version when reading from disk and then perform upgrades if the data being used has changed between versions.
2. Encrypting the data written to disk automatically so that only the current user can access it (could be a module-specific setting).
3. Providing easy reading/writing of a single data file (the most common/simple use case), with support for reading/writing of additional files to the same location (for more complex module needs).

This is just a request for the most basic functionality to start though.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 741367 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=741367).

Repro Steps:
Try to store module configuration/state data for the current user in the module folder when the module is on a file share that the user doesn't have access to. You can't do that. Now try to easily identify where you should store that data and store it there so that it is easily accessible to the module even if the name changes and so that the folder is automatically created if it does not exist without writing a lot of script to handle that. You can't, it takes a fair amount of script to do this right.

Expected Results:
This should be easier, and it should promote best practices automatically, so that module authors do this consistently and correctly every time.

Internal BugId: 3569