Issues with 'Using Module' and classes

[LethiferousMoose]

System Details

• Operating system name and version: Windows 10 Enterprise

PS > code -v
1.17.2
b813d12980308015bcd2b3a2f6efa5c810c33ba5

PS > $pseditor.EditorServicesVersion
Major  Minor  Build  Revision
-----  -----  -----  --------
1      4      1      0


PS > code --list-extensions --show-versions
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

PS > $PSVersionTable
Name                           Value
----                           -----
PSVersion                      5.1.15063.674
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.15063.674
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Issue Description

When using a class from a different module, the PowerShell plugin cannot locate the class source. I have a module which contains class definitions, then in another module I use the "Using module " to load the classes into the session for the module to use. It would be nice if the plugin could locate the supplied module and load in the classes to stop the editor "Unable to find type" errors from occurring.

[LethiferousMoose]

This appears to work as expected when using PowerShell Core.

[TylerLeonhardt]

Thanks for the report!

Just to understand you more, do you mean that intillisense/"go to definition" isn't working for classes?

Can you share some code and a screenshot of the "unable to find type" errors?

[LethiferousMoose]

Sure, in my code I have a module that I use to store all my "shared" classes and then I use the Using Module syntax to include the base classes that I use in my modules. In this case, I have a class for creating a RuntimeDefinedParameter called ProductParameterBuilder that extends my base class DynamicParameterBuilder which lives in "classes" module.
Something like the following:
<workspace>/PSClasses/PSClasses.psm1

class DynamicParameterBuilder {
    [System.Management.Automation.RuntimeDefinedParameter]
    CreateParameter([string] $ParameterName) {
        throw [System.NotImplementedException]::new();
    }
}

<workspace>/PSEnvironment/PSEnvironment.psm1

Using Module PSClasses
...
class ProductParameterBuilder : DynamicParameterBuilder {
    [System.Management.Automation.RuntimeDefinedParameter]
    CreateParameter([string] $ParameterName) {
        # Implementation logic
    }
}

If I use the PowerShell plugin with version 5.1, the base class gets underlined in red and gives the reason "Unable to find type [DynamicParameterBuilder]".

Now if I click the PowerShell icon in the status bar and switch to PowerShell Core 6.0 rc, the error underline goes away.

Intellisense/"go to definition" does not work either, but I did not know if that was supposed to be a feature or not.

Let me know if you have anymore questions.

[TylerLeonhardt]

Can you try one thing for me?

When you get the "Unable to find type" error, can you try F8'ing the using module line and see if the error goes away?

Also could you try restarting the PowerShell session using the command pallet and see if that fixes it?

Thanks for your patience!

[LethiferousMoose]

Okay, I just tried executing F8 on the Using Module line, and I see it executing in the Integrated Console, but the errors persist. I have also run "Restart Current Session", the result is the same.

FYI, I am switching to PowerShell Core going forward so this won't be an issue for me personally, but it would be good to know why this causes errors in PowerShell 5.1

[AlexBillon07]

Hello,

Same issue here

PS C:\EDI> code -v
1.23.1
d0182c3417d225529c6d5ad24b7572815d0de9ac
x64
PS C:\EDI> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.14409.1012
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.14409.1012
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1                      

[rjmholt]

If the problem is the red squigglies appearing under types imported with using, that might be an issue in PSScriptAnalyzer rather than with us -- and executing the line shouldn't help since PSScriptAnalyzer runs in its own runspace.

I believe something like this was addressed in PSScriptAnalyzer: PowerShell/PSScriptAnalyzer#957. And it looks like there hasn't been a PSScriptAnalyzer release in a little while, so maybe that will fix it?

PS classes defined in other files imported with using should pretty much work out of the box I would imagine (binary modules are another matter, but I'm closing in on a solution to that...).

Completions for using should be possible as well, but if you'd like that, please open a separate issue so we can track the work and gauge priority.

[AlexBillon07]

My problem is that the "Go to definition" doesn't work for classes definitions and methods.
I get the "No definition found for" bubble where I believe VSCode should be able to locate th definition of a class or a method.

Maybe I misunderstood this ticket and should open a new issue ?

[rjmholt]

Ok cool — I think I interpreted the "unable to find type" part as a diagnostic from PSScriptAnalyzer there, not a VSCode error.

Ah, just saw the images above. Yes, the unable to find type part is a PSScriptAnalyzer thing. But we should be able to do something about the "Go to definition".

We'll look into this. Thanks for the report!

[TylerLeonhardt]

Just to add on to what @rjmholt said, "Go to definition" doesn't work because we are using legacy AST APIs to support PowerShell v3/v4 in the extension.

We are looking to drop 3,4 which will allow us to use modern AST APIs which should give us symbols for classes.

I'm going to close this issue because @LethiferousMoose's original issue is the PSScriptAnalyzer issue that @rjmholt mentioned, and the issue @AlexBillon07 is having is tracked with #3

If you see otherwise, feel free to drop a message here!