Trouble importing Msal.Ps module in Integrated Environment

Seem to have hit a snag with the Integrated Environment on my App Service PSU - it doesn’t want to load the Msal.Ps module.

Importing it under the Windows Powershell 5.1 Environment throws a couple of “type name not found” errors if I leave debug logs on but loads and works fine - but really I want to use Integrated so I can set cache variables for my dashboards from scheduled scripts.

Trying to import it under Integrated, I get the following error and dashboards refuse to start - anyone else seen this?

Could not load file or assembly 'Microsoft.Identity.Client, Version=4.37.0.0, Culture=neutral, PublicKeyToken=0a613f4dd989e8ae'. at System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable input) at System.Management.Automation.PowerShell.Worker.ConstructPipelineAndDoWork(Runspace rs, Boolean performSyncInvoke) at System.Management.Automation.PowerShell.Worker.CreateRunspaceIfNeededAndDoWork(Runspace rsToUse, Boolean isSync) at System.Management.Automation.PowerShell.CoreInvokeHelper[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings) at System.Management.Automation.PowerShell.CoreInvoke[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings) at System.Management.Automation.PowerShell.Invoke(IEnumerable input, PSInvocationSettings settings) at System.Management.Automation.Runspaces.InitialSessionState.ProcessOneModule(Runspace initializedRunspace, String name, PSModuleInfo moduleInfoToLoad, String path, HashSet`1 publicCommands) at System.Management.Automation.Runspaces.InitialSessionState.ProcessModulesToImport(Runspace initializedRunspace, IEnumerable moduleList, String path, HashSet`1 publicCommands, HashSet`1 unresolvedCmdsToExpose) at System.Management.Automation.Runspaces.InitialSessionState.BindRunspace(Runspace initializedRunspace, PSTraceSource runspaceInitTracer) at System.Management.Automation.Runspaces.LocalRunspace.DoOpenHelper() at System.Management.Automation.Runspaces.RunspaceBase.CoreOpen(Boolean syncCall) at UniversalAutomation.Host.JobService.ExecuteScript(executeScriptRequest request) in D:\a\universal\universal\src\Host\JobService.cs:line 70

Doesn’t just seem to be when I try to load the module that it’s having problems either - this evening after I installed the module anything running in the Integrated environment (whether it calls Msal.Ps or not) is refusing to start (scripts and dashboards) and throwing the same error.

This is likely due to an assembly conflict. My guess would be that the MSAL.PS module uses a different version of the same assembly that PSU uses.

Can you run jobs in WinPS and then use the server-wide cache rather than the $Cache scope?

That was it - a different/older version of Microsoft.Identity.Client.dll was in the root of the PSU package.

I’ve just done a rebuild injecting the version of the dll from the Msal.Ps module (4.37.0.0) - was expecting to have entirely broken PSU tbh, but it’s fixed it. Msal.Ps now loads correctly in the Integrated Environment and all my dashboards are picking up their caches. :sunglasses:

Happy to keep injecting the dll seeing as it doesn’t seem to have broken anything, but any chance that could be updated in a future release?

Sure. I’ll take a look. I checked and we don’t reference that assembly directly so something we use must.

1 Like

Not urgent since overwriting it seems to have done the trick without upsetting anything.

Would be interesting to know what component the current version came with if you do get to the bottom of it… maybe I’ve just got lucky and it’s part of a feature I’m not using.

It’s coming from the SqlClient. We can just pin to a more recent version of Microsoft.Identity.Client in 2.9.0.

image

1 Like

Ah, superb!