Add Sandbox configuration to more easily perform Integration tests.

[bevanweiss]

Will automatically 'install' dotnet/dotnet sdk into sandbox at startup based on versions in 'src/test/sandbox/{AMD64,ARM64}' (dotnet-runtime.zip & dotnet-sdk.zip).
Running ./src/test/sandbox/setup_sandbox.bat will download the required files (when run on the host).
If the files aren't available, and the guest has network, it will attempt to download the files itself at startup.

Still to be done (possible future enhancements):

• menu at startup to allow easy one button selection of which particular test set to run
• investigation into whether vstest.console.exe can be used to capture test execution, and possibly have the sandbox available as a test runner, so MSI tests could be run in the sandbox directly from the dev environment.

[barnson]

We should prefer using the official installers as more typical of what users will be running. Here's what I did: https://github.com/barnson/wixsandbox

[bevanweiss]

The approach of copy'ing the zip in, and unzipping actually came from the Microsoft docker images for containers
https://github.com/dotnet/dotnet-docker/blob/f4904f177893776b719998a8d3a510e55a897b11/src/sdk/8.0/windowsservercore-ltsc2022/amd64/Dockerfile#L46
It's how they do it for the runtime/aspnet/SDK containers.

I did have a quick try (earlier) with the installer, and it seemed to take a bit longer.
It's likely not a significant factor in the overall timing for Sandbox activities though.

I'll modify it tonight to do the .exe download in the host prep, and then the install instead of unzipping within the Sandbox.

[bevanweiss]

I've just done a comparison on the timing. And it's pretty significant.
Doing the zip file extract, it takes approximately 20 seconds (a little under) from double click to the menu appearing.
Doing the "dotnet.exe /install /quiet /norestart" instead takes over 50 seconds.

Do we really need to go the exe install option?

I actually went and looked at how the https://learn.microsoft.com/en-us/dotnet/core/install/windows#install-the-sdk-1 powershell script does it (it's also downloading the zip and extracting it).
From that I realised I shouldn't have been copying both the runtime AND the SDK over, only the SDK is required... which shaved off about 5 seconds from the startup time. So it was at menu in about 15 seconds.

[bevanweiss]

I've made another branch in my fork with the EXE version
https://github.com/bevanweiss/wix/tree/sandbox_setup_with_exe
You could do a time trial between this version and the latest zip version if you wanted.
https://github.com/bevanweiss/wix/tree/sandbox_setup

[barnson]

I'm less concerned about the time---the tests take ages more---than I am running in a typical environment. (The .zips are for Nano Server, which doesn't support MSI.) How about this? If you have the bundle installers working, leave them in but commented/goto'd out so it's easy enough for someone to switch to them if they want to investigate.

[bevanweiss]

In the IntegrationMsi tests I was getting about 6 of the Firewall tests failing, with a difference in upper vs lower case of the drive ('C' vs 'c') in the pathname compare.
I haven't checked the IntegrationBurn tests though.

[barnson]

Hmm...I'm on Windows 11/22H2. I wonder what would cause that failure.

[bevanweiss]

I'm also on W11 Pro/22H2 10.0.22621
When I run:
fsutil.exe file queryCaseSensitiveInfo
over the various wix folders, it reports:
Case sensitive attribute on directory ..{redacted}\wix\src is disabled.

I'll try going with v6 dotnet for a run, to see if that changes it. I wouldn't think so, but not sure what else might make it different. EDIT: Nope, v6.0.31 made no difference. Still has lower case 'c', whilst upper case 'C' expected

[barnson]

One difference is that your tests are coming from the Git checkout -- I wonder if Git is doing something weird...

[bevanweiss]

Ok, issue found.
To identify the tests to present (in the menu) I had the following:

for /f %%i in ('where /R c:\build runtests.cmd') do (
...

NOTE: Lowercase c:\, it would store these away, and present them for execution.
If selected for execution it would do a START "Title" /D {PATH} {FILENAME}
Because the where had c:\ then all the paths were c:\... which appears to have influenced the firewall rules created within the MSI run from that path.

[barnson]

Clean build---thanks!