Method not found with Connect-ExchangeOnline

[dsolodow]

Prerequisites

• I have written a descriptive issue title.
• I have searched all open and closed issues to ensure it has not already been reported.
• I have read the troubleshooting guide.
• I am sure this issue is with the extension itself and does not reproduce in a standalone PowerShell instance.
• I have verified that I am using the latest version of Visual Studio Code and the PowerShell extension.
• If this is a security issue, I have read the security issue reporting guidance.

Summary

ExchangeOnlineManagement versions higher than 3.7.1 throw an error when running Connect-ExchangeOnline in VSCode:

In a standalone PowerShell instance it works as expected.

I know this is often due to extension conflicts, but I've tried this without my $profile, and with ExchangeOnlineManagement the first module loaded

PowerShell Version

PS C:\Users\dsolodow> $PSVersionTable; $host

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

Name             : Visual Studio Code Host
Version          : 2025.0.0
InstanceId       : 85e7dd7d-d758-4d7a-8e80-7cd357e152f3
UI               : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture   : en-US
CurrentUICulture : en-US
PrivateData      : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled  : True
IsRunspacePushed : False
Runspace         : System.Management.Automation.Runspaces.LocalRunspace

Visual Studio Code Version

1.100.2
848b80aeb52026648a8ff9f7c45a9b0a80641e2e
x64

Extension Version

[email protected]
[email protected]

Steps to Reproduce

connect-exchangeonline

Visuals

Logs

PowerShell Trace LSP.log
PowerShell.log
StartEditorServices-24980.log

[JustinGrote]

Please use PowerShell 7, or ensure that ExchangeOnlineManagement is the first module you load (disable anything in your profile). This is an assembly loading problem with the module itself, there's nothing we can do to fix this.

[dsolodow]

I should probably have made this more apparent in my original post but I still got the error with my $profile disabled and ExchangeOnlineManagement as the first module loaded.

[JustinGrote]

Again, strongly recommend using PowerShell 7 in the PowerShell Extension terminal to avoid this problem, is there a strong reason why you aren't?

This happens because the Microsoft.Identity.Client you have loaded (provided by exchange or something else) is not the version that your ExchangeOnlineManagement expects, and is missing a method it's looking for.

Try running this to find where that DLL is loading from after you get this error:

[System.AppDomain]::CurrentDomain.GetAssemblies() | where fullname -like 'Microsoft.Identity.Client*' |% location

[dsolodow]

Unfortunately we have some internally created scripts/modules that need to be updated for PS7.

It looks like it's getting extra copies from dbatools.library and Microsoft.Graph.Authentication, but those modules aren't loaded:

When I fired up procmon and tested with powershell.exe directly, it only looks for that file under the module directory:

However, when importing the module from the VSCode Integrated Terminal, it's looking in the rest of the module directories for that file.

I did just find something interesting though; if instead of just doing

import-module exchangeonlinemanagement

I instead give it the full path of the ExchangeOnlineManagement.psd1 file, it doesn't go looking elsewhere for that file, and the module behaves as expected.

[JustinGrote]

The vscode extension may dynamically load modules based on your intellisense, so if loading exchangeonlinemanagement is not the first thing you do, and I mean very first, then you may have this problem. PowerShell 7 avoids this with ALCs, and there's no reason you can't use PowerSHell 7 to author PowerShell 5.1 scripts, so I again would strongly recommend you install PowerShell 7 on your dev box to write the scripts, and then you can test them in PowerShell 5.1 as well if needed, as PowerShell 5.1 is only best-effort supported. Hope that helps!