PowerShell7/test/csharp
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
..
csharp.tests.csproj Move powershell to .NET Core 2.0 (#3556) 2017-04-17 11:52:38 -07:00
fixture_AssemblyLoadContext.cs Remove CoreConsoleHost from xUnit tests 2016-05-17 13:28:44 -07:00
README.md Update test documentation 2016-04-04 19:20:26 -07:00
test_Binders.cs Add all classes to AssemblyLoadContext collection 2016-03-17 18:15:39 -07:00
test_CorePsPlatform.cs Move powershell to .NET Core 2.0 (#3556) 2017-04-17 11:52:38 -07:00
test_ExtensionMethods.cs Add all classes to AssemblyLoadContext collection 2016-03-17 18:15:39 -07:00
test_FileSystemProvider.cs Convert tab indentations to spaces in *.cs files (#3551) 2017-04-13 13:45:46 -07:00
test_MshSnapinInfo.cs Re-enable checking of assemblies with strong names 2016-06-27 14:49:46 -07:00
test_PSVersionInfo.cs Add all classes to AssemblyLoadContext collection 2016-03-17 18:15:39 -07:00
test_Runspace.cs Remove trailing whitespace (#3001) 2017-01-16 13:31:14 -08:00
test_SecuritySupport.cs Add all classes to AssemblyLoadContext collection 2016-03-17 18:15:39 -07:00
test_SessionState.cs Remove CoreConsoleHost from xUnit tests 2016-05-17 13:28:44 -07:00
test_Utils.cs Add all classes to AssemblyLoadContext collection 2016-03-17 18:15:39 -07:00

xUnit Tests

These tests are completely Linux specific.

Every test class must belong to [Collection("AssemblyLoadContext")]. This ensures that PowerShell's AssemblyLoadContext is initialized before any other code is executed. When this is not the case, late initialization fails with System.InvalidOperationException : Binding model is already locked for the AppDomain and cannot be reset.

Having every class in the same collection is as close to an xUnit global init hook as can be done.

Running xUnit Tests

Go to the top level of the PowerShell repository and run: Start-PSxUnit inside a self-hosted copy of PowerShell.