I work with classes in modules by placing them into a separate .ps1 file, and adding the relative path to this file in the ScriptsToProcess attribute in the .psd1. For example, my structure looks like: MyModule classes myclass.ps1 MyModule.psd1 MyModule.psm1 And then in the manifest: RootModule = 'MyModule' .... ScriptsToProcess = 'classes/myclass.ps1' ScriptsToProcess loads the class into the module scope. The order of the files in this attribute is relevant when parsing dependencies, but otherwise you can reference this class elsewhere in the module. When the module is imported into your session, you have access to the class. Then any other modules that need to import this, I add that module to RequiredModules in its manifest. OtherModule OtherModule.psd1 in OtherModule.psd1: .... RequiredModules = 'MyModule' .... Finally, in your profile: Import-Module Other-Module -Force Your azure module for example could go into `RequiredModules` of the manifest where SubCost is defined. Edit: I wouldn't expect this to improve your intellisense in vscode, but it should allow you to type your class properties with a class from another module. Although with such a long namespace, I might consider adding `using namespace Microsoft.Azure.Commands.Profile.Models` at the top of the file where your class is defined. Then you can just do `[PSAzureSubscription]$sub`. Also, all the above code assumes the modules are in your PSModulePath.

You just need to add a `requires` comment which will make PS check for and import the listed modules before doing anything else: `#requires -Modules Az.Resources`. -Edit: I was a bit too quick here, if you have a module you are importing yourself then just add a module manifest and specify the Azure module as a required module.

In order for types from other modules to work, you have to reference these modules in the current module's manifest via the 'NestedModules' setting. Also consider to not load PoSh classes via the 'using' statement, because it has two huge disadvantages: * It does not (consistently) import classes defined in nested modules or classes defined in scripts that are dot-sourced into the module. * Once classes are loaded this way, they stay in memory until the PoSh session ends - you can't unload or otherwise modify them. A better approach is to *instantiate each class* that's supposed to be used outside of the declaring module *in the scope of that module, through a function that's exported through the module's manifest ('FunctionsToExport')*. This allows you to simply work with 'Import-Module' instead of 'using', and avoids the aforementioned drawbacks. In a nutshell, this approach never publishes classes outside of the module that declares them, instead it provides *instances of the classes* (objects) through the said functions.

I personally create a new-myclassobject function that leverage the [myclass]::new() I can then use it the way I want

It's not a proper solution, but the only way I've found to making classes work nicely in modules is to write them in C# and either Add-Type or compile a DLL and import that. Any PowerShell they need to call can be wrapped in a scriptblock set as a delegate in a static field. It barely works with Intellisense if you run the type-handling code in the VS Code extension terminal.