maxmustermann/PowerShell
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
PowerShell/test/xUnit/xUnit.tests.csproj

40 lines
1.6 KiB
XML
Raw Normal View History

Remove Unicode BOM from text files (#11546)
2020-01-11 08:15:34 +01:00
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">
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 21:04:52 +01:00
Improve formatting performance by having better primitives on `PSObject` (#8785) By not doing excessive amounts of extra work, formatting can be sped up quite significantly (about 8x faster). The main change comes from adding new, more efficient, primitive to query an object for the existence of an instance member. The formatting system has been checking for if an object has properties other than some decorated properties added by PS remoting, and it doesn't this by retrieving all properties which results in heavy allocations and wasted cycles. By adding `GetFirstOrDefault` to `PSObject` and similar primitives to the underlying Adapters, we are able to return early, without having to get all properties back.
2019-03-21 02:43:52 +01:00
<Import Project="../Test.Common.props" />
Move powershell to `2.0.0-preview3-25426-01` using the .NET CLI `2.0.0-preview2-006502` (#4144)
2017-06-30 22:07:14 +02:00
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 21:04:52 +01:00
<PropertyGroup>
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-11-30 23:44:41 +01:00
<Description>PowerShell xUnit Tests</Description>
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 21:04:52 +01:00
<AssemblyName>powershell-tests</AssemblyName>
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 23:22:07 +01:00
<GenerateProgramFile>true</GenerateProgramFile>
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-03 01:58:39 +02:00
<RuntimeIdentifiers>win7-x86;win7-x64;osx-x64;linux-x64</RuntimeIdentifiers>
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 21:04:52 +01:00
</PropertyGroup>
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-11-30 23:44:41 +01:00
<PropertyGroup>
<DelaySign>true</DelaySign>
<AssemblyOriginatorKeyFile>../../src/signing/visualstudiopublic.snk</AssemblyOriginatorKeyFile>
<SignAssembly>true</SignAssembly>
</PropertyGroup>
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 21:04:52 +01:00
<ItemGroup>
Improve formatting performance by having better primitives on `PSObject` (#8785) By not doing excessive amounts of extra work, formatting can be sped up quite significantly (about 8x faster). The main change comes from adding new, more efficient, primitive to query an object for the existence of an instance member. The formatting system has been checking for if an object has properties other than some decorated properties added by PS remoting, and it doesn't this by retrieving all properties which results in heavy allocations and wasted cycles. By adding `GetFirstOrDefault` to `PSObject` and similar primitives to the underlying Adapters, we are able to return early, without having to get all properties back.
2019-03-21 02:43:52 +01:00
<ProjectReference Include="../../src/Microsoft.PowerShell.SDK/Microsoft.PowerShell.SDK.csproj" />
<ProjectReference Include="../../src/Microsoft.PowerShell.Commands.Diagnostics/Microsoft.PowerShell.Commands.Diagnostics.csproj" />
<ProjectReference Include="../../src/Microsoft.WSMan.Management/Microsoft.WSMan.Management.csproj" />
<ProjectReference Include="../../src/Microsoft.Management.Infrastructure.CimCmdlets/Microsoft.Management.Infrastructure.CimCmdlets.csproj" />
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 21:04:52 +01:00
</ItemGroup>
<ItemGroup>
Bump xunit from 2.4.0 to 2.4.1 (#8140)
2018-10-29 21:28:02 +01:00
<PackageReference Include="xunit" Version="2.4.1" />
Bump `Xunit.SkippableFact` from `1.3.12` to `1.4.8` (#12480)
2020-04-28 19:35:40 +02:00
<PackageReference Include="Xunit.SkippableFact" Version="1.4.8" />
Bump xunit.runner.visualstudio from 2.4.0 to 2.4.1 (#8139)
2018-10-29 21:27:25 +01:00
<PackageReference Include="xunit.runner.visualstudio" Version="2.4.1" />
Build(deps): Bump XunitXml.TestLogger from 2.0.0 to 2.1.26 (#8731)
2019-01-24 20:01:24 +01:00
<PackageReference Include="XunitXml.TestLogger" Version="2.1.26" />
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 21:04:52 +01:00
</ItemGroup>
Make xUnit tests run sequentially to avoid race conditions caused by manipulating 'powershell.config.json' in tests (#8945)
2019-02-22 20:57:10 +01:00
<ItemGroup>
<Content Include="xunit.runner.json">
<Link>xunit.runner.json</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
</Content>
</ItemGroup>
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 21:04:52 +01:00
</Project>
Reference in a new issue Copy permalink