VS Code Integrated Terminal issue loading Azure DLL

Hello, I have some info that I wanted to share in case it’s pointing to a bigger issue.

I’ve experienced, and we’ve had several people report (GH, Twitter, Slack) that, certain DLLs will not load in the Integrated Shell.

This loading works in all other environments (ISE, powershell.exe).

System.Exception: Could not load file or assembly 'Microsoft.Azure.Services.AppAuthentication' or one of its dependencies. The system cannot find the file specified. ---> System.Exception: 
                        Could not load file or assembly 'Microsoft.Azure.Services.AppAuthentication' or one of its dependencies. The system cannot find the file specified. ---> 
                        System.Management.Automation.MethodInvocationException: Exception calling "Open" with "0" argument(s): "The type initializer for 'System.Data.SqlClient.SqlAuthenticationProviderManager' threw 
                        an exception." ---> System.TypeInitializationException: The type initializer for 'System.Data.SqlClient.SqlAuthenticationProviderManager' threw an exception. ---> System.ArgumentException: 
                        Failed to instantiate an authentication provider with type 'Microsoft.Azure.Services.AppAuthentication.SqlAppAuthenticationProvider, Microsoft.Azure.Services.AppAuthentication' for 
                        'ActiveDirectoryInteractive'. ---> System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Azure.Services.AppAuthentication' or one of its dependencies. The system cannot 
                        find the file specified.                    

Then later

Could not load file or assembly 'Microsoft.Azure.Services.AppAuthentication' or one of its dependencies. The system cannot find the file specified

I “fixed” my issue by uninstalling Insiders and installing Stable, but people have reported experiencing this issue in both versions. If a Code instance is broken, the import is always broken. But if the Code instance is not broken, it consistently works.

I believe the Code breaks in this code block:

 if ((Get-ItemProperty "HKLM:SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full").Release -ge 461808) {
        Write-Verbose -Message "Loading app.config"
        # Load app.config that supports MFA
        $configpath = "$script:PSModuleRoot\bin\app.config"
        [appdomain]::CurrentDomain.SetData("APP_CONFIG_FILE", $configpath)
        Add-Type -AssemblyName System.Configuration
        # Clear some cache to make sure it loads
        [Configuration.ConfigurationManager].GetField("s_initState", "NonPublic, Static").SetValue($null, 0)
        [Configuration.ConfigurationManager].GetField("s_configSystem", "NonPublic, Static").SetValue($null, $null)
        ([Configuration.ConfigurationManager].Assembly.GetTypes() | Where-Object {$_.FullName -eq "System.Configuration.ClientConfigPaths"})[0].GetField("s_current", "NonPublic, Static").SetValue($null, $null)
    }

I don’t know if that is helpful to you at all.

@garethnewman was able to give me some good info from his broken instance:

Environment Information

Visual Studio Code

Name	Version
Operating System	Windows_NT x64 6.3.9600
VSCode	1.36.0-insider
PowerShell Extension Version	2019.5.0
PowerShell Information

---

Name	Value
PSVersion	5.1.14409.1018
PSEdition	Desktop
PSCompatibleVersions	1.0 2.0 3.0 4.0 5.0 5.1.14409.1018
BuildVersion	10.0.14409.1018
CLRVersion	4.0.30319.42000
WSManStackVersion	3.0
PSRemotingProtocolVersion	2.3
SerializationVersion	1.1.0.1
Visual Studio Code Extensions

---

Visual Studio Code Extensions(Click to Expand)

|Extension|Author|Version| |---|---|---| |powershell|ms-vscode|2019.5.0| |search|dbatools|1.1.3| |team|ms-vsts|1.149.2|;

For now, we are getting around it basically by not supporting the new functionality, much like we do Core 💔

if ($psVersionTable.Platform -ne 'Unix' -and $PSVersionTable.PSEdition -ne 'Core' -and $host.Name -ne 'Visual Studio Code Host') {

[flagmanchris]

Thanks, just sent it through (onedrive link)

[daxian-dbw]

Two suspicious things I observed:

1. The logs shown in the FunsionLogs you shared indicate the successful binding was triggered by Assembly.LoadFrom, whereas the _fusionLog field in WinDbg indicates the loading was triggered by Assembly.Load with a partial assembly name Microsoft.Azure.Services.AppAuthentication.

2. The exception thrown from System_Data_ni!System.Data.SqlClient.SqlAuthenticationProviderManager..ctor(System.Data.SqlClient.SqlAuthenticationProviderConfigurationSection) shows an error message: Failed to instantiate an authentication provider with type 'Microsoft.Azure.Services.AppAuthentication.SqlAppAuthenticationProvider, Microsoft.Azure.Services.AppAuthentication' for 'ActiveDirectoryInteractive'.. Note the type name used – Microsoft.Azure.Services.AppAuthentication.SqlAppAuthenticationProvider, Microsoft.Azure.Services.AppAuthentication. It’s explicitly using an incomplete assembly-qualified name.

---

I looked at the disassembled code of System_Data_ni!System.Data.SqlClient.SqlAuthenticationProviderManager in System.Data.dll. The load exception should happen at here:

try
{
    this._initializer = (SqlAuthenticationInitializer) Activator.CreateInstance(Type.GetType(configSection.InitializerType, true));
    this._initializer.Initialize();
}
catch (Exception ex)
{
    throw SQL.CannotCreateSqlAuthInitializer(configSection.InitializerType, ex);
}

configSection seems coming from a configuration file. Maybe you want to look into the config file to see if the use of an incomplete assembly-qualified type name is intentional.

section = (SqlAuthenticationProviderConfigurationSection) ConfigurationManager.GetSection("SqlAuthenticationProviders");

---

@flagmanchris is the assembly Microsoft.Azure.Services.AppAuthentication.dll shipped with dbatools module at dbatools\bin\libraries\Microsoft.Azure.Services.AppAuthentication.dll? The loading failure was triggered by Assembly.Load("Microsoft.Azure.Services.AppAuthentication"). Assembly.Load will never probe the module folder, so it won’t find the assembly unless the assembly was already loaded by Assembly.LoadFrom, which sort of conforms to the successful fusion logs you shared. Therefore, I think our investigation should shift a bit to see whether this assembly is supposed to be loaded before hitting this code path (via module manifest or etc.), and why that doesn’t happen when running in the integrated console.