Repository navigation
All AppInstallcerCLIE2ETests fail with the same message: "Access to the registry key ... AppModelUnlock ... is denied." #807
Description
Hello friends,
I am trying to get my local development environment set up, and while the code compiles and runs, all 67 of the end-to-end tests fail with the same message, similar to this one:
Test Name: DisplayFeatures
Test FullName: AppInstallerCLIE2ETests.AppInstallerCLIE2ETests.FeaturesCommand.DisplayFeatures
Test Source: C:\Users\kindr\Source\Repos\winget-cli\src\AppInstallerCLIE2ETests\FeaturesCommand.cs : line 27
Test Outcome: Failed
Test Duration: 0:00:00
Test Name: DisplayFeatures
Test Outcome: Failed
Result Message: OneTimeSetUp: System.UnauthorizedAccessException : Access to the registry key 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock' is denied.
The line that's triggering the exception is: src\AppInstallerCLIE2ETests\SetUpFixture.cs(130).
I'm relatively new to Windows development, especially with Visual Studios, so I may be missing something obvious. I have followed all the steps in the README.md under "Building the client>Prerequisites" including enabling Developer Mode. I can also confirm that the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock exists (though I dared not tamper with the permissions.) I'm running the latest build of Windows in the stable channel:
Edition Windows 10 Pro
Version 20H2
Installed on 2021-02-25
OS build 19042.867
Experience Windows Feature Experience Pack 120.2212.551.0
Any help is appreciated!
Activity
JohnMcPMS commentedon Mar 18, 2021
These tests are built to run on the build servers, and so expect to set up everything themselves. This requires Admin permissions to do, and in order to run them locally you will need to run VS as Admin. There is a README in the root of the E2E tests directory as well that should help: https://github.com/microsoft/winget-cli/tree/master/src/AppInstallerCLIE2ETests
Alternately, you can be lazy like myself and not bother running them until they fail in the build. They take much longer to run than the unit tests and often have build server specific issues anyway, as well as the difficult setup, so I have optimized for that path. I may be a special case though, being so entrenched in the project. I certainly understand the desire to ensure that things are running smoothly before you start changes on an unfamiliar project.
kindrowboat commentedon Mar 18, 2021
Thanks for the explaination and pointing me to the readme. When submitting a PR with a new feature, would you expect a new e2e tests or just new unit tests?
JohnMcPMS commentedon Mar 18, 2021
It depends on the feature, but for zip package handling I would expect new E2E test(s). I do prefer as much testing as possible be done in the unit tests, but having some smoke testing in the E2E is good too. I think it is especially needed to ensure that things are working correctly with regards to where files are placed and registry updates, because of how being inside a package works.