Commit graph

14 commits

Author SHA1 Message Date
Ilya a9f106da58 Move xUnit tests in new folder (#8356)
## Motivation

I have a PR where there are many new xUnit tests.
It would also be useful to create new xUnit tests for public APIs.
The number of xUnit tests will increase and their ordering is required.

## PR Summary

- Move C# xUnit tests in new folder. This allows to put new xUnit tests in directory structure in accordance with directory structure where cs files are.
- Use an xUnit TestCaseOrderer attribute to sequentially process tests for `powershell.config.json`.
- Update README.md
- A race condition was fixed which allowed  to run all XUnit tests in single batch job.
2018-12-13 14:22:07 -08:00
dependabot[bot] b3f315eb15 Bump xunit from 2.4.0 to 2.4.1 (#8140) 2018-10-29 13:28:02 -07:00
dependabot[bot] cbfe2c8fe8 Bump xunit.runner.visualstudio from 2.4.0 to 2.4.1 (#8139) 2018-10-29 13:27:25 -07:00
Christoph Bergmeister [MVP] fe731eda14 Use dotnet test since the dotnet xunit test runner has been deprecated (#7980) 2018-10-09 20:55:41 -07:00
dependabot[bot] 6b6d5e3fd1 Bump Xunit.SkippableFact from 1.3.6 to 1.3.12 (#7972)
Bumps [Xunit.SkippableFact](https://github.com/AArnott/Xunit.SkippableFact) from 1.3.6 to 1.3.12.
- [Release notes](https://github.com/AArnott/Xunit.SkippableFact/releases)
- [Commits](https://github.com/AArnott/Xunit.SkippableFact/compare/v1.3.6...v1.3.12)

Signed-off-by: dependabot[bot] <support@dependabot.com>
2018-10-08 11:07:54 -07:00
Christoph Bergmeister [MVP] 5717a5dffc Add xunit project to PowerShell.sln and make it runable from within VisualStudio (#7254)
* add csproj ref to sln

* Remove Microsoft.NET.Test.Sdk NuGet reference. The xunit.runner.visualstudio package is now sufficient for running tests in VS in the latest version (15.7.5)

* use RTM versions of XUnit 2.4.0 that got published today

* Update XUnit in hosting project as well to newer release
2018-08-02 11:51:04 -07:00
Steve Lee 5dc7a6cb07 Add Windows Compatibility Pack 2.0.0 to PS Core and adopt the official .NET Core 2.1 (#6958)
To support PowerShell modules built with .NET Windows Compatibility Pack, we decided that it was best to ship the WCP assemblies with PS Core. This also adds many new .NET APIs be default while only adding ~3.5 MB additional disk footprint (to a ~137 MB install currently).
Also update the build to adopt the official .NET Core 2.1.
2018-06-03 22:06:26 -07:00
Ilya 84344cbb32 Update PowerShell to build with .NET Core SDK 2.1.300-rc1-008662 (#6718)
* Build Update
- Change `TargetFramework` to `netcoreapp2.1` and removed unnecessary `RuntimeFrameworkVersion` from `PowerShell.Common.props`
- Update dotnet SDK to 2.1.300-rc1-008662
- Update `TypeGen` target in `Build.psm1` to work with 2.1
- Rename macOS runtime to `osx-x64` as the old build logic expects 10.12 and breaks running on 10.13 system.
- Remove `PackageReference` to `System.Memory` as it's part of dotnetcore 2.1
- Update search for `crossgen` executable to find the matching version

* Test Update
- Update test tools `WebListener` to latest `asp.net core`
- Marked `AuthHeader Redirect` tests as `Pending` due to change in CoreFX
2018-05-02 16:58:39 -07:00
Travis Plunk a603cf3867
Update csproj files to the latest version of the package references (#5961)
* Add function which tells you packages which probably need to be updated
2018-01-22 12:06:50 -08:00
Chunqing Chen 22abe98c05 Fix xunnit test for PS (#4780)
* Initial work to enable xunit

* Moved AssemblyOriginatorKeyFile to csharp.tests.csproj

* Native binary has dylib extension on macOS
2017-12-01 17:34:30 -08:00
Dongbo Wang 192803bfcf Build powershell core using the generic RID 'linux-x64' (#4841) 2017-09-18 09:31:07 -07:00
Dongbo Wang 3e35fb9918 Move powershell to 2.0.0-preview3-25426-01 using the .NET CLI 2.0.0-preview2-006502 (#4144) 2017-06-30 13:07:14 -07:00
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
Dongbo Wang 54fa658e31 Migrate from project.json to MSBuild (#3398)
- FullCLR build is disabled in this change.
- FullCLR build related functionalities in `build.psm1` and `AppVeyor.psm1` are disabled. They are not cleaned up from `build.psm1` and `AppVeyor.psm1` yet. We need to adopt .NET Core 2.0 to verify the portable module concept, and if that works well, we will remove the Windows PowerShell source code and clean up our scripts.
- `dnxcore50` and `portable-net5+win8` target framework monikers are removed.
- Dependency on `Microsoft.NETCore.Portable.Compatibility` is removed. It's not necessary, but it may come back when we work on supporting the `portable module`. Its necessity can be reviewed at that time.
- I didn't spend the time to try building powershell in Visual Studio 2017. We should have a separate issue for that. It's tracked by #3400

The `TypeCatalogParser` project is replaced by a MSBuild target to gather the dependency information.
Due to .NET Core SDK issue [#1021](https://github.com/dotnet/sdk/issues/1021), our meta-package project `Microsoft.PowerShell.SDK` starts to generate an empty assembly during the build and that results in an empty assembly `Microsoft.PowerShell.SDK.dll` appear in `publish` folder and in `.deps.json` file. We cannot simply remove the assembly because it's now part of the TPA, and removing it will cause powershell to crash at startup. We have to live with this empty assembly until that .NET Core SDK issue is fixed.  It's tracked by #3401.
2017-03-23 13:04:52 -07:00