Try to make building Bal.wixext and IntegrationBurn faster.

1 files changed, 6 insertions, 25 deletions

diff --git a/src/test/burn/README.md b/src/test/burn/README.md
index 6c6e0dd9..1f2168cf 100644
--- a/src/test/burn/README.md
+++ b/src/test/burn/README.md
@@ -1,6 +1,6 @@
 # integration
 
-This repo is for building installers, and then executing xunit tests that run them and verify that they worked.
+This layer is for building installers, and then executing xunit tests that run them and verify that they worked.
 
 ## Running tests
 
@@ -9,42 +9,23 @@ Depending on who you talk to, these are integration or system-level or end-to-en
 They modify machine state so it's strongly recommended *not* to run these tests on your dev box.
 They should be run on a VM instead, where you can easily roll back.
 
-1. Run appveyor.cmd to build everything (the tests will refuse to run).
-1. Copy the build\Release\netcoreapp3.1 folder to your VM.
-1. Open a command prompt and navigate to the netcoreapp3.1 folder.
+1. Run build.cmd to build everything (the tests will not automatically run).
+1. Copy the build\IntegrationBurn\Debug\netcoreapp3.1 folder to your VM.
+1. Open an elevated command prompt and navigate to the netcoreapp3.1 folder.
 1. Run the runtests.cmd file to run the tests.
 
 You can modify the runtests.cmd to run specific tests.
 For example, the following line runs only the specified test:
 
-> dotnet test --filter WixToolsetTest.BurnE2E.BasicFunctionalityTests.CanInstallAndUninstallSimpleBundle WixToolsetTest.BurnE2E.dll
+> dotnet test --filter WixToolsetTest.BurnE2E.BasicFunctionalityTests.CanInstallAndUninstallSimpleBundle_x86_wixstdba WixToolsetTest.BurnE2E.dll
 
 The VM must have:
 1. x64 .NET Core SDK of 5.0 or later (for the test runner)
 1. Any version of .NET Framework (for the .NET Framework TestBA)
 1. x86 .NET Core Desktop Runtime of 5.0 or later (for the .NET Core TestBA)
 
-## Updating dependencies
-
-Use the `updatepackage.ps1` script from https://github.com/wixtoolset/Home.
-For example:
-
-* updatepackage.ps1 -TargetFolder path\to\repo -PackageName WixToolset.Bal.wixext -NewVersion 4.0.91
-* updatepackage.ps1 -TargetFolder path\to\repo -PackageName WixToolset.Data -NewVersion 4.0.199
-* updatepackage.ps1 -TargetFolder path\to\repo -PackageName WixToolset.Dependency.wixext -NewVersion 4.0.25
-* updatepackage.ps1 -TargetFolder path\to\repo -PackageName WixToolset.Mba.Core -NewVersion 4.0.52
-* updatepackage.ps1 -TargetFolder path\to\repo -PackageName WixToolset.NetFx.wixext -NewVersion 4.0.67
-* updatepackage.ps1 -TargetFolder path\to\repo -PackageName WixToolset.Util.wixext -NewVersion 4.0.82
-* updatepackage.ps1 -TargetFolder path\to\repo -PackageName WixToolset.Sdk -NewVersion 4.0.0-build-0204
-
 ## Building with local changes
 
-The micro repo model makes this very difficult and painful.
-The basic idea is to make your changes in each individual repo on the master branch (to get a stable version), commit, and then use appveyor.cmd to build the nuget package.
-Put your custom nuget packages into a folder, and modify each repo's nuget.config with an entry to that folder.
-
-Alternatively, go into the NuGet package cache (%USERPROFILE%\.nuget\packages) and replace the official binaries with your locally built binaries.
-
-Both of those approaches will poison your NuGet package cache, so you probably will want to run the following command to clear it when you're done:
+The current build process will poison your NuGet package cache, so you may have to run the following command to clear it:
 
 > nuget locals all -clear
\ No newline at end of file