PowerShell / PowerShell/PowerShell
PowerShell classes behaviour inconsistent
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 55.5k
- Forks
- 8.5k
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 88
Description
When you create a binary PowerShell module, just by compiling a simple, barebones C# class DLL and adding it to the module path (even without manifest), the class objects inside the DLL will be immediately available for that session after the command 'import-module'.
When you create a 'classic script based' PowerShell module (using .psm1/.psd1) the classes inside the module are only available to that module internally, but not to the PS session by default, unless you run the 'using module ...' command in the PowerShell session.
That by itself is already inconsistent. It gets more confusing when you create a new object using New-WebserviceProxy. The associated classes from the online web service are from then on also available in the current session, without any extra loading.
So, classes in 'foreign' modules are autoloaded and available, while 'PowerShell native' classes are not. This seems to be bug or at least inconsistent behaviour.
It would be great if the 'Export-ModuleMember' command was expanded to support classes as well.
(I have a feeling this is an oversight. I spoke to someone at the PowerShell booth at Microsoft Ignite 2016 and the person was surprised classes inside text based .psm1 files are not available outside the module by default)
See also related comments on: https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/16504684-package-powershell-classes-in-a-module
Steps to reproduce
Create new PowerShell module with classes inside. Classes not available by default when importing module.
Expected behavior
Classes from binary PowerShell modules as well as classic, script based module should load in the same way.
Actual behavior
You need to explicitly call 'Using module ...' in the running PowerShell session in order to get access to the classes inside a script based PowerShell module.
Environment data
> $PSVersionTable
Name Value
---- -----
PSVersion 5.1.14393.206
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14393.206
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the difference between binary modules and .psm1/.psd1 modules using the stated import-module and using module commands. Compare the class behavior with New-WebServiceProxy and investigate whether Export-ModuleMember is the relevant entry point. Done means the module class-loading behavior is consistent, with coverage for the reported scenarios.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp, powershell
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100