PowerShell / PowerShell/PSResourceGet
User context, don't install to `%OneDriveCommercial%` if OneDrive for Business Known Folder Move (KFM) is enabled
Dieses Issue hat noch niemand übernommen.
- Vorherrschende Sprache
- C#
- Sterne
- 576
- Forks
- 114
- Ø Merge
- 1 T. 2 Std.
- Gemergte PRs (30 T.)
- 7
Beschreibung
Summary of the new feature / enhancement
Behavior today
Default install location for PowerShell scripts and modules when specifying user context, is:
- Windows PowerShell:
%USERPROFILE%\Documents\WindowsPowerShell\Modules - PowerShell Core:
%USERPROFILE%\Documents\PowerShell\Modules
But if you have OneDrive for Business set up with Known Folder Move (KFM), default install location for user context is:
- Windows PowerShell:
%OneDriveCommercial%\Documents\WindowsPowerShell\Modules - PowerShell Core:
%OneDriveCommercial%\Documents\PowerShell\Modules
Why is it a problem
This is not ideal, as you'll end up with hundreds or thousands of small files that will be synced up and down to OneDrive, which might cause OneDrive sync issues, and other performance hits.
I currently install all modules to AllUsers scope for this reason. Currently 2.7 GB, 12 617 files, 2 315 folders.
Screenshot

If I did not care about this myself, I'd be using more than 1 / 10 of the capacity / max number of files recommendation for the OneDrive client, just for PowerShell modules.
Proposed technical implementation details
In my opinion, there is no reason to install PowerShell modules from PowerShell Gallery to OneDrive by default when KFM is active. A publicly available PowerShell module is nothing unique that needs to be backed up/ synced.
Option 1 - Cmdlet to set PSResourceLocation for Process/User/Machine
Add cmdlet to set PSResourceLocation for scope Process/User/Machine. For instance:
Set-PSResourceLocation -Scope 'Process' -Path ('{0}\Microsoft\PowerShell' -f $env:LOCALAPPDATA)
It could also:
- Add path to
[System.Environment]::GetEnvironmentVariable('PSModulePath','<scope>'). - Have a Boolean parameter that specifiec whether to move modules and scripts installed by
PackageManagement,PowerShellGetandMicrosoft.PowerShell.PSResourceGetfrom old path given scope to new path.- Ask user if parameter wasn't specified.
Option 2 - Use first path in $env:PSModulePath if set
If I've set [System.Environment]::GetEnvironmentVariable('PSModulePath','User').Split(';')[0] to be somewhere else than the default location for <scope>, use it.
Option 3 - Don't follow KFM redirect
Users must opt in to install PowerShell modules to OneDrive, instead of current default behavior.
- Windows PowerShell:
%USERPROFILE%\Documents\WindowsPowerShell\Modules - PowerShell Core:
%USERPROFILE%\Documents\PowerShell\Modules
Option 4 - Change default location for user scope to %LOCALAPPDATA%
Change default location for user context to:
- Windows PowerShell:
%LOCALAPPDATA%\WindowsPowerShell\Modules - PowerShell Core:
%LOCALAPPDATA%\PowerShell\Modules
Beitragsleitfaden
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Öffne einen Pull Request, der die Issue-Nummer nennt.
Rechercherichtung
Das Issue nennt keine Implementierungsdateien, Einstiegspunkte oder Tests. Kläre zuerst, welcher der vier vorgeschlagenen Ansätze vorgesehen ist, und ermittle dann die Auflösung des Installationspfads für den Benutzerkontext sowie deren Abdeckung für Windows PowerShell und PowerShell Core. Als abgeschlossen sollte gelten, dass das ausgewählte Verhalten für OneDrive Known Folder Move-Szenarien implementiert und verifiziert ist, ohne normale Installationen im Benutzerkontext zu beeinträchtigen.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- csharp, powershell
- Bereich
- cli, tooling
- Issue-Typ
- Feature
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Aktivitätsstatus
- Veraltet
- Klarheit
- Muss geklärt werden
- Anfängerfreundlichkeit
- 25/100