1 voteWim shared this idea ·
An error occurred while saving the commentWim commented
The behaviour is also inconsistent.
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 after import-module for that session.
When you create a 'classic' PowerShell module (using .psm1/.psd1) the classes inside the module are only available to that module internally, but not 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.
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.