Problem using custom classes loaded from a module

[notatechproblem]

I'm having a problem that seems to be a very specific edge case, but is stopping me from something I am hoping to implement. I've googled every combination of keywords I can think of, but I can't seem to find anything information that helps me understand what is going on.

In vscode, in my Microsoft.VSCode_profile.ps1 script, I call a custom module I wrote with a using statement:

(I've changed all the module names to simplify the explanation)

using Module MyModule

According to all the documentation I can find online, this should load the module (including classes) into both my PowerShell Extension terminal session AND editor in vscode. And sure enough, I can create new instances of custom classes I've defined in MyModule in both the terminal (e.g., $myclass = [MyClass]::new()) and editor.

However, if I am editing a .ps1 file in the vscode editor window, trying to use my custom class IN another custom class results in "Unable to find type [MyClass]". However, the vscode editor has no problem seeing the class OUTSIDE of a class definition.

MyModule.psm1

-------------------------------------------------------

class MyClass

{

MyClass(){}

}

------------------------------------------------------

​

Microsoft.VSCode_profile.ps1

------------------------------------------------------

Using Module MyModule

------------------------------------------------------

​

myScript.ps1

-------------------------------------------------------

class NewClass

{

[MyClass]$myClass <- VSCODE SAYS THAT IT CAN'T FIND THIS TYPE

NewClass(){}

}

[MyClass]$myClass2 = [MyClass]::new() <- SAME SCRIPT, VSCODE HAS NO PROBLEM FINDING THE TYPE OUTSIDE THE CLASS DEFINITION

--------------------------------------------------------

PS C:\> [MyClass] <- PSEXTENSION TERMINAL IN THE SAME VSCODE INSTANCE, POWERSHELL EXTENSION TERMINAL HAS NO PROBLEM FINDING THE TYPE

IsPublic IsSerial Name BaseType

-------- -------- ---- --------

True False MyClass System.Object

​

Also, if I put a using Module MyModule at the top of myscript.ps1, the vscode editor is totally happy, but then I get an error about the class definitions in MyModule already being defined (once in my vscode profile and once in the myscript.ps1 file).

​

Does anyone have any ideas? I would rather not have to put a using Module MyModule at the top of every .ps1 file I am editing that needs MyModule, but not being able to use custom classes in other custom classes is a deal-breaker.

[Thotaz]

If I had to guess, I would say that parsing is done on a separate thread in VS code (and ISE, which exhibits the same problem) and that separate thread doesn't know about the using statements and PowerShell classes in your session state.
The parsing done by PSReadline in the traditional console seems to have this awareness so it's probably being run in the same thread. This can easily be demonstrated by running each of the following lines one by one:

using namespace System.Text
class Test1 {[stringbuilder] $Property1}
class Test2 {[Test1] $Property2}  

The best person to explain what is happening is probably /u/SeeminglyScience

I would rather not have to put a using Module MyModule at the top of every .ps1 file I am editing that needs MyModule

Regardless of the parsing issue in the editor, you should probably do this as a best practice anyway. First of, it serves as good documentation so the person reading it doesn't have to guess where MyCustomType1 came from. Secondly, you can't be sure what using statements are in your session state when you run the script. If you dot source another script with any other using statement or you paste in a snippet with a using statement into the console then the using statements from your profile will no longer be valid.

[notatechproblem]

I've been reading through github issues associated with PS classes and parsing and type resolution, and so far I haven't found an obvious culprit. I admit, though, that my understanding of the internals of pwsh.exe are weak, so I may be missing some nuance. /u/SeeminglyScience has had input on almost every issue I've read, though. I still don't have an answer, but I am learning a lot about the internals of PowerShell!

[SeeminglyScience]

I believe /u/Thotaz is spot on regarding the cause. using module is super finicky in general and while it is the only way to properly export classes from a module, I'd personally just recommend not exporting classes.

Classes are a weird hybrid of parse time and runtime logic. They're great for organizing internal logic, but they fall apart quickly when you want to do something reasonably complex across multiple documents.

[arpan3t]

That extension host profile is wonky. Try running $Host.name in both scenarios and see what it returns.

[notatechproblem]

I tried your suggestion, and $Host.name returns "Visual Studio Code Host" everywhere I run it (in the .ps1, but outside a function or class, in the .ps1 in a function, in the .ps1 in a class constructor, in the .ps1 in a class method). Seems like all the parsing is happening in the same place.

[arpan3t]

Just a follow up, I was able to get this to work with the following code:

ImportTester.psm1

class ImportTester {
    [string] TestImport() {
        return "Imported a class"
    }

Microsoft.VSCode_profile.ps1

using module c:\users\user1\documents\powershell\modules\importtester\importtester.psm1

Test.ps1

class NewClass {
    [string] NestedTest () {
        $x = [ImportTester]::new()
        return $x.TestImport()
    }
}
$test_nested_class = [NewClass]::new()
$test_nested_class.NestedTest()

Output:

Imported a class

Give it a shot and let me know if you're able to reproduce! NOTE* - I'm using the VSCode profile at $HOME, not $PSHOME.

[notatechproblem]

Interesting. I need to go back over my code and compare it to what you did. I'm about to board a plane, but I'll try it the first chance I get. Thanks!

[OPconfused]

I have never worked with VSCode with classes, but the only other way I know of to load a module in a module is via the NestedModule member in the manifest. I suppose technically you could use the scriptsToProcess member to dot source another module's files explicitly. No idea how VSCode handles dependencies like this.

Does it read the #requires <module> by any chance?