I've chosen teams services (Visual studio online) as a new repository for my team, we working on the c# project. We're using WiX installer,
Team services msbuild can build our solution projects except for wix,
I have followed wix instruction for daily build instruction mentioned here http://wixtoolset.org/documentation/manual/v3/msbuild/daily_builds.html
I've added all required files in a folder, pushed into repository
the context of .wixproj is as following
<Project>
...
<PropertyGroup>
<WixToolPath>$(SolutionDir)Tools\wix\3\bin\</WixToolPath>
<WixTargetsPath>$(WixToolPath)Wix.targets</WixTargetsPath>
<WixTasksPath>$(WixToolPath)wixtasks.dll</WixTasksPath>
</PropertyGroup>
<Import Project="$(WixTargetsPath)" Condition=" '$(WixTargetsPath)' != '' " />
<!--<Import Project="$(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.targets" Condition=" '$(WixTargetsPath)' == '' AND Exists('$(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.targets') " />-->
<Target Name="EnsureWixToolsetInstalled" Condition="$(WixTargetsImported)' != 'true' ">
<Error Text="The WiX Toolset v3 build tools must be installed to build this project. To download the WiX Toolset, see http://wixtoolset.org/releases/" />
</Target>
</Project>
but Teams services still complains as following
light.exe(0,0): Error LGHT0217: Error executing ICE action 'ICE01'. The most common cause of this kind of ICE failure is an incorrectly
registered scripting engine. See
http://wixtoolset.org/documentation/error217/ for details and how to
solve this problem. The following string format was not expected by
the external UI message logger: "The Windows Installer Service could
not be accessed. This can occur if the Windows Installer is not
correctly installed. Contact your support personnel for
assistance.".
how can I conquer over this issue?
Finally I could resolve it by disabling validation via properties of wix installer,
more can be found here
WiX ICE validation errors
Related
I am developing a suite of UI tests using Selenium. One of the run-time dependencies of this suite is the chromedriver.exe, which we are expected to consume through the Selenium.WebDriver.ChromeDriver NuGet package.
The old world
When this NuGet package is imported the following lines are injected into the csproj file:
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('..\packages\Selenium.WebDriver.ChromeDriver.2.44.0\build\Selenium.WebDriver.ChromeDriver.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Selenium.WebDriver.ChromeDriver.2.44.0\build\Selenium.WebDriver.ChromeDriver.targets'))" />
</Target>
<Import Project="..\packages\Selenium.WebDriver.ChromeDriver.2.44.0\build\Selenium.WebDriver.ChromeDriver.targets" Condition="Exists('..\packages\Selenium.WebDriver.ChromeDriver.2.44.0\build\Selenium.WebDriver.ChromeDriver.targets')" />
And it is automatic by the Visual Studio. This covers our bases, making sure the build targets provided by the Selenium.WebDriver.ChromeDriver package are there at the time of the build and running them as needed. The logic inside the build targets file copies/publishes the chromedriver.exe to the right location.
All is green.
The new world.
I consume the same NuGet package as PackageReference in the csproj file. Cool. However, the build targets of that package are no longer executed. See https://github.com/NuGet/Home/issues/4013. Apparently, this is by design.
I could import the targets manually, but the problem is that I will have to hard code the location where the package is restored. It is no longer restored in the packages directory in the solution, but under my windows profile. But there is no property pointing to this location and hard coding it sucks.
So, here is the version that works for me and I hate it:
<PropertyGroup>
<MyPackagesPath>$(UserProfile)\.nuget\packages\</MyPackagesPath>
<SeleniumWebDriverChromeDriverTargets>$(MyPackagesPath)selenium.webdriver.chromedriver\2.44.0\build\Selenium.WebDriver.ChromeDriver.targets</SeleniumWebDriverChromeDriverTargets>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Selenium.WebDriver.ChromeDriver" Version="2.44.0" />
</ItemGroup>
<Target Name="EnsureChromeDriver" AfterTargets="PrepareForRun">
<Error Text="chrome driver is missing!" Condition="!Exists('$(OutDir)chromedriver.exe')" />
</Target>
<Import Project="$(SeleniumWebDriverChromeDriverTargets)" Condition="Exists('$(SeleniumWebDriverChromeDriverTargets)') And '$(ExcludeRestorePackageImports)' == 'true'" />
Overall, the Sdk style projects are absolutely great, but this whole business of running targets from the packages is totally broken, even if it is by design.
What am I missing?
EDIT 1
So, here is the content of the generated obj\UITests.csproj.nuget.g.targets:
<?xml version="1.0" encoding="utf-8" standalone="no"?>
<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<MSBuildAllProjects>$(MSBuildAllProjects);$(MSBuildThisFileFullPath)</MSBuildAllProjects>
</PropertyGroup>
<ImportGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
<Import Project="$(NuGetPackageRoot)selenium.webdriver.chromedriver\2.44.0\build\Selenium.WebDriver.ChromeDriver.targets" Condition="Exists('$(NuGetPackageRoot)selenium.webdriver.chromedriver\2.44.0\build\Selenium.WebDriver.ChromeDriver.targets')" />
</ImportGroup>
</Project>
Notice the ImportGroup condition is '$(ExcludeRestorePackageImports)' != 'true'. Now, this condition is always false, because ExcludeRestorePackageImports seems to be hard coded to be true in
c:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets
Inspecting binary log confirms this. Plus https://github.com/NuGet/Home/issues/4013 was closed as WontFix.
Or am I still missing something?
If you are running Restore and other targets during the build, you may get unexpected results due to NuGet modifying xml files on disk or because MSBuild files imported by NuGet packages aren't imported correctly.
I am trying to build a wixproj on VSTS but so far I only got the following message:
SetupProject1\SetupProject1.wixproj(27,5): Error : The WiX Toolset v3 build tools must be installed to build this project. To download the WiX Toolset, see http://wixtoolset.org/releases/
For my tests I have created a new wixproj with Wix Toolset v3.11RC2 on my computer and linked it to a new repo on VSTS.
VSTS hosted agent have Wix Toolset v3.10 installed.
The VSTS build use a VS Build Task, with the build Platform set to x86 in order to avoir the AnyCPU error.
I have tried with the Hosted and Hosted VS2017 agent but no luck and also tried the default Wix imports:
<Import Project="$(WixTargetsPath)" Condition=" '$(WixTargetsPath)' != '' " />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.targets" Condition=" '$(WixTargetsPath)' == '' AND Exists('$(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.targets') " />
And those recommended for VS2017:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Import Project="$(WixCATargetsPath)" Condition=" '$(WixCATargetsPath)' != '' " />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.CA.targets" Condition=" '$(WixCATargetsPath)' == '' AND Exists('$(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.CA.targets') " />
Do I need to configure something or is it not possible at the moment?
You should install WiX Toolset v3.10. The v3.11 project templates need corresponding toolset version (v3.11).
So, if you want to use v3.11, you need to setup a on premise build agent. BTW, VS2017 needs v3.11 toolset.
Regarding for v3.10 toolset, don’t install Wix Toolset Visual Studio 2015 extension, the WiX v3.10 extension is already provided, so just install Wix v3.10 toolset directly.
Simple steps for v3.10 if you have already install Wix Toolset Visual Studio extension:
Remove Wix Toolset VS extension
Uninstall WiX v3.10 toolset
Install Wix v3.10 toolset
Create a new Wix project in VS2015
Add to source control and build.
The similar issue: The WiX Toolset v3 build tools must be installed to build this project after applying template.
To summarize my research after #starain-MSFT had answered:
It is possible to use VS2017 + Wix3.11 on your computer and build on VSTS with VS2015 + Wix3.10, you just have to:
use the template from Wix3.10:
<WixTargetsPath Condition=" '$(WixTargetsPath)' == '' AND '$(MSBuildExtensionsPath32)' != '' ">$(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.targets</WixTargetsPath>
<WixTargetsPath Condition=" '$(WixTargetsPath)' == '' ">$(MSBuildExtensionsPath)\Microsoft\WiX\v3.x\Wix.targets</WixTargetsPath>
...
<Import Project="$(WixTargetsPath)" />
avoid any C# 7 specific
The property SuppressValidation set to true might help if you are blocked by ICE warnings.
And if your build hang on VSTS, check the warnings on your computer or set the RunWixToolsOutOfProc property in your .wixproj to true.
Wix on windows 10 with mvs2013 or mvs2014 is not working.
I am getting the error:
Error The "GenerateCompileWithObjectPath" task could not be loaded from the assembly \WixTasks.dll. Could not load file or assembly 'file:///c:\WixTasks.dll' or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. SetupProject5 C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets
If i try to include WixTasks.dll to the project, when mvs2013 or mvs2014 crashes during the build. I include \WixTasks.dll to the C:\SourceControl\vs2015\SetupProject1\SetupProject1\SetupProject1.wixproj from the unpacked wix binaries folder:
C:\SourceControl
// C:\SourceControl\vs2015\SetupProject1\SetupProject1\SetupProject1.wixproj
<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) .NET Foundation and contributors. All rights reserved. Licensed under the Microsoft Reciprocal License. See LICENSE.TXT file in the project root for full license information. -->
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">x86</Platform>
<ProductVersion>3.10</ProductVersion>
<ProjectGuid>0adbe89f-e1ce-4345-90e6-64b8304fa42f</ProjectGuid>
<SchemaVersion>2.0</SchemaVersion>
<OutputName>SetupProject1</OutputName>
<OutputType>Package</OutputType>
<WixToolPath>C:\SourceControl</WixToolPath>
<WixTargetsPath>$(WixToolPath)\wix.targets</WixTargetsPath>
<WixTasksPath>$(WixToolPath)\WixTasks.dll</WixTasksPath>
<WixTargetsPath Condition=" '$(WixTargetsPath)' == '' AND '$(MSBuildExtensionsPath32)' != '' ">$(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.targets</WixTargetsPath>
<WixTargetsPath Condition=" '$(WixTargetsPath)' == '' ">$(MSBuildExtensionsPath)\Microsoft\WiX\v3.x\Wix.targets</WixTargetsPath>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<OutputPath>bin\$(Configuration)\</OutputPath>
<IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
<DefineConstants>Debug</DefineConstants>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
<OutputPath>bin\$(Configuration)\</OutputPath>
<IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
</PropertyGroup>
<ItemGroup>
<Compile Include="Product.wxs" />
</ItemGroup>
<Import Project="$(WixTargetsPath)" />
<!--
To modify your build process, add your task inside one of the targets below and uncomment it.
Other similar extension points exist, see Wix.targets.
<Target Name="BeforeBuild">
</Target>
<Target Name="AfterBuild">
</Target>
-->
I was reading different online forums and examples the last two days. Also Pact books on wix by Nick Ramirez. Nothing is working.
Define the following MSBuild variables and everything should work.
<WixRootPath Condition=" '$(WixRootPath)' == '' ">$(MSBuildThisFileDirectory)Tools\wix\$(WixTargetVersion)\</WixRootPath>
<WixToolPath Condition=" '$(WixToolPath)' == '' ">$(WixRootPath)</WixToolPath>
<WixTargetsPath Condition=" '$(WixTargetsPath)' == '' ">$(WixRootPath)Wix.targets</WixTargetsPath>
<WixCATargetsPath Condition=" '$(WixCATargetsPath)' == '' ">$(WixRootPath)sdk\Wix.CA.targets</WixCATargetsPath>
<WixTasksPath Condition=" '$(WixTasksPath)' == '' ">$(WixToolPath)WixTasks.dll</WixTasksPath>
<WixSdkPath Condition=" '$(WixSdkPath)' == '' ">$(WixRootPath)sdk\</WixSdkPath>
Just make sure the paths are right. These paths are for the wix 3.10.2 binaries which I checkout for my builds on the build machine.
I think the build tasks should be looking in the path defined by the WIX environment variable but I'm not 100% sure about that.
I think defining all the variables with the path you set should fix everything since the error mentions looking in C:\WixTasks.dll normally the path it looks for is something like $(WixInstallPath)WixTasks.dll but if $(WixInstallPath) isn't properly defined it will just be empty and default to C:\WixTasks.dll. You do define $(WixTasksPath) but I think it's getting overwritten for somereason...
Regardless, there's something wrong on your system right now but you can work around it this way probably.
EDIT: If the above doesn't work, download the wix binaries from here and extract them into a folder called "Wix" or whatever you want to call it. Then set your WixRootPath to be equal to that location.
I encountered this when using VS2015 and working on git branches that use different versions of Wix. (I'm upgrading to the latest Wix version but not all branches are there yet.)
You must terminate and restart VS if you switch between git branches that use different versions if Wix. VS holds some Wix files open, files that won't work under any other version of Wix. If you forget to do this your VS build will fail with the (quite cryptic) message of "The "GenerateCompileWithObjectPath" task could not be loaded from the assembly C:\Program Files (x86)\WiX Toolset v3.10\bin\WixTasks.dll"
The working solution from WiX Cookbook by Nick Ramirez, 2015, Chapter1 "Building a WiX installer from the command line", Example 4 "BuildMachineInstaller"
Download and unzip wix binaries file, for example from here.
1. Create some folder for your project, for example C:\SourceControl\own\box1 with file Product.wxs
2. Extract binaries to some folder, for example to C:\SourceControl\own\box1\tools\wix
3. start windows command line tool cmd and change to your project folder. Execute candle and light commands as folows:
C:\SourceControl\own\box1>C:\SourceControl\own\box1\tools\wix\candle *.wxs -o obj\
C:\SourceControl\own\box1>C:\SourceControl\own\box1\tools\wix\light obj\*.wixobj -o bin\CommandLineInstaller.msi
Anyway, if somebody could give some working example files and description how to make *.exe or *.msi with MSBuild or Visual Studio Build and wix, i would appreciate a lot. The other examples in Pact books are not working by pure copying, although are very useful for general understanding.
I've just come across this issue and found that at the top of the wix2010.targets file was the following property group.
<PropertyGroup>
<WixInstallPath Condition=" '$(WixInstallPath)' == ''">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Installer XML\3.11#InstallRoot)</WixInstallPath>
<WixInstallPath Condition=" '$(WixInstallPath)' == ''">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows Installer XML\3.11#InstallRoot)</WixInstallPath>
When checking the referenced registry path there was no entry for 3.11 but there was one there for 3.10. and the installed version was reported as 3.10. So updating the property group to the following corrected the issue for me.
<PropertyGroup>
<WixInstallPath Condition=" '$(WixInstallPath)' == ''">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Installer XML\3.10#InstallRoot)</WixInstallPath>
<WixInstallPath Condition=" '$(WixInstallPath)' == ''">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows Installer XML\3.10#InstallRoot)</WixInstallPath>
Hope this helps.
I solved the problem by following these instructions:
Download WIX311.exe from https://github.com/wixtoolset/wix3/releases/tag/wix3111rtm
Download Votive2017.vsix from https://marketplace.visualstudio.com/items?itemName=RobMensching.WixToolsetVisualStudio2017Extension
Remove any old WiX nuget packets from your solution/project
Follow these instructions (you can omit /quiet).
http://packagingstuffs.blogspot.com/2017/11/wix-toolset-311-silent-install-method.html
Content from the website above;
To Install:
Step1: Download the source from web and get the installer wix311.exe.
Step2: Run following command:wix311.exe /install /quiet /norestart
Step 3: Copy the Votive2017.vsix file (provided by vendor) to the local machine (e.g. %TEMP%)
Step 4: Run VSIXinstaller from its stored location
"%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Professional\Common7\IDE\VSIXInstaller.exe" /quiet
Good luck and best regards
The Visual Studio Setup and Deployment uses Prerequisites.
These Prerequisites come as Bootstrapper packages with preconfigured Product.xml and Package.xml.
Can I reuse these configuration XML or do I need to redo the configuration when I making a PackageGroup for WiX?
The SQLExpress2008R2 Bootstrapper package:
product.xml: Contains related products and calls a SQLExpressCheck.exe
package.xml: Decides on the Architecture and has default arguments for installing the SQL Server
If I cannot reuse the Product.xml and Package.xml in Burn, should I resort to the BootstrapperFile in the WixProj file?
Unfortunately, you have to create your own PackageGroups and ExePackages. While some information can be copied from the Visual Studio Bootstrapper packages, you should look for the installation documentation for the prerequisite. Sometimes the real installation instructions are hidden in the release notes or even MSDN blogs. You might have to Google for "silent" or "unattended".
It wouldn't do any good to add GenerateBootstrapper to the .wixproj file because .wixproj files are not designed to import the common microsoft targets.
I decided in my case to instead of writing Burn PackageGroups use the following setup in the wixproj.
I have 7 Bootstrapper Packages with complex product.xml and package.xml and it would have made no sense to recreate Burn Package Groups.
<ItemGroup>
<BootstrapperFile Include=".NETFramework,Version=v4.0">
<ProductName>Microsoft .NET Framework 4 (x86 und x64)</ProductName>
</BootstrapperFile>
</ItemGroup>
<PropertyGroup>
<WindowsSDKBootstrapperPath>$(registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\GenericBootstrapper\4.0#Path)</WindowsSDKBootstrapperPath>
</PropertyGroup>
<Target Name="BeforeBuild">
</Target>
<Target Name="AfterBuild">
<GenerateBootstrapper ApplicationFile="$(TargetFileName)" ApplicationName="Rodenstock Consulting" ApplicationRequiresElevation="True" BootstrapperItems="#(BootstrapperFile)" ComponentsLocation="Relative" CopyComponents="True" OutputPath="$(OutputPath)" Path="$(WindowsSDKBootstrapperPath)" />
</Target>
I am using TeamCity for a continuous integration server and am deploying my application using a ClickOnce installer. I can get the installer to function and deploy my application but I cannot figure out how to include the installer for .net 4.5 if the computer does not already have it installed or how to enable the auto-update check feature in ClickOnce deployments. I am currently using the MSBuild file below to build my installer
<Project DefaultTargets="DoPublish" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets"/>
<PropertyGroup>
<Version>$(BUILD_NUMBER)</Version>
<Install>true</Install>
<InstallFrom>Unc</InstallFrom>
<UpdateEnabled>true</UpdateEnabled>
<UpdateMode>Background</UpdateMode>
<ClickOnceBuildDirectory>$(MSBuildProjectDirectory)\MyProject\bin\$(Configuration)\app.publish</ClickOnceBuildDirectory>
<ClickOnceInstallDirectory>$(MSBuildProjectDirectory)\Publish</ClickOnceInstallDirectory>
<ClickOnceFinalLocation>$(env_PublishUrl)</ClickOnceFinalLocation>
</PropertyGroup>
<Target Name="DoPublish">
<RemoveDir Directories="$(ClickOnceInstallDirectory)" ContinueOnError="true" />
<MSBuild Projects="MyProject.sln" Targets="Clean;Build" Properties="ApplicationVersion=$(Version);Configuration=$(Configuration)"/>
<MSBuild Projects="MyProject\MyProject.csproj" Targets="Publish" Properties="ApplicationVersion=$(Version);Configuration=$(Configuration);InstallUrl=$(ClickOnceFinalLocation)" />
<MakeDir Directories="$(ClickOnceInstallDirectory)"/>
<Exec Command="xcopy /E $(ClickOnceBuildDirectory) $(ClickOnceInstallDirectory)" />
</Target>
</Project>
You can use a bootstrapper to handle prerequisites like checking for the .NET Framework. Check the Application Deployment Prerequisites MSDN article, especially the sections about bootstrapping with ClickOnce and MSBuild.
There are also 2 more MSDN articles that detail how to install ClickOnce prerequisites and Creating bootstrapper packages.
As for auto-updates, do you want to locate the auto-update functionality outside the application itself, i.e., in an installer vs. in the application? There are several ways to allow ClickOnce updates in your application, including auto-updates via the ClickOnce Deployment API.
A brief explanation of using ClickOnce Bootstrapper packages can be found in this existing Stackoverflow article. Though you're not using WiX here, you can also check this this WiX thread, which is useful because you see some of the steps that didn't work along the way. These examples show the use of the GenerateBootstrapper MSBuild task to create the bootstrapper for the ClickOnce installer. Note that in the examples at the above links, the "Path" in the GenerateBootstrapper task is set to a subfolder under a Windows SDK location. This can be changed to another location, as long as that location has the necessary prerequisite packages.
Below is an example in which the .NET 4.5 Framework is set as a prerequisite for the install. The parent directory structure for the .NET 4.5 prerequisite is specified by the $(MyPathToPrerequisitePackages) property.
The BootstrapperFile item in the below example specifies the .NET 4.5 Framework prerequisite package. The value ".NETFramework,Version=v4.5" comes from the product.xml file in the Bootstrapper\Packages\DotNetFX45 folder, and allows the GenerateBootstrapper task to correctly identify the .NET 4.5 prerequisite/bootstrapper package. The "ProductName" value is simply a friendly description of the package.
<PropertyGroup>
<MyPathToPrerequisitePackages>C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\Bootstrapper</MyPathToPrerequisitePackages>
</PropertyGroup>
<ItemGroup>
<BootstrapperFile Include=".NETFramework,Version=v4.5">
<ProductName>.NET Framework 4.5</ProductName>
</BootstrapperFile>
</ItemGroup>
<GenerateBootstrapper
ApplicationFile="$(MyAppAssembly).application"
ApplicationUrl="$(MyClickOnceAppUrl)"
ApplicationName="$(MyClickOnceAppName)"
BootstrapperItems="#(BootstrapperFile)"
Culture="en"
FallbackCulture="en-US"
CopyComponents="true"
Validate="false"
Path="$(MyPathToPrerequisitePackages)"
SupportUrl="$(MyAppSupportUrl)"
OutputPath="$(MyDesiredOutputPath)\" />
Just posted a response on 'https://stackoverflow.com/a/39610060/1345870':
Just struggled with this myself - I chose to commit the bootstrapper files to source control. It is possible to override the path to bootstrappers, just provide /p:GenerateBootstrapperSdkPath=.build\Bootstrapper
Then no need to modify registry - and the added benefit that the build is now self-contained.
Only "problem" is that I have to manually copy the Bootstrapper files into source control. In my case (VStudio2015), this meant copying the files from C:\Program Files (x86)\Microsoft Visual Studio 14.0\SDK\Bootstrapper