Add xunit fork, clean up test deployment and execution #40
Conversation
This project is designed to target .NET Core. It depends on other runtime components of xunit including xunit.execution and xunit.runner.utility. Those are similarly being modified, but will be done in a fork of the main xunit repository, so that the changes can be merged upstream. Those changes can be merged upstream because they depend on contracts that are available in portable targeting packs, and thus can be built by targeting an appropriate portable profile. This xunit.console.netcore project is being added to the buildtools repository because it depends on a contract (System.Console) which is not a part of any currently available portable targeting pack.
The new xunit packages properly declare their dependencies on framework assemblies through package references, at compile time through packages.config and at run time through the test-runtime-packages.config. This change consumes those packages, and properly deploys the correct runtime libraries using the ResolveNuGetPackages task.
|
This PR goes with dotnet/corefx#358 |
| <add key="nuget.org" value="https://www.nuget.org/api/v2/" /> | ||
| </packageSources> | ||
| <activePackageSource> | ||
| <add key="All" value="(Aggregate source)" /> | ||
| </activePackageSource> |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
|
Thanks @weshaggard - I updated based on your feedback. |
|
The changes look good to me thanks @FiveTimesTheFun. We should verify that our CI can build successfully looking at the log it seems like something went wrong with our Azure storage. @mmitche any ideas? |
|
15:16:11 C:\Jenkins\workspace\BuildTools_Build>"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86 && build.cmd /p:SkipTests=true |
Conflicts: src/Microsoft.DotNet.Build.Tasks/Targets/tests.targets src/nuget/Microsoft.DotNet.BuildTools.nuspec
Hi,
I’ve just created a pair of pull requests, a fork of xunit (https://github.com/FiveTimesTheFun/xunit/tree/netcore) and a small CodeFlow for DevDiv\ProjectK to clean up test execution on CoreCLR. These changes are included in MyGet packages in the dotnet-buildtools feed, Microsoft.DotNet.BuildTools 1.0.18-prerelease, Microsoft.DotNet.TestHost 1.0.2-prerelease, xunit.abstractions.netcore 1.0.0-prerelease, xunit.console.netcore 1.0.0-prerelease, xunit.core.netcore 1.0.0-prerelease, and xunit.runner.dependencies.netcore 1.0.0-prerelease. Before the holidays, to unblock libraries I created a private copy of xunit that ran on CoreCLR. This change cleans up that private copy so most of it should be able to go upstream to xunit, and more accurately calculates the framework libraries that the test host depends on.
The xunit changes are split in half. Half of the changes are made in a fork of xunit, which should be able to flow upstream. (Before it flows upstream the new packages I created will be merged in to the existing packages and my name will be removed from the list of authors… I just included it so that people would know who to ask about the particular forked packages). They are new projects that compile the existing xunit code targeting the .NET Core contracts. They target these contracts by compiling as a portable assembly using a portable targeting pack that has the necessary contracts. The other half of the changes are in the runner executable, xunit.console.netcore.exe. Because this assembly has a dependency on a contract, System.Console, which is not a part of a portable targeting pack, it cannot be currently compiled without taking a dependency on our ProjectK corefx nuget packages or the ASP.NET ProjectK build tools. Because of that I’ve included that project in the buildtools repository.
The rest of the changes are to consume these new packages and deploy the test execution environments. A new target in publishtest.targets is run during the build of each project in corefx. For test projects, this target creates an execution environment folder of the build outputs, and the appropriate runtime assemblies for the packages that it depends on. As other platforms like Unix come online, they will use this to deploy their platform specific binaries in a unique test execution environment folder. The test projects are updated to depend on the new forked xunit packages. When the changes have flown upstream and new official xunit packages have been created, the projects should be updated to take a dependency on those new packages.
This change gets us closer to running in the Visual Studio UI on CoreCLR with xunit, because the xunit.execution.dll and xunit.runner.utility.dll assemblies target .NET Core, but it doesn’t get us all the way there. For that we need to wire up launching corerun in the Visual Studio runner and the serialization between those two processes.
Please let me know all your questions concerns or complaints or anything I can do here to address something coming down the pipeline.
Thanks,
Matt