| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
firewall rules.
Signed-off-by: Bevan Weiss <bevan.weiss@gmail.com>
|
|
|
|
|
|
|
|
|
|
| |
Install both the x64 AND the x86 versions of Windows Desktop Runtime.
Needed for the Burn Integration tests.
And having dotnet files in the sandbox directory was annoying, so put
them all into an assets directory
Signed-off-by: Bevan Weiss <bevan.weiss@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Removed ARM64/AMD64 folders for dotnet, the Sandbox MUST match the host
here, so no point downloading the installer for the non-host platform.
Debugger could probably be reduced in the same manner, but have not in
this iteration.
Have also added a simple README, just to explain (very basic) operation.
Signed-off-by: Bevan Weiss <bevan.weiss@gmail.com>
|
|
|
|
|
|
|
| |
Fix a couple of copy-paste errors in the "don't have files from
host in Sandbox" path also.
Signed-off-by: Bevan Weiss <bevan.weiss@gmail.com>
|
|
|
|
|
|
| |
Not sure if it's ideal, but it works..
Signed-off-by: Bevan Weiss <bevan.weiss@gmail.com>
|
|
|
|
|
|
|
|
|
| |
By default enable /noauth and /anyuser on the debugger, and don't show the
security warning (/nosecuritywarn).
It'll still show the firewall warning prompt. Default settings should be
fine for firewall (Private networks).
Signed-off-by: Bevan Weiss <bevan.weiss@gmail.com>
|
|
|
|
|
|
| |
And a fix up for the tests not launching the first try
(due to delayed expansion).
Also fixed up the copying of the debugger files.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It will now prompt for configuring the Remote Debugger if it can find it
on the host when doing the setup.
And will prompt within the Sandbox to run the Debugger at startup if found
It will also show the host-local IP address to connect to the debugger.
In addition, it will display a small menu to allow for simple selection of
a particular runtests.cmd version to execute.
I still haven't found a good way to get a debugger attached into the msiexec
environment without already having a coded breakpoint in, however.
Also added this sandbox folder to .gitignore, so that artifacts from here
aren't committed into the repo
Signed-off-by: Bevan Weiss <bevan.weiss@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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:
* 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.
Signed-off-by: Bevan Weiss <bevan.weiss@gmail.com>
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The includepath argument was displayed as `-include` in help message
while only `-includepath` is accepted.
|
| |
|
|
|
|
|
|
| |
v143 output is compatible back to VS2017 (at least).
Fixes https://github.com/wixtoolset/issues/issues/8211.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The MSBuild Version property is well-known and can be set by standard
processes. That can cause problem in the tests where the version is explicitly
set to validate WiX behaviors. So, we've switched to using the TestVersion
property that will be specific for our testing purposes.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
folder
Fixes 8078
|
| |
|
| |
|
|
|
|
| |
See https://github.com/wixtoolset/issues/issues/7862.
|
|
|
|
|
|
|
|
| |
WiX v4 (and probably v3) standardized on the error code E_MOREDATA when string
buffers were too small instead of E_INSUFFICIIENT_BUFFER. This fixes v5 to
match in a few missing cases.
Fixes 8094
|
|
|
|
| |
Fixes https://github.com/wixtoolset/issues/issues/8096.
|
|
|
|
| |
Fixes 8091
|
|
|
|
| |
Fixes https://github.com/wixtoolset/issues/issues/8046.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When running elevated, Burn uses the Windows Temp folder as its working folder
to prevent normal processes from tampering with the files. Windows Temp does
allow non-elevated processes to write to the folder but they cannot see the
files there. Unfortunately, contrary to our belief, non-elevated processes
can read the files in Windows Temp by watching for directory changes. This
allows a malicious process to lie in wait, watching the Windows Temp folder
until a Burn process is launched elevated, then attack the working folder.
Mitigate that attack by protecting the working folder to only elevated users.
Managed custom actions also fall back to using the Windows Temp folder in
some cases and thus can be exposed in a similar fashion as an elevated Burn
process. Remove that possibility.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When deleting directories recursively, an elevated custom action
following junctions in a user-writable location could recurse into
any directory, including some that you might not want to be deleted.
Therefore, avoid recursing into directories that are actually
junctions (aka "reparse points").
This applies to:
- The RemoveFoldersEx custom action (which doesn't actually do deletions
but would instruct elevated MSI to delete on your behalf).
- DTF's custom action runner.
|
|
|
|
|
| |
Take this breaking change opportunity to simplify the header files used by
BA devs.
|
| |
|
|
|
|
| |
Fixes https://github.com/wixtoolset/issues/issues/8059.
|
|
|
|
|
|
| |
It's a formatted field but was too short.
Fixes https://github.com/wixtoolset/issues/issues/8043.
|
| |
|
| |
|
|
|
|
| |
Fixes https://github.com/wixtoolset/issues/issues/8040.
|
|
|
|
| |
Fixes https://github.com/wixtoolset/issues/issues/8036.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Also renames WixToolet.BextUtil nupkg to WixToolset.BootstrapperExtensionApi.
|
| |
|