Open IsraelOrosMsft opened 8 months ago
According to Israel's findings and our investigation, this is a conflict of the Azure.Core assembly that both SqlServer and Az.Accounts depend on. Both products handles the AssemblyResolve event to redirect the assembly binding. Whichever module gets loaded first has the higher priority for the binding and would shadow the other one.
There hasn't been a perfect solution to this problem on Windows PowerShell, but on PowerShell 7, the Azure.Core assembly is loaded in a custom AssemblyLoadContext and hence isolated from other modules, so this issue won't happen.
If this is an assembly conflict, this workaround solution may work but would need to be adjusted for the particular conflicting assembly and versions. There is instruction on seeing that listed: https://github.com/Azure/azure-powershell/issues/21960#issuecomment-1938831513
If it's newtonsoft.json which is very commonly the conflicting assembly, you can redirect it to use new versions with an app.config per my post linked above.
Description
I am having issues identifying the root cause of the Connect-AzAccount : Entry point was not found error in my system. The behavior of the Connect-AzAccount cmdlet is completely inconsistent. For example, I can open a Windows PowerShell ISE window and run the cmdlet and it runs perfectly. But if I open a new Windows PowerShell ISE window, the cmdlet will fail with the Entry point was not found error. Same script, just run in two different instances of the PowerShell ISE process. I can even run the exact same script simultaneously on both sessions and one of them will fail and the other succeed.
Issue script & Debug output
Environment data
Module versions
Error output