Port Microsoft.DotNet.XUnitRunnerUap

[ViktorHofer]

The Directory.Build.props and Directory.Build.targets don't play nice with the UWP project therefore I created empty ones in the project to disable the root ones. Tips how to condition the root ones correctly are welcome 😁

Changes:

• RemoteExecutor service removed as the runner now supports multiple instances
• Output logging removed as we can now directly log into the console and capture the output
• Dependencies updated & code cleanup
• Added README instructions for the runner and launcher

[ViktorHofer]

@tarekgh I updated the app to a UWP console application targeting the latest version 1803. I tried to updated your script but it seems the dependencies have changed since you wrote it. Do you know which files are necessary and must included? Or do you know somebody to find that out?

[tarekgh]

@joperezr should be the one who is familiar with the script and the UWP dependency.

[tmat]

The Directory.Build.props and Directory.Build.targets don't play nice with the UWP project

What do you mean? Do you see any build errors? If so please file an issue and share a binlog.

[tmat]

OK two possible issues:

1. C++ project - Arcade.SDK doesn't support C++ projects currently
2. The UAP project doesn't use SDK-style projects
   @nguerrera Is it possible to use .NET Core SDK projects for UAP?

[nguerrera]

@nguerrera Is it possible to use .NET Core SDK projects for UAP?

Nothing is built-in, but there is https://www.nuget.org/packages/MSBuild.Sdk.Extras/ from the community.

Also, it doesn't have to be necessary to import Microsoft.NET.Sdk to use the Arcade SDK.

[markwilkie]

I can imagine needing UWP projects like this one, as well as other .NET Framework type projects that currently aren't supported by the SDK (ex: WinForms/WPF). We could certainly use another SDK that builds on top of the Arcade SDK to augment things if we felt that was easier then just adding the conditions in the places we discover we need. In the meantime we can let those projects override what they need and we can try and find the pattern we need/want to share if and when we hit critical mass for those project types.

I agree with this thinking - the "line" as I see it is for packages that are required. For those, they need to conform.

However, for different repos that would like to build packages for their purposes, I don't see a problem with them building and publishing in the arcade repo. Of course, the farther away these packages "stray" from the "standard" arcade sdk style projects, the less they get to participate in the value that Arcade brings. However, that value is a sliding scale...

[markwilkie]

@tmat and @weshaggard - I'm ok w/ this going into Arcade and I think it makes sense, even if it's not a SDK-style project. You guys have any hard pushback? The way I see it is that so long as the Arcade SDK itself is not affected, the guidelines for packages that teams want to bring on is looser.

[weshaggard]

I'm good with these going into arcade.

I do want to call out that my comments were not just about this project going into arcade but also about any projects in any repo that consumes arcade. We need to be able to provide some level of support for those projects if they cannot be SDK style projects.

[tmat]

I'm fine as long as the issue that was hit by this PR is investigated.

[ViktorHofer]

The PR isn't in a mergeable state yet, I first need to update the UWP appx script (buildAndUpdateRunner.bat).

[weshaggard]

I'm fine as long as the issue that was hit by this PR is investigated.

I'm not sure what you want investigated. If I understand the issue correctly it is caused by the auto importing of Directory.builds.props/targets in the root of Arcade into a non SDK project which I wouldn't expect to work in general because of the assumptions being made in those props/targets about being an SDK project. So unless your expectation is that the auto-imported props/targets should work for any project type, which that isn't my expectation, then having empty versions of those to black the importing of the root versions seems like a reasonable thing.

[tmat]

Yes, I would expect it to mostly work. There are certainly some dependencies on .NET SDK - I am aware of a few. However, the errors above indicate an issue that I am not aware of. It would be useful to find out what it is, so that we can

provide some level of support for those projects if they cannot be SDK style projects.

as you suggested.

[ViktorHofer]

@joperezr @safern this is now ready to be merged. PTAL

[joperezr]

@ViktorHofer can you confirm that all of the code from the Xunit Launcher (C++) was copied exactly as it is on buildtools without any changes? Same goes for the actual Unit Test runner. If there were some changes required in order to get stuff to build, it would be nice to see which changes were required (apart from the need to add the Directory.Build.* files)

[ViktorHofer]

Only look at my commits, not the others ported over from buildtools. I didn't touch the WindowsStoreAppLauncher at all, you can skip reviewing that completely. The runner of course was rewritten as a UWP console app. I didn't change any logic involved with that.

[ViktorHofer]

I would like to merge this today to unblock the xunit work in corefx / other repos and will follow-up with what needs to be done to have a minimal Directory.Build.props and Directory.Build.targets support.

[safern]

LGTM.