> **Note** PowerShell v6.0.0-beta.1 has been released, which is on top of .NET Core 2.0 ([preview1-002106-00][netcoreapp20-preview1]).
> The existing design of `PowerShell AssemblyLoadContext` is not changed in `beta.1` release,
> so the way to host PowerShell `beta.1` is the same as before from the C# code perspective.
> However, you will need the 2.0 preview version of .NET Core SDK <sub>(the version `2.0.0-preview1-005952` is currently used to build PowerShell Core)</sub>,
> and the `.csproj` file will need to be updated.
> A .NET Core 2.0 version of the sample application project `"MyApp"` can be found under [sample-dotnet2.0-powershell.beta.1](./sample-dotnet2.0-powershell.beta.1) for your reference.
## PowerShell Core targeting .NET Core 1.1 and Prior
### Overview
Due to the lack of necessary APIs for manipulating assemblies in .NET Core 1.1 and prior,
PowerShell Core needs to control assembly loading via our customized `AssemblyLoadContext` ([CorePsAssemblyLoadContext.cs][]) in order to do tasks like type resolution.
So applications that want to host PowerShell Core (using PowerShell APIs) need to be bootstrapped from `PowerShellAssemblyLoadContextInitializer`.
`PowerShellAssemblyLoadContextInitializer` exposes 2 APIs for this purpose:
`SetPowerShellAssemblyLoadContext` and `InitializeAndCallEntryMethod`.
They are for different scenarios:
-`SetPowerShellAssemblyLoadContext` - It's designed to be used by a native host
whose Trusted Platform Assemblies (TPA) do not include PowerShell assemblies,
such as the in-box `powershell.exe` and other native CoreCLR host in Nano Server.
When using this API, instead of setting up a new load context,
`PowerShellAssemblyLoadContextInitializer` will register a handler to the [Resolving][] event of the default load context.
Then PowerShell Core will depend on the default load context to handle TPA and the `Resolving` event to handle other assemblies.
-`InitializeAndCallEntryMethod` - It's designed to be used with `dotnet.exe`
where the TPA list includes PowerShell assemblies.
When using this API, `PowerShellAssemblyLoadContextInitializer` will set up a new load context to handle all assemblies.
PowerShell Core itself also uses this API for [bootstrapping][].
This documentation only covers the `InitializeAndCallEntryMethod` API,
as it's what you need when building a .NET Core application with .NET CLI.
### Comparison - Hosting Windows PowerShell vs. Hosting PowerShell Core
As shown below, you can insert your business logic code directly in the `Main` method.
```CSharp
// MyApp.exe
using System;
using System.Management.Automation;
public class Program
{
static void Main(string[] args)
{
// My business logic code
using (PowerShell ps = PowerShell.Create())
{
var results = ps.AddScript("Get-Command Write-Output").Invoke();
Console.WriteLine(results[0].ToString());
}
}
}
```
However, when it comes to hosting PowerShell Core, there will be a layer of redirection for the PowerShell load context to take effect.
In a .NET Core application, the entry point assembly that contains the `Main` method is loaded in the default load context,
and thus all assemblies referenced by the entry point assembly, implicitly or explicitly, will also be loaded into the default load context.
In order to have the PowerShell load context to control assembly loading for the execution of an application,
the business logic code needs to be extracted out of the entry point assembly and put into a different assembly, say `Logic.dll`.
The entry point `Main` method shall do one thing only -- let the PowerShell load context load `Logic.dll` and start the execution of the business logic.
Once the execution starts this way, all further assembly loading requests will be handled by the PowerShell load context.
So the above example needs to be altered as follows in a .NET Core application: