needs to do is to set a DllImportResolver callback for the Microsoft.Management.Infrastructure assembly upon module loading, which will then be used by the runtime to resolve the P/Invoke's from MMI to libmi/libpsrpclient

This is something that I have investigated when someone tried to get this working in Azure Cloud Shell where you don't have root access jborean93/omi#24 (comment)

Add-Type -TypeDefinition @'
using System;
using System.Collections.Generic;
using System.Reflection;
using System.Runtime.InteropServices;

namespace CloudShell
{
    public static class MI
    {
        public static Dictionary<string, string> DllMap = new Dictionary<string, string>();
        
        public static IntPtr ImportResolver(string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
        {
            if (DllMap.ContainsKey(libraryName))
                libraryName = DllMap[libraryName];

            return NativeLibrary.Load(libraryName, assembly, searchPath);
        }
    }
}
'@

$libbase = Join-Path (Import-Module -Name PSWSMan -PassThru).ModuleBase lib glibc-1.1
[CloudShell.MI]::DllMap['libpsrpclient'] = Join-Path $libBase libpsrpclient.so
[Runtime.InteropServices.NativeLibrary]::SetDllImportResolver([PSObject].Assembly, [CloudShell.MI]::ImportResolver)

While this does work and allows you to use the fork without root access and the restart there is one catch with SetDllImportResolver that makes me uncomfortable. The docs for SetDllImportResolver states that

Only one resolver can be registered per assembly. Trying to register a second resolver fails with an InvalidOperationException.

Right now there is no custom import resolver for the S.M.A assembly but I have no idea if that assumption will be true in the future. It also means that any 3rd party code that does this themselves for some reason will not be usable with this module and vice versa. I don't know whether this is really something to be concerned about but I have mostly avoided going that route because I didn't want to paint myself into a corner.

I see in your comment you are talking about setting this for the Microsoft.Management.Infrastructure assembly. I've personally not used my fork for anything in MMI, my focus was on PSRemoting over WSMan, so I couldn't even tell you if it works at all with the changes I've made. I'm not even sure when it's used in PowerShell on Linux as the CIM cmdlets aren't present. If getting MMI working is an end goal then it would mean the DLL resolver needs to be set on both S.M.A for PSRemoting over WSMan and for MMI increasing the risk of a collision in the future.

I saw in PSWSMan.psm1 that you have a set of steps to resolve which libs to be used based on the runtime/environment. That logic can be put in the DllImportResolver callback. You set the callback when the PSWSMan module is being loaded, and then unset the callback (NativeLibrary.SetDllImportResolver(wmiAssembly, null)) upon module unloading.

This is definitely possible but there are 2 wrinkles that make this complicated. The linkage between libmi and the OpenSSL libraries mostly just works but on EL7 and macOS the linked lib path essentially requires either a rewrite of the ELF headers to the correct location or a symlink to point to the proper one. I don't think this is a massive issue as essentially a symlink would be made in that directory which shouldn't be that difficult.

@jborean93, what do you think about this proposal? This will essentially make your forked omi repository the advertised "official" repo for WSMan client support in PowerShell. In fact

I'm not against the idea, I do have some concerns about SetDllImportResolver and how only 1 can be set per assembly. I know it does at least work which is great I just don't want it to break at a future point because PowerShell now adds it's own resolver for x feature.

My only other qualm is how this works from a support perspective, While I'm happy to help out when I can I cannot give any guarantees that any bugs or feature requests will be addressed at all. This is fine if this is a fork and people opt into that knowing the "risks" involved but when something comes with the "official" status that may change the expectation of the users. While I don't wish to cause any offense to anybody who works on this part of PowerShell the builtin implementation is a bit lacking and the fork should provide a better experience it's still not a 1 for 1 comparison with what Windows provides.

I see 4 potential options that are available

• Do nothing and continue the status quo
  • I don't think you can really continue with this due to the reliance on OpenSSL 1.0.x which is fast dissapearing from most distributions
• At least upgrade the builtin libmi lib with a newer one from the OMI repo that is built against OpenSSL 1.1.x
  • I think from the pwsh team's perspective this is a very quick win with very little loss
  • The PowerShell support might not be there anymore but it hasn't stopped the OMI team from producing build https://github.com/microsoft/omi/releases
  • You "should" just be able to take one of the newer ulinux builds for OpenSSL 1.1.x and ship that for distributions that on that version
  • It's essentially the same code from the same team, just compiled against a more modern OpenSSL build which is probably the worst problem with the builtin version today
• "Promote" PSWSMan as the official-ish way of using WSMan on Linux
  • Solves the OpenSSL issue as well as a whole bunch of other things mentioned in my fork
  • From my perspective the most important change is TLS certificate validation being done on HTTPS connection
  • Isn't a nice works out of the box scenario, some people may be wary about external dependencies
  • "Support" is also questionable but that probably depends on how it is documented as the "official" way
  • The TLS cert validation works but it can be difficult to trust your own CA chains, this isn't as straightforward as it would be on Windows
• Scrap all those and actually implement WSMan as a client in C#
  • This is big undertaking and I would love for it to be the case but I don't see it really happening
  • Will solve a whole bunch of issues and would simplify the whole TLS logic behind more well tested and known code that is the .NET library
  • Would also require a lot more work in PowerShell, like the pluginable transports that has been mentioned, for it to actually be possible

I know 4 is a pipe dream and I personally don't have time to work on it and the same probably also applies to anybody on the PowerShell team.

TLDR: I'm happy to investigate this further but have some concerns around limtations of SetDllImportResolver as it applies to the assembly and the perception of support that comes from the "official" status.

Regarding MMI, it's still needed on Windows for CimCmdlets, but is out of scope for this discussion. The only other thing MMI was used for on Linux/macOS was DSC configuration compilation to a mof file. Since we are no longer using MOF for DSC going forward, it is ok to break this dependency.

I would think PSWSMan would be as official as Pester. We (or CloudShell team) will try to submit PRs where it makes sense, but the community should expect "best effort GitHub based support" for PSWSMan module.

Even though we won't use SetDllImportResolver for the real implementation, but the prototype can be done using this API, so you don't need to wait for PowerShell package to stop shipping those libs (work will be needed in the Microsoft.PowerShell.Native NuGet package for that). Once it's proven to work properly, it should be easy to move the code to an event handler of AssemblyLoadContext.ResolvingUnmanagedDll.

PowerShell needs some additional changes besides removing those 2 libs -- the code path that creates a new PSSession on WSMan should detect if the required libs are available, and if not, throw the appropriate message pointing to a aka.ms link explaining how to get WSMan support through PSWSMan.

I'd like to know when it comes to Enterprises that are still paying for overdue Windows PowerShell. It looks ridiculous to put a patch on another patch. :-)

Here we are not talking about Windows PowerShell. Nothing is changed to Windows PowerShell. What do you mean by "a patch on another patch"?

We didn't get WSMan in OOB before and never will. Same with SSH. With this suggestion, we stay in the same place again, or even take a step back (well, to a side :-) ).

It's not very clear what you mean here, could you please elaborate some more?

@daxian-dbw I've had a play with this today and feel like this should work going forward

Add-Type -TypeDefinition @'
using System;
using System.Management.Automation;
using System.Reflection;
using System.Runtime.InteropServices;
using System.Runtime.Loader;

namespace PSWSMan
{
    public class Resolver : IDisposable
    {
        private static readonly string PSRP_LIB_NAME = "libpsrpclient";

        private string libPath = null;
        private IntPtr libHandle = IntPtr.Zero;

        public Resolver(string libPath, bool setPwshResolver)
        {
            this.libPath = libPath;
            AssemblyLoadContext.Default.ResolvingUnmanagedDll += ResolvePSRPClient;

            if (setPwshResolver)
            {
                try
                {
                    NativeLibrary.SetDllImportResolver(typeof(PSObject).Assembly, ImportResolver);
                }
                catch (InvalidOperationException) {}  // Only 1 resolver allowed per assembly
            }
        }

        private IntPtr ImportResolver(string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
        {
            if (libraryName == PSRP_LIB_NAME)
                return GetPSRPClientLibrary(assembly, searchPath);

            return NativeLibrary.Load(libraryName, assembly, searchPath);
        }

        private IntPtr ResolvePSRPClient(Assembly assembly, string libraryName)
        {
            if (libraryName != PSRP_LIB_NAME)
                return IntPtr.Zero;

            return GetPSRPClientLibrary(assembly, null);
        }

        private IntPtr GetPSRPClientLibrary(Assembly assembly, DllImportSearchPath? searchPath)
        {
            if (libHandle == IntPtr.Zero)
                libHandle = NativeLibrary.Load(libPath, assembly, searchPath);

            return libHandle;
        }

        public void Dispose()
        {
            if (libHandle != IntPtr.Zero)
            {
                NativeLibrary.Free(libHandle);
                libHandle = IntPtr.Zero;
            }

            AssemblyLoadContext.Default.ResolvingUnmanagedDll -= ResolvePSRPClient;
            GC.SuppressFinalize(this);
        }
        ~Resolver() { this.Dispose(); }
    }
}
'@

# Will be selected at runtime based on the host environment - just used for testing here
$libPath = "/home/jborean/dev/omi/PSWSMan/lib/glibc-1.1/libpsrpclient.so"

# Will check if pwsh still ships libpsrpclient, if so it's going to call SetDllImportResolver to ensure
# pwsh no longer uses the shipped copy. If not present then SetDllImportResolver is not called
# so that in case pwsh adds it's own resolver won't impact this module
$pwshDir = Split-Path -Path ([PSObject].Assembly.Location) -Parent
$libPresent = Test-Path -LiteralPath (Join-Path $pwshDir libpsrpclient.so)

# Will live for the scope of the module - disposes itself on unload
[PSWSMan.Resolver]::new($libPath, $libPresent)

Do you see any glaring problems with this approach? It should work today where the builtin libs are present and in the future where they are no longer present with PowerShell. Things are a bit more complicated on macOS as it needs to set up some symlinks for the OpenSSL libs at runtime but I think I have a separate solution for that which I don't hate too much.

The only downside I can see with this approach over the current just copy into the pwsh dir is that someone needs to import this module. If any WSMan commands are run then the existing libpsrpclient is loaded forever and the user would need to restart pwsh and import the module first. This should hopefully be less of a problem in the future when libpsrpclient is no longer shipped.

I wonder we are trying to resolve the fundamental problem with PowerShell remoting based on the principle of minimal change.
It would be more correct to create a new modern design to support different implementations. We already have a RFC for this, but it is also based on the principle of minimal change and would rather confuse and make things worse.
Why not make it a subsystem? And not create a new one based on gRPC, for example?
It would be a great fundamental investment for years to come. MSFT team has been talking about it for years. Isn't the next non-LTS milestone the most appropriate time for this work, when MSFT has completed another cycle of OS (Windows 11) development?