PowerShell/test/powershell/Language/Scripting/ConstrainedLanguageMode.Tests.ps1
Dongbo Wang 7a55bf98b2 Move powershell to .NET Core 2.0 (#3556)
This change moves powershell to .NET Core 2.0. Major changes are:
1. PowerShell assemblies are now targeting `netcoreapp2.0`. We are using `microsoft.netcore.app-2.0.0-preview1-001913-00`, which is from dotnet-core build 4/4/17. We cannot target `netstandard2.0` because the packages `System.Reflection.Emit` and `System.Reflection.Emit.Lightweight`, which are needed for powershell class, cannot be referenced when targeting `netstandard2.0`.
2. Refactor code to remove most CLR stub types and extension types.
3. Update build scripts to enable CI builds. The `-cache` section is specified to depend on `appveyor.yml`, so the cache will be invalidated if `appveyor.yml` is changed.
4. Ship `netcoreapp` reference assemblies with powershell to fix the issues in `Add-Type` (#2764). By default `Add-Type` will reference all those reference assemblies when compiling C# code. If `-ReferenceAssembly` is specified, then we search reference assemblies first, then the framework runtime assemblies, and lastly the loaded assemblies (possibly a third-party one that was already loaded).
5. `dotnet publish` generates executable on Unix platforms, but doesn't set "x" permission and thus it cannot execute. Currently, the "x" permission is set in the build script, `dotnet/cli` issue [#6286](https://github.com/dotnet/cli/issues/6286) is tracking this.
6. Replace the use of some APIs with the ones that take `SecureString`.
7. osx.10.12 is required to update to `netcoreapp2.0` because `dotnet-cli` 2.0.0-preview only works on osx.10.12.
8. Add dependency to `System.ValueTuple` to work around a ambiguous type identity issue in coreclr. The issue is tracked by `dotnet/corefx` [#17797](https://github.com/dotnet/corefx/issues/17797). When moving to newer version of `netcoreapp2.0`, we need to verify if this dependency is still needed.
2017-04-17 11:52:38 -07:00

41 lines
1.4 KiB
PowerShell

Describe "Test constrained language mode" -Tags "CI" {
It "dynamic invocation on non-PowerShell thread should work" {
$refAssemblies = @()
if (!$IsCoreCLR) {
$refAssemblies += "Microsoft.CSharp"
}
$t,$null = Add-Type -ReferencedAssemblies $refAssemblies -WarningAction Ignore -PassThru @"
public class BinderBug$(Get-Date -Format FileDateTime)
{
public static object Test(System.Management.Automation.PSObject psobj)
{
// Invoke a method through PSObject, but with dynamic, so we get PowerShell's dynamic site binder involved
// And we do this on a different thread so there is no ExecutionContext/runspace to check the language mode
// The actual method called doesn't really matter.
return System.Threading.Tasks.Task.Run(() => ((dynamic)psobj).AddCommand("Get-Command")).Result;
}
}
"@
$o = [powershell]::Create()
$t::Test($o) | Should Be $o
try
{
# Set language mode to ConstrainedLanguage on a different runspace (so it doesn't affect this runspace)
$ps = [powershell]::Create()
$null = $ps.AddScript('$ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage"')
$null = $ps.Invoke()
$t::Test($o) | Should Be $o
}
finally
{
$ps.Dispose()
}
}
}