Incorrect module path when using .NET interactive
Prerequisites
- [X] Write a descriptive title.
- [X] Make sure you are able to repro it on the latest released version
- [X] Search the existing issues.
Steps to reproduce
When running Install/Update-PSResource in a .NET interactive notebook the installation path is incorrectly set as Documents\WindowsPowerShell, even though powershell core is being used
Notebook code (.dib file)
#!pwsh
$PSVersionTable
Install-PSResource -Name 'Az.Accounts' -Repository PSGallery -Scope CurrentUser -Verbose -TrustRepository
Output:
Name Value
---- -----
PSVersion 7.1.3
PSEdition Core
GitCommitId 7.1.3
OS Microsoft Windows 10.0.19042
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
VERBOSE: All paths to search: 'C:\Users\henry.buckle\Documents\WindowsPowerShell\Modules'
VERBOSE: All paths to search: 'C:\Users\henry.buckle\Documents\WindowsPowerShell\Scripts'
VERBOSE: Performing the operation "Install-PSResource" on target "package to install: 'Az.Accounts'".
VERBOSE: Parameters passed in >>> Name: 'Az.Accounts'; Version: ''; Prerelease: 'False'; Repository: 'PSGallery'; AcceptLicense: 'False'; Quiet: 'False'; Reinstall: 'False'; TrustRepository: 'True'; NoClobber: 'False';
VERBOSE: Attempting to search for packages in 'PSGallery'
VERBOSE: Untrusted repository accepted as trusted source.
VERBOSE: Null Type provided, so add PSGalleryScripts repository
VERBOSE: Searching in repository PSGallery
VERBOSE: 2.5.2.0
VERBOSE: Null Type provided, so add PSGalleryScripts repository
VERBOSE: Searching in repository PSGallery
VERBOSE: Searching through package path: 'C:\Users\henry.buckle\Documents\WindowsPowerShell\Modules\Az.Accounts'
VERBOSE: Searching through package path: 'C:\Users\henry.buckle\Documents\WindowsPowerShell\Modules\Az.Accounts'
show more (open the raw output data in a text editor) ...
VERBOSE: Attempting to move 'C:\Users\henry.buckle\AppData\Local\Temp\76e3ca5f-c444-4a13-8225-6e7b6b1069f0\az.accounts\2.5.2' to 'C:\Users\henry.buckle\Documents\WindowsPowerShell\Modules\Az.Accounts\2.5.2'
VERBOSE: Successfully installed package 'Az.Accounts' to location 'C:\Users\henry.buckle\Documents\WindowsPowerShell\Modules'
VERBOSE: Attempting to delete 'C:\Users\henry.buckle\AppData\Local\Temp\76e3ca5f-c444-4a13-8225-6e7b6b1069f0'
VERBOSE: Successfully deleted 'C:\Users\henry.buckle\AppData\Local\Temp\76e3ca5f-c444-4a13-8225-6e7b6b1069f0'
Expected behavior
Installation path should be `Documents\PowerShell`
Actual behavior
Installation path is `Documents\WindowsPowerShell`
Error details
No response
Environment data
ModuleType Version PreRelease Name ExportedCommands
---------- ------- ---------- ---- ----------------
Binary 3.0.11 beta PowerShellGet {Find-PSResource, Get-Install…
Name Value
---- -----
PSVersion 7.1.3
PSEdition Core
GitCommitId 7.1.3
OS Microsoft Windows 10.0.19042
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Visuals
No response
Seems like for some reason the host version in .NET interactive is 0.0.1
function FunctionName {
[cmdletbinding()]
param ()
Write-Host $PSCmdlet.Host.Version
}
FunctionName
0.0.1
@hbuckle thanks for reaching out!
Could you share your PS Modules path output with us by running:
$env:PSModulePath
We haven't yet done testing in the .NET interactive notebook and will test this scenario.
This is PSModulePath from the .NET interactive kernel
C:\Users\henry.buckle\.nuget\packages\microsoft.dotnet-interactive\1.0.240403\tools\net5.0\any\Modules
C:\Users\henry.buckle\Documents\PowerShell\Modules
C:\Program Files\PowerShell\Modules
c:\users\henry.buckle\.nuget\packages\microsoft.dotnet-interactive\1.0.240403\tools\net5.0\any\runtimes\win\lib\net5.0\Modules
C:\Program Files\WindowsPowerShell\Modules
C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules
I'm not sure when exactly this may have been resolved, but it looks like it is no longer an issue as of 3.0.14-beta14. I'm going to close this issue as resolved, but if you're still having this issue or see this issue pop up again in the future please let us know either here or in a new issue. Thanks!
@alerickson - I just tried this again and get the same issue with 3.0.17
Save the following as a .dib file and open in VSCode with the ms-dotnettools.dotnet-interactive-vscode extension
#!pwsh
$env:PSModulePath -split ';'
Get-Module PowerShellGet
Get-PSResource -Scope CurrentUser -Name 'Az' -Verbose
When you run the cell you get the following
C:\Users\henry.buckle\.nuget\packages\microsoft.dotnet-interactive\1.0.350406\tools\net6.0\any\Modules
C:\Users\henry.buckle\Documents\PowerShell\Modules
C:\Program Files\PowerShell\Modules
c:\users\henry.buckle\.nuget\packages\microsoft.dotnet-interactive\1.0.350406\tools\net6.0\any\runtimes\win\lib\net6.0\Modules
C:\Program Files\WindowsPowerShell\Modules
C:\windows\system32\WindowsPowerShell\v1.0\Modules
VERBOSE: Retrieving directories in the path 'C:\Users\henry.buckle\Documents\WindowsPowerShell\Modules'
VERBOSE: Retrieving directories in the path 'C:\Users\henry.buckle\Documents\WindowsPowerShell\Scripts'
VERBOSE: All paths to search: 'C:\Users\henry.buckle\Documents\WindowsPowerShell\Modules\PackageManagement'
VERBOSE: All paths to search: 'C:\Users\henry.buckle\Documents\WindowsPowerShell\Modules\PowerShellGet'
VERBOSE: Entering GetPSResource
I think the use of psCmdlet.Host.Version here is wrong - this is the version of the hosting application, not the PowerShell engine
https://github.com/PowerShell/PowerShellGet/blob/b005e0fff5fc02ca09e8502b947da9ea13c90b20/src/code/Utils.cs#L723

@alerickson, @anamnavi any update?
If it helps this is how PowerShellEditorServices does it
https://github.com/PowerShell/PowerShellEditorServices/blob/main/src/PowerShellEditorServices/Utility/VersionUtils.cs
@hbuckle thanks for providing such thorough info, we'll investigate into this.
@alerickson @alerickson - will it be fixed for GA? It looks like psCmdlet.Host.Version is still in use
This is also an issue when using RubyPwshPSHost which is what Puppet uses to call PowerShell.
It would definitely be nice to have this fixed.