Closed prajasek-netapp closed 2 weeks ago
Hi, I suggest it is a conflict with PowerShell's version of the library. It own's the process and is likely to have loaded that first.
PS C:\Program Files\PowerShell\7> (Get-Item -LiteralPath System.ServiceModel.Primitives.dll).VersionInfo
ProductVersion FileVersion FileName
-------------- ----------- --------
3.4.3 4.1000.323.51101 C:\Program Files\PowerShell\7\System.ServiceModel.Primitives.dll
If you are just writing a script then you have a major challenge, but if you are writing a C #cmdlet then you can set up an Assembly Load Context.
The problem is a single load context can only load one version of a named shared assembly. So you can create a child load context and load your conflicting assemblies into that.
I have just just gone through this process with one of my modules, where I load the Postgres Database Connection into the child Assembly Load Context but can share objects created within that load context through my cmdlet, the Alc module is the bridging assembly that allows objects to be shared across the divide.
The assemblies within the lib directory run in the child Alc.
📣 Hey @prajasek-netapp, how did we do? We would love to hear your feedback with the link below! 🗣️
🔗 https://aka.ms/PSRepoFeedback
Thanks, it worked.
Prerequisites
Steps to reproduce
I am not able to load the module, which has System.ServiceModel.Primitives dependency.
Simply load the module in the powershell 7. Example:-
[System.Reflection.Assembly]::LoadFrom('< path to the folder contains System.ServiceModel.Primitives.dll>')
Add-Type -Path "< path to the folder contains System.ServiceModel.Primitives.dll>"
Both the commands results in Could not load file or assembly 'System.ServiceModel.Primitives, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Expected behavior
Actual behavior
Error details
Environment data
Visuals
No response