Port test infrastructure to the open

[stevenbrix]

I started digging into this a little bit, but there are a lot more dependencies on registry access than I had anticipated. This will most likely take a few days by someone more knowledgeable than I am and take some careful scanning of the code. Since we want to move this out in the open as well, I feel both these items can be done at the same time.

[stevenbrix]

There are a few workarounds that need to be done in the Helix setup because of this, be sure to search for the url to this work item and update any documentation and/or remove the workarounds that were put in place. Part of this should also be to remove the dependency on Microsoft.WindowsDesktop.App from both QualityVault and STI. QV uses WinForms for displaying the progress UI in the bottom right corner. We should be able to build it against MicrosoftPrivateWinformsPackage or remove this functionality entirely.

[stevenbrix]

I'll summarize the workarounds in place and why they are needed:

The test infrastructure currently builds against Microsoft.WindowsDesktop.App (see more on this below). Due to https://github.com/dotnet/core-setup/issues/6370, it is tricky to get a proper Microsoft.WindowsDekstop.App runtime on the Helix machine. Instead of using the $(MicrosoftNETCoreAppVersion) property to install the proper version of Microsoft.NETCore.App on the machine, we set DotNetCliPackageType to sdk, which will install all the runtimes necessary. However, the best we can do here is use the sdk that is used to build the product with, which doesn't include the version of Microsoft.NETCore.App that we want. We don't particularly care which version of the runtimes the infrastructure runs against, however, we don't want the test executables to run against the incorrect version of Microsoft.NETCore.App in Helix. To work around this, we bundle up the local install that Arcade puts on the machine through the multi-framework support and put that on the machine when $(ContinuousIntegrationBuild) is set to True. The *.runtimeconfig.json files are all properly authored against this version of the runtime, so that will be used when the tests run on the Helix machine.

Note that when running locally, we are able to easily take advantage of the multi-framework support and don't have to do much. A recent change from Arcade causes the DOTNET_MULTILEVEL_LOOKUP variable to be set to 0. We have to set it to 1 to allow looking outside of of the DOTNET_ROOT(x86) location, since that only contains the Microsoft.NETCore.App runtime.

There seems to be an issue with our internal test repo at the time that has some tight dependencies on machine setup that I can not figure out. Both my machines are unable to build the repo, where one of them worked before I updated my VS install, and now it fails with the same errors as my others. Other people on the team aren't seeing this, nor do the official build machines, so it's hard to understand without going into more depth, which is not worth the time investigating at the moment. For that reason, I cannot simply remove the dependency on Microsoft.WindowsDesktop.App from the infrastructure.

[stevenbrix]

Removing the dependency on running as admin is being tracked by #1149 since it is a larger effort then we originally thought