Jason Zhai ba94b53ba9 Merge branch 'release/8.0.4xx' | 1 week ago | |
---|---|---|
.. | ||
Framework | 1 week ago | |
images | 1 month ago | |
MsiInstallerTests.cs | 1 week ago | |
README.md | 1 month ago | |
VSWorkloadTests.cs | 1 week ago | |
WorkloadSetTests.cs | 1 week ago | |
dotnet-MsiInstallation.Tests.csproj | 1 month ago |
On Windows, when the .NET SDK is installed either via the standalone installer or by Visual Studio, it is installed to the Program Files folder. In both cases it uses MSIs under the hood, so we call this an MSI-based install (as opposed to a file-based install which consists of unzipping or copying the .NET SDK files to an arbitrary folder).
For an MSI-based .NET SDK install, .NET SDK workloads are also installed using MSIs. This modifies global machine state, which makes it hard to write automated tests for MSI-based workload operations.
To address this, the MSI Installation tests use a Virtual Machine as the target environment to install the .NET SDK and workloads. APIs to run commands on the Virtual Machine or to inspect its file system are available and are similar to the test APIs used in other tests in the repo.
Because installation actions can be fairly slow, the test infrastructure uses VM snapshots (also called checkpoints) to avoid repeating an action that was already run. Thus, if multiple tests have the same setup steps, those steps won't be repeated for each test, rather the correct snapshot will be applied when needed. As tests are run, a tree of states (with corresponding snapshots) and actions to transition between them are built up from the initial state. This tree of states is saved across test runs, so if nothing has changed then running a test a second time should complete very quickly, as all of the results of the test actions were already recorded.
The main requirements for running the tests are:
\\TestVM\c$
)Follow these instructions to enable Hyper-V on your host machine: Enable Hyper-V
For the tests to remotely control the VM, your host computer needs to be able to access the VM over the network. To enable this, you need to create a virtual switch for the VM which will also be shared by the host PC. In Hyper-V Manager, click on your host machine and then go to Virtual Switch Manager.
Create a new Virtual Switch connected to your external network adapter, and check the box that says "Allow management operating system to share this network adapter."
There are two different names for a virtual machine. There is the name that the host computer uses to identify the virtual machine. This is what you see in Hyper-V Manager. We call this name the "VM Name". There is also the PC name that the Operating System inside the virtual machine uses to identify itself. You can see or modify this in the system settings inside the virtual machine, and this is what you use to access the machine over the network. We call this name the "VM Machine Name".
For example, if you use Hyper-V's "Quick Create" to create a Virtual Machine, the VM Name may be "Windows 11 dev environment", while the VM Machine Name may be "WINDEV2401EVAL". In this case you would access the admin share using \\WINDEV2401EVAL\C$
.
The simplest way to create a virtual machine is to use "Quick Create". This will create a virtual machine that is ready to use without having to do much configuration. The virtual machine will have Visual Studio and the .NET SDK installed. Currently this doesn't impact the tests, but in the future it may be necessary to uninstall Visual Studio from the virtual machine.
You can also create a virtual machine by installing Windows on it from scratch. General instructions are here. To create the virtual machine:
These steps need to be taken regardless of the method used to create the virtual machine:
The first setting can be found in the 'Ethernet' or 'Wireless Connection' tab at the top.
Network Discovery and File Sharing is found under the 'advanced' tab, then under Advanced Sharing Settings.
\\TestVM\c$
or \\WINDEV2401EVAL\c$
).
REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1
\\WINDEV2401EVAL\c$
in File Explorer to confirm it's working. You will need to enter the username and password for the VM. The username will be of the form <VM Machine Name>\<Username>
, such as WINDEV2401EVAL\User
. Select the option to save the login information. This will allow the tests to access the VM.psexec \\WINDEV2401EVAL cmd /c dir c:\
(replacing WINDEV2401EVAL
with the VM machine name) to verify that PsExec can run commands on the VM. The command should complete in less than a second. If it takes longer then the Remote Service Management firewall rule is probably not enabled correctly.C:\SdkTesting
folder inside the VM. Copy the standalone installer for the baseline version of the SDK used to test (for example dotnet-sdk-8.0.100-win-x64.exe
) to that folderwinrm quickconfig
from a command prompt. This is needed for the tests to call the WMI APIs to control the virtual machine.Run the tests under Visual Studio -- to do so, you must launch Visual Studio with admin privileges.
The tests can read settings from a VMTestSettings.json
file which you need to manually create. The tests store the VM State tree in a VMState.json
file. Both of these go in the current directory, which when running tests in Visual Studio will be artifacts\bin\Tests\dotnet-MsiInstallation.Tests\Debug
. The VMTestSettings.json
file can have the following values:
\\TestVM
. If this isn't specified, the tests will use the VM Name with any spaces removed for the VM machine name.C:\SdkTesting
inside the VM.SdkInstallerVersion
.
Example:{
"VMName": "TestVM",
"VMMachineName": "WINDEV2401EVAL",
"SdkInstallerVersion": "8.0.300-preview.24155.26"
}
If you want to change the snapshot used for the initial test state, in addition to renaming the snapshots so that the new one has "Test Start" in its name, you will need to delete the VMState.json
file, as otherwise the root test state will be read from it.
Hyper-V supports a maximum of 50 snapshots per VM. If you make changes to the SDK and re-run tests, new snapshots will be created for the newly deployed stage 2 SDK. You may need to delete the older snapshots in order avoid hitting the snapshot limit. Also, if you want to force a test to run a command instead of using the cached result, you can delete the corresponding snapshot.