Community version conflicts with Azure 'Az' module

Is anyone else seeing this?

Latest version of powershell core. Within VSCode it loads some commandlets from universal dashboard but fails to export the commandlets New-UDEndpoint and Start-UDRestApi.

i got used to this and was working them through a powershell session outside of VSCode but now all of a sudden i cant import the module while the Azure Az (new az version of the AzureRM) module is imported. all sorts of errors happening as it tries to import.

Has anyone else got problems with Az module imported within the same runspace as UniversalDashboard.Community? or can anyone confirm it is working ok for them ?

Thanks

Can you show the errors you are seeing?

Hi @adam :slight_smile:

Importing UnversalDashboard.Community first it will load with no problems. You then import Az and most error messages are saying ‘Assembly with same name is already loaded’

If you import Az first, then again it imports correctly. you then import UniversalDashboard.Community and it errors (one error this time not multiple like above):

Import-Module : Could not load file or assembly 'Microsoft.Extensions.Caching.Ab
stractions, Version=2.1.2.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.
Could not find or load a specific file. (Exception from HRESULT: 0x80131621)
At C:\Program Files\PowerShell\Modules\UniversalDashboard.Community\2.1.0\Univer
salDashboard.psm1:2 char:2
+     Import-Module -Name "$PSScriptRoot/netstandard2.0/UniversalDashbo ...
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [Import-Module], FileLoadException
+ FullyQualifiedErrorId : System.IO.FileLoadException,Microsoft.PowerShell.Comma
nds.ImportModuleCommand

Ah, yeah. It’s likely because the Az module uses the same assemblies but different versions and they are conflicting.

You might be able to work around this by out-of-procing calls to the Az module. You can do this by using something like Start-Job and then call the Az module in the job and then using Receive-Job to return the result back to UD.

It’s not ideal and there likely should be a better way to handle this built into UD.

currently working through this issue myself. I think ive got a difference in that ive seen this on windows and Raspbian, PS Core 6.2, UD full edition with versions of 2.3.2 (and 2.4)
Script requires UniversalDashboard and Az.Resources.
Get-UDDashboard and Start-UDDashboard are the commands that error for me.

Get-UDDashboard : The term 'Get-UDDashboard' is not recognized as the name of a cmdlet, 
function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try 
again.
At /home/pi/Source/Metrics/Environments.ps1:7 char:15
+ $Dashboards = Get-UDDashboard
+               ~~~~~~~~~~~~~~~
+ CategoryInfo          : ObjectNotFound: (Get-UDDashboard:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException