Enable Windows PowerShell PSModulePath by default on Windows by SteveL-MSFT · Pull Request #4132 · PowerShell/PowerShell

SteveL-MSFT · 2017-06-28T16:20:09Z

Now that we have moved to .Net Std 2.0 compatible CoreClr 2.0 and added capability to search GAC for assemblies, we need to make it easier for users to use Windows PowerShell modules from PSCore6 to get feedback on compatibility.

This change is only for Windows and appends the Windows PowerShell PSModulePath on startup. Depending on the data/feedback we get, we can decide what to do (opt-in vs opt-out) as we get closer to a release candidate.

Out-Default tests has to be updated to suppress the Warning message by not loading the profile.

Related #4056

Based on the customer data, we can decide a more permanent solution.

…ell PSModulePath by default to encourage testing of using FullCLR modules

adityapatwardhan · 2017-06-28T17:28:15Z

build.psm1

 The currently installed .NET Command Line Tools is not the required version.

-Installed version: $dotnetCLIIntalledVersion 
+Installed version: $dotnetCLIIntalledVersion


Typo in Installed.

That wasn't part of this PR, but since I only see 3 hits, I'm leaning towards fixing it here instead of a new PR

adityapatwardhan · 2017-06-28T17:42:24Z

src/powershell-win-core/Microsoft.PowerShell_profile.ps1

+	# If a Windows PowerShell module works or not, please provide feedback at https://github.com/PowerShell/PowerShell/issues/4062
+
+	Write-Warning "Appended Windows PowerShell PSModulePath"
+	$env:psmodulepath += ";${env:userprofile}\Documents\WindowsPowerShell\Modules;${env:programfiles}\WindowsPowerShell\Modules;${env:windir}\system32\WindowsPowerShell\v1.0\Modules\"


This only gets the default, if the Windows PSModulePath is modified by installing Azure cmdlets or SQL, then they won't be available. We would need something like this:

$env:PSModulePath += (";" + (& ${env:windir}\system32\windowspowershell\v1.0\powershell.exe '$env:PSModulePath'))

Calling out to Windows PowerShell can incur a 150-250ms startup penalty. Since this change isn't intended to be the final solution and just helps to get customer feedback, I think we are ok with it not being 100% accurate. Advanced customers can update their PSModulePath as needed.

SteveL-MSFT · 2017-06-28T19:25:16Z

Although I intend for this to be temporary, I'll add a test case

adityapatwardhan · 2017-06-28T23:44:16Z

build.psm1

+    # copy PowerShell host profile if Windows
+    if ($IsWindows)
+    {
+        Copy-Item -Path "$PSScriptRoot/src/powershell-win-core/Microsoft.PowerShell_profile.ps1" -Destination $publishPath


-Force ? When rebuilding without cleaning.

make sense, will add

adityapatwardhan · 2017-06-28T23:55:09Z

test/powershell/engine/Module/ModulePath.Tests.ps1

+
+    It "Default PowerShell profile appends Windows PowerShell PSModulePath only on Windows" {
+
+        $psmodulepath = & $powershell -c '$env:PSModulePath'


Like in this test case, would other tests now have the warning message and fail? Can you verify by running all tests?

I thought I did, but hit a few more failures. Will fix.

lzybkr · 2017-06-29T18:44:41Z

Because this is a temporary change - can we have a temporary test that will fail at some fixed point in the future - even if it's a nightly failure, that would be fine.

The point here - if we reach that point where the test starts failing, we need to take action, either implement this correctly (not via a profile script), remove it, or something else.

SteveL-MSFT · 2017-06-30T17:39:50Z

@lzybkr rather than having a temporary test, I've changed this to not be a 'fix' but related so we'll keep the issue open and will revisit after we get some customer data

…ell into windows-psmodulepath

SteveL-MSFT · 2017-07-03T15:24:07Z

@adityapatwardhan looks like I had some changes staged on a different computer that wasn't committed (Console Tests), can you take a quick look?

adityapatwardhan

LGTM

SteveL-MSFT · 2017-07-03T23:48:12Z

@lzybkr can you merge so we can get this in for beta.4?

SteveL-MSFT · 2017-07-06T00:55:58Z

@TravisEz13 can you merge this since @lzybkr is currently out of office?

alexandair · 2017-07-17T14:00:35Z

This change doesn't make sense on new Nano Server container.
This is what you see when you start microsoft/nanoserver-insider-powershell:

"WARNING: Appended Windows PowerShell PSModulePath"

PS C:\> $env:psmodulepath -split ';'
PowerShell\Modules
c:\program files\powershell\Modules
C:\Users\ContainerUser\Documents\WindowsPowerShell\Modules
C:\Program Files\WindowsPowerShell\Modules
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\

3 of those 5 paths are unnecessary on new Nano Server.

SteveL-MSFT · 2017-07-17T15:52:10Z

@alexandair you are correct, NanoServer-Insider doesn't have Windows PowerShell Core 5.1 anymore. Can you add a comment to #4056? The final resolution to this will likely be adding a config setting to the startup json file and checking if full windows. Thanks.

alexandair · 2017-07-17T16:53:28Z

@SteveL-MSFT Done.

MathiasMagnus · 2017-07-23T20:28:05Z

Is there a way to turn off the warning? It's fairly annoying and I can give feedback without it reminding me on every startup.

SteveL-MSFT · 2017-07-24T03:11:43Z

@MathiasMagnus edit Microsoft.PowerShell_profile.ps1 in $PSHome and remove the Write-Warning line

MathiasMagnus · 2017-07-24T06:58:39Z

@SteveL-MSFT Thanks. :)

As a sidenote: is it instructive to think that these are 1-to-1 mappings?

Powershell	Bash
`$PSHOME\Microsoft.PowerShell_profile.ps1`	`/etc/profile`
`$PROFILE`	`~/.profile`

SteveL-MSFT · 2017-07-24T17:05:55Z

@MathiasMagnus yes

Default powershell host profile for Windows to append Windows PowerSh…

8ff38c3

…ell PSModulePath by default to encourage testing of using FullCLR modules

SteveL-MSFT assigned lzybkr Jun 28, 2017

SteveL-MSFT requested review from BrucePay, joeyaiello and lzybkr June 28, 2017 16:20

msftclas added the cla-not-required label Jun 28, 2017

Change test to use -noprofile to make output more predictable

05d723b

adityapatwardhan requested changes Jun 28, 2017

View reviewed changes

SteveL-MSFT force-pushed the windows-psmodulepath branch from 232f7f3 to 4f067eb Compare June 28, 2017 20:41

added tests, fixed typo

1eb7b51

SteveL-MSFT force-pushed the windows-psmodulepath branch from 4f067eb to 1eb7b51 Compare June 28, 2017 21:24

adityapatwardhan requested changes Jun 28, 2017

View reviewed changes

added tests, fixed typo

85b6401

SteveL-MSFT force-pushed the windows-psmodulepath branch from 1eb7b51 to 85b6401 Compare June 30, 2017 17:37

added -force to copy-item use

e6e064b

adityapatwardhan approved these changes Jun 30, 2017

View reviewed changes

Merge branch 'windows-psmodulepath' of github.com:SteveL-MSFT/PowerSh…

68b06c5

…ell into windows-psmodulepath

adityapatwardhan approved these changes Jul 3, 2017

View reviewed changes

SteveL-MSFT assigned TravisEz13 and unassigned lzybkr Jul 6, 2017

daxian-dbw approved these changes Jul 7, 2017

View reviewed changes

daxian-dbw merged commit 7bce165 into PowerShell:master Jul 7, 2017

SteveL-MSFT deleted the windows-psmodulepath branch July 17, 2017 15:52

TravisEz13 mentioned this pull request Feb 13, 2018

Tests should explicitly pass -NoProfile when launching powershell. #3881

Closed


		It "Default PowerShell profile appends Windows PowerShell PSModulePath only on Windows" {

		$psmodulepath = & $powershell -c '$env:PSModulePath'

Conversation

SteveL-MSFT commented Jun 28, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SteveL-MSFT commented Jun 28, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lzybkr commented Jun 29, 2017

Uh oh!

SteveL-MSFT commented Jun 30, 2017

Uh oh!

SteveL-MSFT commented Jul 3, 2017

Uh oh!

adityapatwardhan left a comment

Choose a reason for hiding this comment

Uh oh!

SteveL-MSFT commented Jul 3, 2017

Uh oh!

SteveL-MSFT commented Jul 6, 2017

Uh oh!

alexandair commented Jul 17, 2017

Uh oh!

SteveL-MSFT commented Jul 17, 2017

Uh oh!

alexandair commented Jul 17, 2017

Uh oh!

MathiasMagnus commented Jul 23, 2017

Uh oh!

SteveL-MSFT commented Jul 24, 2017

Uh oh!

MathiasMagnus commented Jul 24, 2017

Uh oh!

SteveL-MSFT commented Jul 24, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

SteveL-MSFT commented Jun 28, 2017 •

edited

Loading