I am using WIX 3.0 Toolset and VS2008. In my ".wixproj" file I have added the following code (which works fine). I want to add a condition so that it will only install PIA if office 2007 is installed.
...
<ItemGroup>
<BootstrapperFile Include="Microsoft.Net.Framework.3.5">
<ProductName>.NET Framework 3.5</ProductName>
</BootstrapperFile>
<!-- Here I want to check if office is installed. If true then install the PIAs -->
<BootstrapperFile Include="Microsoft.Office.PIARedist.2007">
<ProductName>Microsoft Office 2007 Primary Interop Assemblies</ProductName>
</BootstrapperFile>
</ItemGroup>
...
I have the following code written in my installer script .wxs but this is not useful in the bootstrapper.
...
<!-- Properties to check for Word 2007 Version. Return string should be "Word.Application.12" -->
<Property Id="WORDVERSION">
<RegistrySearch Id="RegistrySearchWordVersion"
Root="HKCR"
Key="Word.Application\CurVer"
Type="raw"/>
</Property>
...
Similar to: WIX: GenerateBootStrapper conditions?
Check out the Product and Package Schema Reference and you probably want to look at the <BypassIf> and <InstallChecks> element.
Related
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>
Step 1:
Do the edit for following to the *.*proj files
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />
<!-- To modify your build process, add your task inside one of the targets below and uncomment it.
Other similar extension points exist, see Microsoft.Common.targets.-->
<Target Name="BeforeBuild">
<Version VersionFile="..\VersionInfo.txt" RevisionType="Increment">
<Output TaskParameter="Major" PropertyName="Major" />
<Output TaskParameter="Minor" PropertyName="Minor" />
<Output TaskParameter="Build" PropertyName="Build" />
<Output TaskParameter="Revision" PropertyName="Revision" />
</Version>
<AssemblyInfo CodeLanguage="CS" OutputFile=".\Properties\AssemblyVersion.cs" AssemblyVersion="$(Major).$(Minor).$(Build).$(Revision)" AssemblyFileVersion="$(Major).$(Minor).$(Build).$(Revision)" />
</Target>
<!--
<Target Name="AfterBuild">
</Target>
-->
Step 2:
Remove the AssemblyVersion number, and AssemblyFileVersion from the AssemblyInfo.cs
Step 3:
Create a file called VersionInfo.text outside where the sln resides.
Step 3:
Include the AssemblyVersionNumber.cs into the project's
Step 4:
Issue a MSBuild, Works fine on local machine, but not on the build server.
DevMachine: (32 bit)
C:\SVNHome\branches\MyGreatProject-II>msbuild -ver
Microsoft (R) Build Engine Version 3.5.30729.1
[Microsoft .NET Framework, Version 2.0.50727.3643]
Copyright (C) Microsoft Corporation 2007. All rights reserved.
BuildServer:
D:\SVNHome\branches\source\MyGreatProject-II>%windir%\Microsoft.NET\Framework64\v3.5\msbuild
-ver
Microsoft (R) Build Engine Version 3.5.30729.1
[Microsoft .NET Framework, Version 2.0.50727.4234]
Copyright (C) Microsoft Corporation 2007. All rights reserved.
Error Message given on the build server is not helping.
Properties\AssemblyInfo.cs: error CS1730: Assembly and module
attributes must precede all other elements defined in a file except
using clauses and extern alias declarations
Its my bad, Went on to the Server,
Undo all checkouts on the build Server
Force a build, then it worked fine.
Thank you Jessehouwing. That was it.
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
i've inherited a setup project which uses Wix 3.0
For programming reason we must switch to VS2012 and therefore to Wix 3.7, too.
While reading about Wix 3.7 i found out that 3.7 offers project type "Setup project"
and project type "Bootstrapper project".
My first question is: Have i to make a Setup project as before AND a bootstrapper project and combine it or just a bootstrapper project.
Using Wix 3.0 the bootstrapper stuff was located in the wixproj file:
<ItemGroup>
<BootstrapperFile Include="Microsoft.Net.Framework.3.5.SP1">
<ProductName>Microsoft .NET Framework 3.5 SP1</ProductName>
</BootstrapperFile>
<BootstrapperFile Include="Microsoft.Windows.Installer.3.1">
<ProductName>Windows Installer 3.1</ProductName>
</BootstrapperFile>
</ItemGroup>
<Target Name="AfterBuild">
<GenerateBootstrapper Condition=" '$(Platform)' == 'x86' " ApplicationName="$(ProductName)" BootstrapperItems="#(BootstrapperFile)" ComponentsLocation="HomeSite" CopyComponents="True" OutputPath="$(TargetDir)%(CultureGroup.OutputFolder)" Culture="%(CultureGroup.Identity)" FallbackCulture="en-us" Path="$(WindowsSDKPath)" />
<GenerateBootstrapper Condition=" '$(Platform)' == 'x64' " ApplicationName="$(ProductName) (x64)" BootstrapperItems="#(BootstrapperFile)" ComponentsLocation="HomeSite" CopyComponents="True" OutputPath="$(TargetDir)%(CultureGroup.OutputFolder)" Culture="%(CultureGroup.Identity)" FallbackCulture="en-us" Path="$(WindowsSDKPath)" />
</Target>
Is this still possible? Here i have to change from .Net 3.5SP1 to .Net 4.5
Can somebody help me?
First, you could upgrade by just using WiX Toolset 3.7 and running wixcop on your WiX files to upgrade them.
If you want to use the new WiX bootstrapper...
You need both project types. A "Setup" project creates an .msi file. A "Bootstrapper" project creates an .exe file.
Remove the Visual Studio Bootstrapper items and GenerateBootstrapper tasks from your setup project. Create corresponding ExePackage or PackageGroupRef elements in your bootstrapper's Chain. A PackageGroup roughly corresponds to a Visual Studio Bootstrapper package but the "syntax" is different. To recreate a Visual Studio Bootstrapper package consult the files under C:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bootstrapper\Packages or equivalent.
For the Microsoft .NET framework, the WixNetfxExtension extension defines package groups that you can just reference.
My application needs .Net Framework 3.5, Crystal Report 10.5 and SQLServer Express 2005 as pre-requisites. For this purpose I created a wix setup project and added the msbuild task for prerequisites.
My current problem
When installing the kit to an user machine, crystal report trying to install before .net framework 3.5.
How can I change the order of the prerequisites?
My current msbuild task code is given below;
<ItemGroup>
<BootstrapperFile Include="Microsoft.Net.Framework.3.5">
<ProductName>.NET Framework 3.5</ProductName>
</BootstrapperFile>
<BootstrapperFile Include="Microsoft.Windows.Installer.3.1">
<ProductName>Windows Installer 3.1</ProductName>
</BootstrapperFile>
<BootstrapperFile Include="BusinessObjects.CrystalReports.10.5">
<ProductName>Crystal Reports Basic for Visual Studio 2008 (x86, x64)</ProductName>
</BootstrapperFile>
<BootstrapperFile Include="Microsoft.Sql.Server.Express.9.2">
<ProductName>SQL Server 2005 Express Edition SP2 (x86)</ProductName>
</BootstrapperFile>
<Target Name="AfterBuild">
<GenerateBootstrapper ApplicationFile="$(TargetFileName)"
ApplicationName="Business Software"
BootstrapperItems="#(BootstrapperFile)"
ComponentsLocation="Relative"
CopyComponents="True"
OutputPath="$(OutputPath)\en-us\"
Path="C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\" />
This problem is rectified by replacing the DependsOnProduct tag in CrystalReports10_5\products.xml as follows
<RelatedProducts>
<!--<DependsOnProduct Code="Microsoft.Net.Framework.2.0" />-->
<DependsOnProduct Code="Microsoft.Net.Framework.3.5.SP1" />
Try using dotnetinstaller.
It is a free tool and the benefit of using dotnetinstaller is you can merge your msi with that and can generate an exe which can be executed an administrator unlike msi file.
In dotnetinstaller you can have pre-conditions defined and much more.