Request for PowerShell to do something about the modules assembly conflict situation #24365
Replies: 1 comment
-
On the positive side, it is easier to support AssemblyLoadContext in PowerShell 7 than in 5. First a developer has to be convinced to leave Currently the only gate-keeper of the PSGallery is Publish-Module itself which does perform validation appropriate for PowerShell, however it is not compulsory. I don't see the Gallery becoming a gated community, I think that would be the slippery-slope if there were additional hurdles for developers to publish packages, at least they don't (currently) need code signing certificates. I don't see |
Beta Was this translation helpful? Give feedback.
-
PowerShell should educate and push C# compiled PowerShell module creators and maintainers to follow best practices, like using AssemblyLoadContext to avoid assembly conflicts. More context: https://youtu.be/__J7b84BAmQ.
This is a PowerShell problem, it has a huge negative impact on using PowerShell itself. It's not just a problem with an individual module.
To get an indication on how widespread this is: Numbers of issues opened containing "could not load file or assembly" as of 2024-10-03:
Az
Microsoft.Graph
PnP.PowerShell
PSScriptAnalyzer
PowerShellEditorServices
vscode-powershell
VSCode with the
vscode-powershell
extension is the official way to author PowerShell now.vscode-powershell
also uses assembly dependecies that can conflict with assemblies used by modules, which can create issues that does not happen in a PowerShell terminal outside ofvscode-powershell
.This is not an issue
vscode-powershell
can fix from their context, like this issue (and many others like it) describes:A centralized initiative with a more forced approach should be considered IMO. I think the PowerShell project itself should do something about it. Some ideas:
Az
,ExchangeOnlineManagement
,Microsoft.Graph
andPnP.PowerShell
.Az
andvscode-powershell
.Beta Was this translation helpful? Give feedback.
All reactions