PipeSecurity (netstandard2.0) does not use .NET Framework implementation when loaded in Windows PowerShell

[rjmholt]

Not sure if this is the right place to ask about this, but let me know if not.

I'm trying to port a codebase that used to compile against net451 and netstandard1.6 to netstandard2.0.

(The code is essentially a PowerShell module that has to work with both Windows PowerShell and PS Core.)

I'm hitting a crash where constructing a PipeSecurity object in PS Core (netcoreapp2.1) on Windows throws this error:

An error occurred while starting PowerShell Editor Services:

Exception calling "StartLanguageService" with "2" argument(s): "Access Control List (ACL) APIs are part of resource management on Windows and
are not supported on this platform."
   at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception)
   at System.Management.Automation.Interpreter.ActionCallInstruction`2.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.Interpreter.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.LightLambda.RunVoid1[T0](T0 arg0)
   at System.Management.Automation.PSScriptCmdlet.RunClause(Action`1 clause, Object dollarUnderbar, Object inputToProcess)
   at System.Management.Automation.PSScriptCmdlet.DoEndProcessing()
   at System.Management.Automation.CommandProcessorBase.Complete()
Access Control List (ACL) APIs are part of resource management on Windows and are not supported on this platform.
   at System.Security.AccessControl.ObjectSecurity..ctor()
   at System.Security.AccessControl.CommonObjectSecurity..ctor(Boolean isContainer)
   at System.Security.AccessControl.NativeObjectSecurity..ctor(Boolean isContainer, ResourceType resourceType)
   at System.IO.Pipes.PipeSecurity..ctor()
   at Microsoft.PowerShell.EditorServices.Protocol.MessageProtocol.Channel.NamedPipeServerListener.Start()
   at Microsoft.PowerShell.EditorServices.Host.EditorServicesHost.StartLanguageService(EditorServiceTransportConfig config, ProfilePaths profilePaths)
   at CallSite.Target(Closure , CallSite , Object , Object , Object )

That's occurring in our codebase here: https://github.com/PowerShell/PowerShellEditorServices/blob/f45c6312a859cde4aa25ea347a345e1d35238350/src/PowerShellEditorServices.Protocol/MessageProtocol/Channel/NamedPipeServerListener.cs#L38-L67

The PR I'm making the changes in is here: PowerShell/PowerShellEditorServices#741

The PipeSecurity constructor was working for us in netstandard1.6, although it looks like this is a netstandard specific error message: https://github.com/dotnet/corefx/blob/032cc324f9f3c6d6fee7ca01e7aa8e3a4969deb9/src/System.Security.AccessControl/src/System.Security.AccessControl.csproj#L6

Is there a way for me to construct the PipeSecurity object in a netstandard2.0 library running against netcoreapp2.1 on Windows?

[danmoseley]

@pjanotti ?

[rjmholt]

Just realised I omitted some important data.

The binaries we generate are not actually loaded as a module by PowerShell, but Add-Typed, which is essentially Assembly.LoadFrom().

We used to construct the module selectively by cherry-picking binaries and placing them in a directory like modules/PowerShellEditorServices/bin/Core and modules/PowerShellEditorServices/bin/Desktop and then Add-Type-ing the ones we needed and letting assembly resolution take care of the rest.

This cherry-picking works perfectly when compiled against both netstandard1.6 and netstandard2.0 on Core.

But since netstandard2.0 gives us only one target, I just dumped all the DLLs from the publish folder into a shared directory (modules/PowerShellEditorServices/bin).

So it looks like adding some DLL has caused this problem?

[pjanotti]

Hi @rjmholt PipeSecurity will do no good to you in netcoreapp, even with the System.IO.Pipes.AccessControl package, there is no way to proper use it for pipes (summary #26869, full discussion #26400). You can use it on Windows with netstandard2.0 on top of netfx but then you don't have the proper constructor in netstandard2.0 ... sorry ...

The workaround is to directly p/invoke the constructor of the named pipe and set the proper settings so you can use it with the PipeSecurity via System.IO.Pipes.AccessControl package for netcoreapp, if you need some help with that I can try to give some guidance tomorrow.

[pjanotti]

Ah just looked at https://github.com/PowerShell/PowerShellEditorServices/blob/f45c6312a859cde4aa25ea347a345e1d35238350/src/PowerShellEditorServices.Protocol/MessageProtocol/Channel/NamedPipeServerListener.cs#L38-L67 ... in this case the workaround is already implemented but you will need to add a reference to System.IO.Pipes.AccessControl and create the PipeSecurity from there. I suspect that the same issue didn't happen in netcoreapp2.0 but need to investigate to confirm.

[rjmholt]

Thanks for the help (and quick response)! Yes, unfortunately our dependency on named pipes is a tricky one.

With our previous build against netstandard1.6, PS Core moved to netcoreapp2.1 and didn't create any problems for us -- both netcoreapp2.0 and netcoreapp2.1 seemed to tolerate the new PipeSecurity().

in this case the workaround is already implemented but you will need to add a reference to System.IO.Pipes.AccessControl and create the PipeSecurity from there.

I didn't quite understand you here where you say "add a reference". We have a csproj with the package reference, and we move the assembly into the same folder as the assembly we load -- is there another thing we need to do?

Also, I noticed our existing build grabs the System.IO.Pipes.AccessControl assembly from publish\runtimes\win\lib\netstandard1.3, so I don't know if that's some kind of workaround. (I've asked in my PR to see if there's a known reason)

[rjmholt]

Just tried to do things closer to how we did when we had the two build targets with the hand-picked assemblies.

I made sure to take System.IO.Pipes.AccessControl.dll and put it in the relevant folder. Now get the following error:

An error occurred while starting PowerShell Editor Services:

Exception calling "StartLanguageService" with "2" argument(s): "Could not load file or assembly 'System.IO.Pipes.AccessControl, Version=4.0.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified."
   at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception)
   at System.Management.Automation.Interpreter.ActionCallInstruction`2.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.Interpreter.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.LightLambda.RunVoid1[T0](T0 arg0)
   at System.Management.Automation.PSScriptCmdlet.RunClause(Action`1 clause, Object dollarUnderbar, Object inputToProcess)
   at System.Management.Automation.PSScriptCmdlet.DoEndProcessing()
   at System.Management.Automation.CommandProcessorBase.Complete()
Could not load file or assembly 'System.IO.Pipes.AccessControl, Version=4.0.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
   at Microsoft.PowerShell.EditorServices.Protocol.MessageProtocol.Channel.NamedPipeServerListener.Start()
   at Microsoft.PowerShell.EditorServices.Host.EditorServicesHost.StartLanguageService(EditorServiceTransportConfig config, ProfilePaths profilePaths)
   at CallSite.Target(Closure , CallSite , Object , Object , Object )

I checked the assembly strong name, and it seems to match:

> [System.Reflection.Assembly]::LoadFile("$PWd\..\PowerShellEditorServices\module\P
owerShellEditorServices\bin\Core\System.IO.Pipes.AccessControl.dll").FullName
System.IO.Pipes.AccessControl, Version=4.0.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

[pjanotti]

Hum... do you have System.Security.AccessControl.dll and System.IO.Pipes.dll on the same folder?

[rjmholt]

Yes to System.IO.Pipes.dll but no to System.Security.AccessControl.dll. I'll put that in and give it a try

[pjanotti]

We will have to understand which dlls are being brought to the folder (are they from which package?). At this moment I think that if we can correctly build against netstandard2.0 and run with actual netcoreapp dlls it should work... I will have to continue this tomorrow...

[rjmholt]

Yes I didn't mean to keep you up -- I'm not in a rush.

I need to apologise -- it turns out the original error was being thrown by Windows PowerShell (it was a configuration I overlooked, despite starting the process from PS Core):

An error occurred while starting PowerShell Editor Services:

Exception calling "StartLanguageService" with "2" argument(s): "Access Control List (ACL) APIs are part of resource management on Windows and
are not supported on this platform."
   at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception)
   at System.Management.Automation.Interpreter.ActionCallInstruction`2.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.Interpreter.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.LightLambda.RunVoid1[T0](T0 arg0)
   at System.Management.Automation.PSScriptCmdlet.RunClause(Action`1 clause, Object dollarUnderbar, Object inputToProcess)
   at System.Management.Automation.PSScriptCmdlet.DoEndProcessing()
   at System.Management.Automation.CommandProcessorBase.Complete()
Access Control List (ACL) APIs are part of resource management on Windows and are not supported on this platform.
   at System.Security.AccessControl.ObjectSecurity..ctor()
   at System.Security.AccessControl.CommonObjectSecurity..ctor(Boolean isContainer)
   at System.Security.AccessControl.NativeObjectSecurity..ctor(Boolean isContainer, ResourceType resourceType)
   at System.IO.Pipes.PipeSecurity..ctor()
   at Microsoft.PowerShell.EditorServices.Protocol.MessageProtocol.Channel.NamedPipeServerListener.Start()
   at Microsoft.PowerShell.EditorServices.Host.EditorServicesHost.StartLanguageService(EditorServiceTransportConfig config, ProfilePaths profilePaths)
   at CallSite.Target(Closure , CallSite , Object , Object , Object )

PowerShell Core/netcoreapp2.1 works fine.

But to run in Windows PowerShell, I needed to add the System.IO.Pipes.dll dependencies. I kept following the errors one by one, until I added System.Security.Principal.Windows.dll and got this original error again.

[rjmholt]

The current DLLs in the Windows PowerShell bin folder are:

> ls .\modules\PowerShellEditorServices\bin\Desktop\


    Directory: C:\Users\roholt\Documents\Dev\vscode-PowerShell\modules\PowerShellE
    ditorServices\bin\Desktop


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       12/30/2017   8:31 AM           9052 libdisablekeyecho.dylib
-a----       12/30/2017   8:31 AM           8840 libdisablekeyecho.so
-a----         9/7/2018  12:34 AM         392192 Microsoft.PowerShell.EditorServic
                                                 es.dll
-a----         9/7/2018  12:34 AM          36352 Microsoft.PowerShell.EditorServic
                                                 es.Host.dll
-a----         9/7/2018  12:34 AM         247808 Microsoft.PowerShell.EditorServic
                                                 es.Protocol.dll
-a----        5/18/2018   1:46 AM         118272 Serilog.dll
-a----         5/9/2018  10:39 PM           8704 Serilog.Sinks.Async.dll
-a----       10/22/2017   4:48 PM          31744 Serilog.Sinks.Console.dll
-a----       10/29/2017   6:30 PM          26624 Serilog.Sinks.File.dll
-a----        5/15/2018   1:29 PM          27272 System.IO.Pipes.AccessControl.dll
-a----        5/15/2018   1:29 PM          54416 System.Security.AccessControl.dll
-a----         7/6/2018   1:01 PM          21736 System.Security.Principal.dll
-a----        5/15/2018   1:29 PM          39056 System.Security.Principal.Windows
                                                 .dll
-a----       12/30/2017   8:31 AM           4096 UnixConsoleEcho.dll

[pjanotti]

The symptom described seems to indicate that on Windows PowerShell the code is attempting to run against some netstandard dll, which typically shouldn't happen but seems related to the way dlls are being added in the build of the project.

At first thought for Windows Powershell you shouldn't need to reference pipe and PipeSecurity related via System.IO.Pipes, you actually should get those via System.Core, the ACL stuff itself should be in mscorlib and already loaded in Powershell itself. That said I need to better understand how the project is pulling these dependencies. I will try to see if I can figure it out from your PR but I appreciate any guiding information.

[TylerLeonhardt]

@pjanotti this is a part of PowerShell Editor Services (the language server protocol implementation for PowerShell - used in the VSCode extension) which is the essentially a C#-based PowerShell module.

In other words, this code gets loaded into a PowerShell session... so all assemblies from PowerShell are already there - like you said. In order to cut down on dlls we ship in the module, we copy only the dlls that matter into a module directory (aka just the finished product):
https://github.com/PowerShell/PowerShellEditorServices/blob/master/PowerShellEditorServices.build.ps1#L204-L252

NOTE: That code is when PowerShell Editor Services was built for net451 and netstandard1.6. We separated the code that gets loaded into Windows PowerShell vs PowerShell Core.

In the PR that @rjmholt is working on, he's converting everything to .NET Standard 2.0 and completely removing net451 from the source. That means we get rid of the "Desktop" and "Core" folders we use to have (see that link for references to that) and just have all the dlls in one place.

I hope that provides some context.