Repository navigation
Provide a way to host PowerShell in a CoreCLR application #2291
Description
Activity
Hosting PowerShell in your own process is more difficult due to the necessity of loading PowerShell's AssemblyLoadContext before CoreCLR's, or at least this is the impression I came away with after talking to Dongbo Wang (@daxian-dbw). Dongbo should be able to tell you more about it.
Reacted by Andy JordanMy understanding is it doesn't have to be before loading coreclr. In https://github.com/PowerShell/PowerShell/blob/master/src/powershell/Program.cs we are doing exactly that: initializing ALC in the managed code.
I included a line
PowerShellAssemblyLoadContextInitializer.SetPowerShellAssemblyLoadContext(AppContext.BaseDirectory);which I took from our XUnit tests, but it may need some alterations.
Actually, that's indeed could be the problem with windows version (improper ALC init).For a CoreCLR application to host powershell, if the powershell assemblies are in its TPA list, then it has to use one of the
Initialize*method to call into the actual entry point:PowerShellAssemblyLoadContextInitializer.InitializeAndLoadEntryAssembly(string basePaths, AssemblyName entryAssemblyName); PowerShellAssemblyLoadContextInitializer.InitializeAndCallEntryMethod(string basePaths, AssemblyName entryAssemblyName, string entryTypeName, string entryMethodName, object[] args);You can find an example at https://github.com/PowerShell/PowerShell/blob/master/src/powershell/Program.cs#L27
SetPowerShellAssemblyLoadContextis for CoreCLR applications that don't have powershell assemblies in their TPA list, which are usually native CoreCLR hosts.Initialize*APIs are for CoreCLR applications that have powershell assemblies in their TPA list, which are usually managed hosts that leverage dotnet.exe.If I add the following code it works:
PowerShellAssemblyLoadContextInitializer.SetPowerShellAssemblyLoadContext("C:\\Program Files\\PowerShell\\6.0.0.10");Seems like the required dll's are not being copied to the bin folder.
For example:
PowerShellAssemblyLoadContextInitializer.SetPowerShellAssemblyLoadContext("C:\\Program Files\\PowerShell\\6.0.0.10"); using (PowerShell ps = PowerShell.Create()) { ps.AddScript("Write-Host 'It works!'"); var result = ps.Invoke()[0]; Console.WriteLine(result.toString()); }
- added this to the milestone
on Nov 4, 2016 - modified the milestones: ,
on Dec 19, 2016 Any hints on how to make this work on Linux (CentOS)?
- changed the title
[-]Provide a way to host powershell in coreclr application[/-][+]Provide a way to host Powershell in a CoreCLR application[/+]on Mar 20, 2017 - changed the title
[-]Provide a way to host Powershell in a CoreCLR application[/-][+]Provide a way to host PowerShell in a CoreCLR application[/+]on Mar 20, 2017 A documentation about hosting powershell core is added: https://github.com/PowerShell/PowerShell/tree/master/docs/host-powershell
Iztok Prelog (@iztokp) Unfortunately, as discussed here, all powershell NuGet packages that have been published so far only contain powershell assemblies built specifically for Windows. We need to publish NuGet packages that contain both Windows and Unix assemblies (#3417 is opened to track this), but
dotnet packdoesn't seem to support that.
This is follow-up from #2284
Steps to reproduce
Create a simple coreclr app that hosts powershell thru
Microsoft.PowerShell.SDKNote: the current function of
Microsoft.PowerShell.SDKis to provide an ability to compile binary modules that then could be imported and used in PowerShell on any platform. This issue asks a question: should we allow the same nuget package to enable hosting scenario?Program.cs
project.json
{ "version": "1.0.0-*", "buildOptions": { "debugType": "portable", "emitEntryPoint": true }, "dependencies": {}, "frameworks": { "netcoreapp1.0": { "dependencies": { "Microsoft.NETCore.App": { "type": "platform", "version": "1.0.1" }, "Microsoft.PowerShell.SDK" : "1.0.0-alpha10" }, "imports": "dnxcore50" } } }nuget.config
dotnet restore works fine, dotnet run doesn't
Expected behavior
You should be able to run and execute
Actual behavior
On Unix (note that 6.0.0-alpha10 package doesn't have libs compile under
Unixconfiguration, so that's expected)On Windows
Environment data