Bug: Assembly with same name is already loaded

[Gill-Bates]

When using Az.KeyVault in Combination with Send-MailKiTMessage the command Import-Module throws:

Import-Module: C:\Temp\d5plgr21.aue\484853eb-9c26-4659-ac55-ff53e9138976.ps1:2
Line |
   2 |  Import-Module Az.Keyvault
     |  ~~~~~~~~~~~~~~~~~~~~~~~~~
     | Assembly with same name is already loaded

Tested with PS 7.1, 7.2 and with latest Module Versions.

[o-o00o-o]

Yes we are having this problem as well. It was exposed by us using the Microsoft.Powershell.SecretManagement library and registering a KeyVault and when we use Get-Secret it throws Assembly with same name is already loaded

Full repro with output with -verbose here

import-module az.keyvault
import-module Send-MailKitMessage -verbose

Import-Module:
VERBOSE: Loading module from path 'C:\Users\blah\OneDrive\Documents\PowerShell\Modules\Send-MailKitMessage\3.1.0\Send-MailKitMessage.psd1'.
VERBOSE: Loading 'Assembly' from path 'C:\Users\blah\OneDrive\Documents\PowerShell\Modules\Send-MailKitMessage\3.1.0\Libraries\BouncyCastle.Crypto.dll'.
VERBOSE: Loading 'Executable' from path 'C:\Users\blah\OneDrive\Documents\PowerShell\Modules\Send-MailKitMessage\3.1.0\Libraries\BouncyCastle.Crypto.dll'.
VERBOSE: Loading 'Assembly' from path 'C:\Users\blah\OneDrive\Documents\PowerShell\Modules\Send-MailKitMessage\3.1.0\Libraries\MailKit.dll'.
VERBOSE: Loading 'Executable' from path 'C:\Users\blah\OneDrive\Documents\PowerShell\Modules\Send-MailKitMessage\3.1.0\Libraries\MailKit.dll'.
VERBOSE: Loading 'Assembly' from path 'C:\Users\blah\OneDrive\Documents\PowerShell\Modules\Send-MailKitMessage\3.1.0\Libraries\MimeKit.dll'.
VERBOSE: Loading 'Executable' from path 'C:\Users\blah\OneDrive\Documents\PowerShell\Modules\Send-MailKitMessage\3.1.0\Libraries\MimeKit.dll'.
import-module :
PSMessageDetails      :
Exception             : System.IO.FileLoadException: Assembly with same name is already loaded
                           at System.Management.Automation.Runspaces.InitialSessionState.Bind_LoadAssemblies(ExecutionContext context)
                           at System.Management.Automation.Runspaces.InitialSessionState.Bind(ExecutionContext context, Boolean updateOnly, PSModuleInfo module, Boolean noClobber, Boolean local, Boolean setLocation)
                           at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModuleManifest(String moduleManifestPath, ExternalScriptInfo manifestScriptInfo, Hashtable data, Hashtable localizedData, ManifestProcessingFlags manifestProcessingFlags, Version minimumVersion, Version maximumVersion, Version requiredVersion, Nullable`1 requiredModuleGuid, ImportModuleOptions& options, Boolean& containedErrors)
TargetObject          :
CategoryInfo          : InvalidOperation: (:) [Import-Module], FileLoadException
FullyQualifiedErrorId : FormatXmlUpdateException,Microsoft.PowerShell.Commands.ImportModuleCommand
ErrorDetails          :
InvocationInfo        : System.Management.Automation.InvocationInfo
ScriptStackTrace      : at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo : {0, 1}

Secrets ultimately more vital than email so we will have to turn off the email features until this is resolved or find an alternative email sending method :(

[o-o00o-o]

Unfortunately I think the problem is ultimately this

https://devblogs.microsoft.com/powershell/resolving-powershell-module-assembly-dependency-conflicts/

In our case I'm going to try using the job system to send the emails using Send-MailKitMessage via a separate job and where we use the [MimeKit.InternetAddressList]::Parse - we just check Get-Assembly first before calling it and only Import-Module Send-MailkitMessage if it isn't there

[austineric]

Hi @Gill-Bates and @o-o00o-o,
Thanks for identitying this.

@o-o00o-o I would agree, I think that will be the way to resolve. In fact in 3.2.0-preview1 where Windows PowerShell support is added I had to use that exact approach to resolve another conflict:

Send-MailKitMessage/Project/Send_MailKitMessage.cs

Line 16 in eef9fc1

//so per https://devblogs.microsoft.com/powershell/resolving-powershell-module-assembly-dependency-conflicts/ I am using an AssemblyResolve event handler to create a dynamic binding redirect so all calls to System.Buffers use the same assembly

I'll see if I can get an updated version out shortly.

[DarkLite1]

Has this been fixed in the meantime? Is the project still maintained?

[austineric]

Hi @DarkLite1,
No this has not been fixed yet, and yes the project is still maintained as time allows :)