Not able to connect to Azure with Az.Accounts version 2.12.3 (get_SerializationSettings) from within Visual studio code / Azure Automation runbook on Hybrid Worker

[mrvdsah]

Description

With the latest version of Az.Accounts version 2.12.3 we face an issue when running the Connect-AzAccount command in PowerShell 5.1.3 terminal in Visual Studio code. The previous version(s) 2.12.2 did not throw an error.

The error occurs with fully installed AZ module latest version 10.0.0.0 or only having the Az.Accounts module installed.

Issue script & Debug output

Connect-AzAccount : Method 'get_SerializationSettings' in type 'Microsoft.Azure.Management.Internal.Resources.ResourceManagementClient' from assembly 'Microsoft.Azure.PowerShell.Clients.Reso
urceManager, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' does not have an implementation.
At line:1 char:1
+ Connect-AzAccount
+ ~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Connect-AzAccount], TypeLoadException
    + FullyQualifiedErrorId : System.TypeLoadException,Microsoft.Azure.Commands.Profile.ConnectAzureRmAccountCommand

Environment data

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

Module versions

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Script     2.12.3     Az.Accounts                         {Add-AzEnvironment, Clear-AzConfig, Clear-AzContext, Clear-AzDefault...}

Error output

Resolve-AzError : Method 'get_SerializationSettings' in type 'Microsoft.Azure.Management.Internal.Resources.ResourceManagementClient' from assembly 'Microsoft.Azure.PowerShell.Clients.ResourceManager, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=31bf3856ad364e35' does not have an implementation.
At line:1 char:1
+ Resolve-AzError
+ ~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Resolve-AzError], TypeLoadException
    + FullyQualifiedErrorId : System.TypeLoadException,Microsoft.Azure.Commands.Profile.Errors.ResolveError

[BartDecker]

Can confirm. Have the same problem.

[Poolshark314]

Same here

[flizzer]

Ditto...

[jdarre]

Same here. It fails i Terminal as well
Name Value

---

PSVersion 5.1.22621.963
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.22621.963
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

[isra-fel]

Hi thanks for reporting. We are aware of this compatibility issue and are working with PowerShell to get it fixed. Let me summarize the problem here:

Symptom

The Windows PowerShell 5.1 terminal provided by the PowerShell VS Code extension cannot import Az.Resources v6.6.1. The error you receive is: "Register-AzModule : The type initializer for 'Microsoft.Azure.Commands.Common.AzModule' threw an exception".

Root cause

The Windows PowerShell 5.1 runtime preloads the PowerShellEditorServices module, which depends on Newtonsoft.Json 11.0. This issue is similar to one that caused a conflict with Az.Accounts.

Workarounds

• Use PowerShell 7 instead of Windows PowerShell 5.1.
  • Install PowerShell 7
  • Go to the command palette of VS Code (F1 or Ctrl + Shift + P), select: "PowerShell: Show Session Menu" and then select: "Switch to: PowerShell (x64)"
• Downgrade Az modules (Az.Accounts v2.12.1, Az.Resources v6.6.0)
• Use the Windows PowerShell console or ISE installed on your system

Solution

We have contacted the team who maintains the PowerShellEditorServices module for an update of the library. According to them, it is inherited from the OmniSharp library that provides our LSP layer. We are in the process of following up with Omnisharp, which is part of .NET foundation.

[axdko]

Workarounds

• Use PowerShell 7 instead of Windows PowerShell 5.1.

  • Install PowerShell 7
  • Go to the command palette of VS Code (F1 or Ctrl + Shift + P), select: "PowerShell: Show Session Menu" and then select: "Switch to: PowerShell (x64)"

Is it possible that it doesn't work in PS7 ?

Name	Value
PSVersion	7.3.4
PSEdition	Core
GitCommitId	7.3.4
OS	Microsoft Windows 10.0.22621
Platform	Win32NT
PSCompatibleVersions	{1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion	2.3
SerializationVersion	1.1.0.1
WSManStackVersion	3.0

I had to downgrade the two mentioned Az modules (Az.Accounts v2.12.1, Az.Resources v6.6.0) to make it work.

[mrvdsah]

Can't wait to upgrade to PowerShell 7.0 to leave the nightmare of the newtonsoft dll. See as well https://learn.microsoft.com/en-us/powershell/scripting/dev-cross-plat/resolving-dependency-conflicts?view=powershell-7.3.

However Azure Automation only support 5.1 for production. PowerShell > 7.1 is already for I think over 1 year in preview (so we cannot switch to core because of it being in preview still).

As well as some M365 power shell libraries are not compatible yet with PowerShell core.

[ElSrJuez]

Not a VSCode only issue:
Also happens with Azure Automation runbook on Hybrid Worker (WS2K22), latest Az Module installed.

[rbeltman]

Not a VSCode only issue: Also happens with Azure Automation runbook on Hybrid Worker (WS2K22), latest Az Module installed.

Note that because of the retiring run as accounts this should be the replacement. Downgrading to a earlier version does not seem a very stable mitigation. I also noticed that a brand new Automation account is leveraged with a lower version "out of the box" which is not returned after getting the module through the gallery.

[alvindutt]

I am also facing the same issue using Automation Account runbooks with PS version 5.

[danilomsousa]

I did the install of Powershell 7 and also Downgrade Az modules but now I'm facing a different issue. Somebody could help me please?

Bug running a powershell script as Administrator on Powershell 7
Connect-AzAccount: C:\Nebula\Configuration\Scripts\Meridian\ImportSSLCertificate.ps1:21 Line | 21 | Connect-AzAccount -ServicePrincipal -Tenant $BootstrapConfig.AzureTen … | ~~~~~~~~~~~~~~~~~ | The 'Connect-AzAccount' command was found in the module 'Az.Accounts', but the module could not be loaded due to | the following error: [Assembly with same name is already loaded] For more information, run 'Import-Module | Az.Accounts'.

Import-Module
PS C:\Nebula\Configuration\Scripts> Import-Module Az.Accounts Import-Module: Assembly with same name is already loaded

Modules

PS C:\Nebula\Configuration\Scripts> Get-Module -listavailable
    Directory: C:\Users\default.vm\Documents\PowerShell\Modules
ModuleType Version    PreRelease Name                                PSEdition ExportedCommands
---------- -------    ---------- ----                                --------- ----------------
Script     2.12.1                Az.Accounts                         Core,Desk {Disable-AzDataCollection, Disable-AzCo…
Script     5.7.1                 Az.Compute                          Core,Desk {Remove-AzAvailabilitySet, Get-AzAvaila…
Script     4.9.2                 Az.KeyVault                         Core,Desk {Add-AzKeyVaultCertificate, Update-AzKe…
Script     6.6.0                 Az.Resources                        Core,Desk {Get-AzProviderOperation, Remove-AzRole…
Script     4.6.0                 Az.Sql                              Core,Desk {Invoke-AzSqlServerExternalGovernanceSt…
Script     5.6.0                 Az.Storage                          Core,Desk {Get-AzStorageAccount, Get-AzStorageAcc…
    Directory: C:\program files\powershell\7\Modules
ModuleType Version    PreRelease Name                                PSEdition ExportedCommands
---------- -------    ---------- ----                                --------- ----------------
Manifest   7.0.0.0               CimCmdlets                          Core      {Get-CimAssociatedInstance, Get-CimClas…
Manifest   1.2.5                 Microsoft.PowerShell.Archive        Desk      {Compress-Archive, Expand-Archive}
Manifest   7.0.0.0               Microsoft.PowerShell.Diagnostics    Core      {Get-WinEvent, New-WinEvent, Get-Counte…
Manifest   7.0.0.0               Microsoft.PowerShell.Host           Core      {Start-Transcript, Stop-Transcript}
Manifest   7.0.0.0               Microsoft.PowerShell.Management     Core      {Add-Content, Clear-Content, Get-Clipbo…
Manifest   7.0.0.0               Microsoft.PowerShell.Security       Core      {Get-Acl, Set-Acl, Get-PfxCertificate, …
Manifest   7.0.0.0               Microsoft.PowerShell.Utility        Core      {Export-Alias, Get-Alias, Import-Alias,…
Manifest   7.0.0.0               Microsoft.WSMan.Management          Core      {Disable-WSManCredSSP, Enable-WSManCred…
Script     1.4.8.1               PackageManagement                   Desk      {Find-Package, Get-Package, Get-Package…
Script     2.2.5                 PowerShellGet                       Desk      {Find-Command, Find-DSCResource, Find-M…
Script     7.0.0.0               PSDiagnostics                       Core      {Disable-PSTrace, Disable-PSWSManCombin…
Script     2.2.6                 PSReadLine                          Desk      {Get-PSReadLineKeyHandler, Set-PSReadLi…
Binary     2.0.3                 ThreadJob                           Desk      Start-ThreadJob
    Directory: C:\Program Files\WindowsPowerShell\Modules
ModuleType Version    PreRelease Name                                PSEdition ExportedCommands
---------- -------    ---------- ----                                --------- ----------------
Script     1.0.1                 Microsoft.PowerShell.Operation.Val… Desk      {Get-OperationValidation, Invoke-Operat…
Binary     1.0.0.1               PackageManagement                   Desk      {Find-Package, Get-Package, Get-Package…
Script     3.4.0                 Pester                              Desk      {Describe, Context, It, Should…}
Script     1.0.0.1               PowerShellGet                       Desk      {Install-Module, Find-Module, Save-Modu…
Script     1.2                   PSReadline                          Desk      {Get-PSReadlineKeyHandler, Set-PSReadli…
    Directory: C:\Program Files\Microsoft Monitoring Agent\Agent\PowerShell
ModuleType Version    PreRelease Name                                PSEdition ExportedCommands
---------- -------    ---------- ----                                --------- ----------------
Binary     1.0.0.0               Microsoft.MonitoringAgent.PowerShe… Desk
    Directory: C:\Program Files\Microsoft Monitoring Agent\Agent\AzureAutomation\7.3.1722.0
ModuleType Version    PreRelease Name                                PSEdition ExportedCommands
---------- -------    ---------- ----                                --------- ----------------
Binary     1.0                   HybridRegistration                  Desk
    Directory: C:\Program Files\Microsoft Monitoring Agent\Agent\AzureAutomation\7.3.1722.0\HybridAgent\Modules
ModuleType Version    PreRelease Name                                PSEdition ExportedCommands
---------- -------    ---------- ----                                --------- ----------------
Binary     1.0                   Orchestrator.AssetManagement.Cmdle… Desk      {Get-AutomationVariable, Set-Automation…

[insomniacc]

Just another +1 here, having the same issue with AutomationAccount Runbooks running on a hybrid worker VM.
Seems there's some issues with PS Core in runbooks and which are still in preview so I'm limited to running 5.1.

My only option is to use 5.1 and therefore downgrade the module, but this also causes the keyvault module to fail due to version incompatibilities so I've had to downgrade that 2x also.

[mrvdsah]

What is the latest status of this issue?

[marcoflorian]

+1 same issue here :(

Install-Module -Name MSOnline
Install-Module -Name Az.Resources
Install-Module -Name Az.Accounts

connect-msolservice 
Connect-AzAccount

PS C:\Windows\system32> Connect-AzAccount
Connect-AzAccount : Method 'get_SerializationSettings' in type 'Microsoft.Azure.Management.Internal.Resources.ResourceManagementClient' from assembly
'Microsoft.Azure.PowerShell.Clients.ResourceManager, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' does not have an implementation.
At line:1 char:1
+ Connect-AzAccount
+ ~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Connect-AzAccount], TypeLoadException
    + FullyQualifiedErrorId : System.TypeLoadException,Microsoft.Azure.Commands.Profile.ConnectAzureRmAccountCommand

[pmoisontech]

Hi,

Facing the same issue.
Spent several hours to try to have a stable dev env with Az PS in VS Code.
Any update about a fix?

[StevieLamb]

Not a VSCode only issue: Also happens with Azure Automation runbook on Hybrid Worker (WS2K22), latest Az Module installed.

We've seen this issue without using Hybrid Workers; pure Azure Automation with Managed Identity (no RunAs usage).

[StevieLamb]

Using Windows PowerShell is not a workaround.
I and a team member have reliably reproduced this issue via that mechanism.

Downgrading to Az.Accounts 2.12.1 and Az.Resources 6.6.0 also fails to resolve.

This issue gives more details on the scenarios in which I've reproduced the issue:
#9728 (comment)

Everything works in v7, but that's just not a solution when scripting for two major MSFT platforms: Endpoint Manager MDM scripts, and Azure Automation.
That runtime cannot be targeted by Intune, and is not in production in AA.

[isra-fel]

Hi, I'm glad to announce the issue was resolved, please see this comment for more information.

For maintenance purpose I'm closing this issue. If you need us to follow up on anything please reply in #21647 . Thanks.

[mark3grahams]

I am glad you solved the Azure automation issue but I am not sure why you closed this issue. This issue seems to be mostly based around the issue that was not fixed.

“And for the conflict with the vscode terminal provided by the PowerShell extension, unfortunately the issue is still there. We couldn't get response from the maintainer of OmniSharp/csharp-language-server-protocol , who we hope can update their dependency of Newtonsoft.Json hence resolve the conflict. I'll update the thread once we get any updates.”

[isra-fel]

This issue seems to be mostly based around the issue that was not fixed.

Hey @mark3grahams , yes, this issue was about vscode originally. But the conversation quickly got mixed by the other issue with Azure Automation. I closed this one purely to avoid confusion and duplication.

[KeysAU]

Also getting this issue Az.Accounts version 2.12.5, PS 5.1 windows 10 (VSCode)

[o-l-a-v]

@jpawlowski Some off topic advice / experience sharing from using Automation Account with PowerShell 7.2 for some time:

• Connect-AzAccount -Identity with system assigned managed identity randomly fails with error code Forbidden. I have a runbook that runs every 10 minutes to ingest some logs, it works > 99.9% of the time, but randomly fails. Even with retry logic to try to authenticate 5 times before crashing the runbook, giving error "Forbidden" all five attempts.
  • I've had a ticket open for this for over a month with 0 progress.
  • I've had this happened on multiple Automation Account resources, not just one.
  • I've had this happened with Az.Accounts v2.19.0 and v3.0.0. Just updated to v3.0.1, haven't had this happened yet. I don't think this is caused by the Az.Accounts module though.
• A runbook job can randomly fail to start, with final state "Suspended". What's maybe even worse is that this final event is not logged to Log Analytics if you've enabled Diagnostic Settings for said Automation Account resource.

I'm considering checking out Function Apps as a replacement. I've been a long time Automation Account user, but these reliability problems and my poor Azure support experience kind of forces me to look for something else. At least for workloads were realiability is a concern, like with log ingestion.

[jpawlowski]

@o-l-a-v, thank you for sharing these insides. Sounds like I should reevaluate to keep the PS 5.1 workarounds and compatibility in the code. I was hoping to make the code easier by removing 5.1 backwards compatibility, especially for performance and memory optimization that's really hard to achieve sometimes in PS 5.1. I still want to try it but might now be prepared to go back to PS 5.1, but at least be prepared to switch to PS 7.2 by cleaning up the child runbook dependency.

Azure Functions are not really a replacement for Azure Automation, it really depends on the specific use case. Sometimes you might even need both in combination. Azure Functions are meant to perform quick actions like within a few seconds and can give direct output back to the caller for that reason. However, it doesn't work for long-running tasks, like for user provisioning or something that requires further processing. Azure Automation has its domain and issues shall hopefully be fixed. The support experience you describe may be different when you have access to primer support, or a direct contact to the Microsoft support organization and product groups (my experience).

[ITJoeSchmo]

I provided a work-around for these persistent NewtonSoft.Json conflicts we have seen rear their head time and time again between the HybridWorker modules, Az.* Modules, Graph.* Modules, and now VSCode in my post above back in February. It became a big hassle to try to keep specific versions with missing functionalities across the board.

My team has been leveraging this workaround I came up with in a production environment for 2 different automation platforms (AzureAutomation HybridWorkers for 1, a 3rd Party Platform for the other) which both leverage PowerShell (under different executables) to work-around the NewtonSoft.Json assembly conflict.

This assembly redirection is even mentioned by Microsoft documentation here as a potential solution which I found after I had implemented it:

1. https://learn.microsoft.com/en-us/azure/automation/troubleshoot/hybrid-runbook-worker#unable-to-update-az-modules-while-using-the-hybrid-worker
2. https://learn.microsoft.com/en-us/powershell/scripting/dev-cross-plat/resolving-dependency-conflicts?view=powershell-7.4#static-binding-redirect-with-appconfig-to-force-using-the-same-dependency-version

• The only "concern" in the 2nd article for this type of solution is ".NET Core doesn't support app.config, so this solution only applies to powershell.exe (5.1)" but PowerShell Core shouldn't have this issue because it can handle assembly conflicts itself, so I don't really think it is relevant to mention?

The only quirk is some modules have to be imported in a specific order to be happy if more than 1 is used in your script:

1. Az.*
2. Graph.*
3. ExchangeOnline

I have only had to re-apply the bindingRedirect once when the app was updated and it was overwritten. I am surprised the work-around has not gotten much traction since I have shared...

Today I tested this with the VSCode conflict by adding the redirect to the powershell.exe.config file located @ "$PSHOME\powershell.exe.config" and it does also resolve this issue. I decided to write up a script to allow others to easily patch their own app.config file and insert the same redirection without having to do so manually. Find that script here

The script will back up the current configuration file to $ENV:temp, take ownership and grant your user FullControl, then insert the XML into the config, then rollback the ownership/permissions. After that you should be NewtonSoft.Json-assembly-conflict-free in new PowerShell sessions.

Here is what to expect to see when running the PS1:

Afterwards I started a new PowerShell Extension session in VSCode, Ran Import-Module Az.Accounts, and connected without issue as you can see here:

DISCLAIMER:
This script is provided "as is" without warranty of any kind, express or implied. Use this script at your own risk.
While this solution has been leveraged in a PRODUCTION capacity by my team for >5 months without issue, the author and contributors are not responsible for any damage or issues potentially caused by the use of this script.
Always test scripts in a non-production environment before deploying them into a production setting.

[jpawlowski]

I provided a work-around for these persistent NewtonSoft.Json conflicts we have seen rear their head time and time again between the HybridWorker modules, Az.* Modules, Graph.* Modules, and now VSCode in my post above back in February.

This workaround only helps if you don't want to do fancy serverless things, which I think is what most people want to do nowadays (if there is no on-prem dependency).

I've not been using hybrid workers intensively but wonder why people would still stick with Windows PowerShell on it. I'd be curious to learn more should you be willing to share some aspects.

For local issues on the workstation, it is just becoming too cumbersome and complicated to fix good old PowerShell 5.1. Microsoft has clearly moved on and doesn't care about PS 5.1 anymore; it is just that they can't remove it as a default on Windows (yet). Sadly, most people are not aware of the complex situation (I've been explaining this to customers quite often within the last few months).

VSCode is designed to be used with PowerShell Core. I personally would recommend everybody to leave Windows PowerShell Desktop version behind. I know that for development of code that should still work on PowerShell 5.1, this comes with some challenges to handle the backwards compatibility. I've been able to handle this okay to be honest, and PSScriptAnalyzer can be taught to help with some warnings for backwards compatibility.

In Microsoft Land (maybe not limited to that), I do think they embraced developing inside a (Linux) devcontainer as a standard which means that you will need to use PowerShell Core. I personally also wouldn't want to go back to only local development either (or switch to a Windows PC, since I'm using a Mac for decades already).

Taking all of this into consideration, you may not expect much from anyone in Microsoft to fix stuff in any area that is still using PowerShell 5.1. Any investment is in PowerShell Core and even though nobody tells you that officially, you may assume that they often simply would like to send a reply like "move to the newest version". They will not do this as an official statement anytime soon for many reasons.

That being said, I have decided to stop making own investments (timewise and moneywise) into PowerShell 5.1, too. I know this sounds like an unpopular decision to make, but you must make that sooner or later.

... and all Microsoft SaaS related modules have now been updated in a way so they can be used in PowerShell Core and are multi-platform compatible. This was different like 2 years ago. But the situation has changed for the better in that regard and the journey of PowerShell 5.1 is about to come to a dead end.

[ITJoeSchmo]

I provided a work-around for these persistent NewtonSoft.Json conflicts we have seen rear their head time and time again between the HybridWorker modules, Az.* Modules, Graph.* Modules, and now VSCode in my post above back in February.

This workaround only helps if you don't want to do fancy serverless things, which I think is what most people want to do nowadays (if there is no on-prem dependency).

I've not been using hybrid workers intensively but wonder why people would still stick with Windows PowerShell on it. I'd be curious to learn more should you be willing to share some aspects.

For local issues on the workstation, it is just becoming too cumbersome and complicated to fix good old PowerShell 5.1. Microsoft has clearly moved on and doesn't care about PS 5.1 anymore; it is just that they can't remove it as a default on Windows (yet). Sadly, most people are not aware of the complex situation (I've been explaining this to customers quite often within the last few months).

VSCode is designed to be used with PowerShell Core. I personally would recommend everybody to leave Windows PowerShell Desktop version behind. I know that for development of code that should still work on PowerShell 5.1, this comes with some challenges to handle the backwards compatibility. I've been able to handle this okay to be honest, and PSScriptAnalyzer can be taught to help with some warnings for backwards compatibility.

In Microsoft Land (maybe not limited to that), I do think they embraced developing inside a (Linux) devcontainer as a standard which means that you will need to use PowerShell Core. I personally also wouldn't want to go back to only local development either (or switch to a Windows PC, since I'm using a Mac for decades already).

Taking all of this into consideration, you may not expect much from anyone in Microsoft to fix stuff in any area that is still using PowerShell 5.1. Any investment is in PowerShell Core and even though nobody tells you that officially, you may assume that they often simply would like to send a reply like "move to the newest version". They will not do this as an official statement anytime soon for many reasons.

That being said, I have decided to stop making own investments (timewise and moneywise) into PowerShell 5.1, too. I know this sounds like an unpopular decision to make, but you must make that sooner or later.

... and all Microsoft SaaS related modules have now been updated in a way so they can be used in PowerShell Core and are multi-platform compatible. This was different like 2 years ago. But the situation has changed for the better in that regard and the journey of PowerShell 5.1 is about to come to a dead end.

I totally agree with everything you've said here. The serverless aspect makes sense as this wouldn't be applicable.

I've been slowly adjusting all our automation to be compatible with PowerShell Core. Right now a lot of our runbooks dot-source other run books. I'm working on turning some of those children runbooks into functions in a module, and making other children runbooks use basic variables over complex ones so we can leverage start-azautomationrunbook. Anything new I've written I make sure is written in a way that can be used with PowerShell Core.

One problem is I don't think our 3rd party automation platform has the option of using Core, but with 5.1 EOS coming up in a few years I'm sure that will change as well.

Our goal is to use Core for sure. Unfortunately we don't have the resources to make the migration our #1 priority but it is something we are iterating towards.

[MrFly72]

So there is the upcomming breaking change:

2024-07-17T05:19:22.978 [Warning] WARNING: Upcoming breaking changes in the cmdlet 'Get-AzAccessToken' :The Token property of the output type will be changed from String to SecureString. Add the [-AsSecureString] switch to avoid the impact of this upcoming breaking change.- The change is expected to take effect in Az version : '13.0.0'- The change is expected to take effect in Az.Accounts version : '4.0.0'Note : Go to https://aka.ms/azps-changewarnings for steps to suppress this breaking change warning, and other information on breaking changes in Azure PowerShell.

And this case is still valid for me in VSCode, which still trows the error on Connect-AZAccount when using 3.0.2 of AZ Accounts.

[Clawz2k]

Was getting the same error for couple of months and finally got time to have a closer look.
Downgrade the packages to the below list and haven't had an failure for the past 3 days. Usually I get at least 1 failed per day.
Az.Accounts 2.12.1
Az.Resources 6.5.3
Az.Storage 5.4.1
AzTable 2.1.0

[MrFly72]

This is not a good solution anymore, as AZ.Accounts will have a breaking change soon.
Its really a pain that nobody takes care of this for such a long time ....

[michaelmsonne]

Can't agree more - but I'm trying to push here with my contacts at Microsoft and the team behind - stay tuned!

[MrFly72]

Any news on this?
Somebody again upgraded the AZ.Accounts, as he needed a new module on a server and now again VSCode is broken in PS5.1 (not in 7.x). But i need to test backward compatibility as people in my teams usually dont use PS7.
This is a nightmare Microsoft!!!

[Alex-wdy]

#26206 Related issues

[MrFly72]

This is still open even after the latest update:

This definitely needs somebody to have a look at it!
This is BLOCKING any debugging of AZ-Driven Code in VSCode with PS5.1!!!!

[mark3grahams]

Can't agree more - but I'm trying to push here with my contacts at Microsoft and the team behind - stay tuned!

@michaelmsonne Do you have an update?

[michaelmsonne]

Can't agree more - but I'm trying to push here with my contacts at Microsoft and the team behind - stay tuned!

@michaelmsonne Do you have an update?

I have pinged the team at Microsoft yesterday again, in my Teams chat I have...
Not any updates after 10 oct..

[MrFly72]

I also opened my MS connections last week as this is getting more and more a problem in our enterprise environment. (250000 employees, our service completely on azure)

[michaelmsonne]

Update from my contacts:

"We will update the issue progress on the GitHub issue tomorrow to facilitate everyone to know the progress".

The issue is a bit tricky as I can understand on the team. The team is currently considering how to decouple these tricky issues.

Lets see tomorrow!

[Alex-wdy]

Update from my contacts:

"We will update the issue progress on the GitHub issue tomorrow to facilitate everyone to know the progress".

The issue is a bit tricky as I can understand on the team. The team is currently considering how to decouple these tricky issues.

Lets see tomorrow!

The reply is a bit late because the engineers are dealing with some urgent issues. I look forward to @isra-fel giving a progress reply soon.

[isra-fel]

I was investigating in the issue with vscode, the one thing that's super suspicious is this error in the fusion log (full version).

WRN: The same assembly was loaded into multiple contexts of an application domain:
WRN: Context: LoadFrom | Domain ID: 1 | Assembly Name: Newtonsoft.Json, Version=13.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
WRN: Context: Neither | Domain ID: 1 | Assembly Name: Newtonsoft.Json, Version=13.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
WRN: This might lead to runtime failures.
WRN: It is recommended to inspect your application on whether this is intentional or not.
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.

The log was captured when Az.Accounts was imported to the integrated terminal. It showed the process of binding Newtonsoft.Json and a bunch of warnings about The same assembly was loaded into multiple contexts of an application domain. I'm not very experienced in the low-levels of .NETFramework runtime, but at least the warnings were clear that This might lead to runtime failures.

My assumption is that the two assemblies in the fusion log are these two from the preloaded modules PSScriptAnalyzer and PowerShellEditorServices.

PS C:\> pasm json | fl
FullName            : Newtonsoft.Json, Version=13.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
Location            : C:\Users\yeliu\.vscode\extensions\ms-vscode.powershell-2024.4.0\modules\PSScriptAnalyzer\1.23.0\Newtonsoft. 
                      Json.dll
AssemblyFileVersion : 13.0.3.27908
TargetFramework     : .NETFramework,Version=v4.5

FullName            : Newtonsoft.Json, Version=13.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
Location            : C:\Users\yeliu\.vscode\extensions\ms-vscode.powershell-2024.4.0\modules\PowerShellEditorServices\bin\Common
                      \Newtonsoft.Json.dll
AssemblyFileVersion : 13.0.3.27908
TargetFramework     : .NETStandard,Version=v2.0

pasm: https://gist.github.com/isra-fel/0c503fbccbf301e8c42135dfa47e4408

These are my findings for now.

[MrFly72]

@isra-fel hank you for looking deeper into it. Very appreciated that someone now starts to really look into this issue to get it fixed.

[Alex-wdy]

@isra-fel hank you for looking deeper into it. Very appreciated that someone now starts to really look into this issue to get it fixed.

We plan to update every two weeks or monthly, although we may not be able to give an ETA

[michaelmsonne]

@isra-fel hank you for looking deeper into it. Very appreciated that someone now starts to really look into this issue to get it fixed.

We plan to update every two weeks or monthly, although we may not be able to give an ETA

Hi @Alex-wdy ,

Is ther any updates the last month or? This is a very bad bug på deal with all the time :(

[MrFly72]

Hey, we really need an update to this! This is not tolerable and keeps us back in everyday work!

[Division-Bell]

This consistency MS manage with screwing these Az PS modules up is impressive.

[mark3grahams]

They are never fixing this. The heat death of the universe will come quicker.

[isra-fel]

OK so from the author of the PowerShell extension's perspective

Our recommendation is to author your PS 5.1 scripts in PS7. PS5.1 is only best effort supported in the vscode extension per the readme.

I will conclude this issue as below - it's a limitation of PS 5.1 that there's no solution for assembly isolation. The known workarounds are

1. Open the PowerShell session menu and switch to PowerShell 7 (Recommend)
2. Run the scripts in a standalone PowerShell exe - hence PowerShell language service and PowerShell script analyzer are not loaded