I am using IzPack 4.3.4 and I am trying to add my uninstaller to
the Programs and Features section of the Windows control panel
I am using Windows 10 (Build 10240).
But it does not seem to work, I modified the existing simple sample and added the following code to install.xml:
<natives>
<native type="3rdparty" name="COIOSHelper.dll" stage="both">
</native>
<native type="3rdparty" name="COIOSHelper_x64.dll" stage="both">
</native>
</natives>
<listeners>
<listener classname="RegistryInstallerListener" stage="install"/>
<listener classname="RegistryUninstallerListener" stage="uninstall"/>
</listeners>
Various sources, including the IzPack docs, state that this should make it work. But nothing appears in the Programs and Features list.
So what do I need to do in order to make this work?
You also need ShellLink.dll for this to work:
<natives>
<native type="izpack" name="ShellLink.dll" />
<native type="izpack" name="ShellLink_x64.dll" />
<native type="3rdparty" name="COIOSHelper.dll" stage="both">
<os family="windows" />
</native>
<native type="3rdparty" name="COIOSHelper_x64.dll" stage="both">
<os family="windows" />
</native>
</natives>
Related
This is my xml file for installer.
<izpack:registry version="5.0"
xmlns:izpack="http://izpack.org/schema/registry"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://izpack.org/schema/registry http://izpack.org/schema/5.0/izpack-registry-5.0.xsd">
<pack name="UninstallStuff">
<!-- Special "pack", if not defined an uninstall key will be generated automatically -->
<!-- The variable $UNINSTALL_NAME can be only used if CheckedHelloPanel will be used
because there the variable will be declared. With that variabel it is possible
to install more as one instances of the product on one machine each with an
unique uninstall key. -->
<value name="DisplayName"
keypath="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$APP_NAME $APP_VER"
root="HKLM"
string="$APP_NAME" />
<value name="DisplayVersion"
keypath="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$APP_NAME $APP_VER"
root="HKLM"
string="$APP_VER" />
<value name="UninstallString"
keypath="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$APP_NAME $APP_VER"
root="HKLM"
string=""$JAVA_HOME\bin\javaw.exe" -jar "$INSTALL_PATH\uninstaller\uninstaller.jar"" />
<value name="DisplayIcon"
keypath="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$APP_NAME $APP_VER"
root="HKLM"
string="$INSTALL_PATH\icon\uninstallericon.ico" />
<value name="Publisher"
keypath="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$APP_NAME $APP_VER"
root="HKLM"
string="opname" />
</pack>
</izpack:registry>
I am getting publisher name but i am not able to get size field value.How can i add size field in add remove program.
I guess you've probably found the solution by now (or given up) as this question is over three years old, but I have found the solution. It doesn't seem to be documented on the IzPack site, but digging through the schema and the registry settings of other installed programs reveals the answer.
Application size is stored in the registry as a 32-bit DWORD value, which is the application's size in KB, under the key "EstimatedSize". For example, for a 100MB (==102400KB) application, your configuration would look like the following:
<value name="EstimatedSize"
keypath="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$APP_NAME $APP_VER"
root="HKLM"
dword="102400" />
If WixVariables WixMbaPrereqPackageId and WixMbaPrereqLicenseUrl are not added, it fails to compile.
The Windows Installer XML variable !(wix.WixMbaPrereqPackageId) is unknown.
The Windows Installer XML variable !(wix.WixMbaPrereqLicenseUrl) is unknown.
If the two variables are added, even though my test computer has .NET Framework 4.0 installed, the bootstrapper installs .NET Framework 4.0 every time.
How to avoid installing .NET Framework when the target computer already has the .NET framework?
Below is my sample code.
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">
<Bundle Name="TestBootstrapper" Version="1.0.0.0" Manufacturer="Microsoft" UpgradeCode="e8c02687-b5fe-4842-bcc4-286c2800b556">
<BootstrapperApplicationRef Id='ManagedBootstrapperApplicationHost'>
<Payload SourceFile='MyBA.dll' />
</BootstrapperApplicationRef>
<!--<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />-->
<Chain>
<PackageGroupRef
Id="Netfx4Full"/>
<MsiPackage Name="SetupProject1.msi" SourceFile="data\SetupProject1.msi" DownloadUrl="http://myserver/SetupProject1.msi" Compressed="no">
</MsiPackage>
<MsiPackage Name="SetupProject2.msi" SourceFile="data\SetupProject2.msi" DownloadUrl="http://myserver/SetupProject2.msi" Compressed="no">
</MsiPackage>
</Chain>
</Bundle>
<Fragment>
<WixVariable
Id="WixMbaPrereqPackageId"
Value="Netfx4Full" />
<WixVariable
Id="WixMbaPrereqLicenseUrl"
Value="NetfxLicense.rtf" />
<util:RegistrySearch
Root="HKLM"
Key="SOFTWARE\Microsoft\Net Framework Setup\NDP\v4\Full"
Value="Version"
Variable="Netfx4FullVersion" />
<util:RegistrySearch
Root="HKLM"
Key="SOFTWARE\Microsoft\Net Framework Setup\NDP\v4\Full"
Value="Version"
Variable="Netfx4x64FullVersion"
Win64="yes" />
<PackageGroup Id="Netfx4Full">
<ExePackage
Id="Netfx4Full"
Cache="no"
Compressed="no"
PerMachine="yes"
Permanent="yes"
Vital="yes"
SourceFile="dotNetFx40_Full_x86_x64.exe"
DownloadUrl="http://go.microsoft.com/fwlink/?LinkId=164193"
DetectCondition="Netfx4FullVersion AND (NOT VersionNT64 OR Netfx4x64FullVersion)" />
</PackageGroup>
</Fragment>
</Wix>
You are missing some configuration required by Burn to start up the custom BA. If initializing and loading of you BA fails it starts the prerequisite installer. In your case .Net Framework.
You have to add a "BootstrapperCore.config" file as payload in order to get your custom BA running. The BoostrapperCore.config tells the burn engine how to initialize your custom BA.
Your BootstrapperApplicationRef should look like this
<BootstrapperApplicationRef Id='ManagedBootstrapperApplicationHost'>
<Payload SourceFile='MyBA.dll' />
<Payload SourceFile='BootstrapperCore.config' />
</BootstrapperApplicationRef>
Content of BootstrapperCore.config file:
<configuration>
<configSections>
<sectionGroup name="wix.bootstrapper"
type="Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperSectionGroup, BootstrapperCore">
<section name="host"
type="Microsoft.Tools.WindowsInstallerXml.Bootstrapper.HostSection, BootstrapperCore" />
</sectionGroup>
</configSections>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" />
</startup>
<wix.bootstrapper>
<host assemblyName="MyBA">
<supportedFramework version="v4\Full" />
<supportedFramework version="v4\Client" />
</host>
</wix.bootstrapper>
</configuration>
Write the name of your assembly without extension to attribute "assemblyName".
Also make sure that you add the following entry to the assemblyinfo.cs of your BA Assembly, where MyNamespace.MyBA is the name of the class including the full namespace name which you derived from WiXBootstrapper.BootstrapperApplication
[assembly: BootstrapperApplication(typeof(MyNamespace.MyBA))]
WIX Bootstrapper is started the Framework installation by default, when it is unable to load the MBA. Check with simple message box that your MBA is loaded or not.
You can use the below code in Run() function to ensure that.
protected override void Run()
{
this.Engine.Log(LogLevel.Verbose, "Running the TestBA.");
MessageBox.Show("MBA is loaded");
this.Engine.Quit(0);
}
Ensure you have included the MBA class name in assembly info file.
[assembly: BootstrapperApplication(typeof(TestBA))]
Check your Bootstrapper log file in %temp% location to find the root cause of the error.
I referred this example to start the Bootstrapper application. This may helpful for you.
Burn creates a log -- what does it say? It sounds like your DetectCondition is wrong. Why not use the WiX package groups for .NET? They have the correct searches and conditions.
I am trying to create installer for our application using izpack, i am facing problem while executing script file in linux.I am able to run bat files through process panel. please reply
This question would be more easier to answer if you provide a little bit more info here ...
Blind guessing I would say that you need to make sure that the executable bits are preserved on your linux shell scripts using the executable tag like shown below:
<pack name="Tomcat 6 Application Server" required="yes" packImgId="Tomcat.image">
<description>The Tomcat 6.0 Web Application Server.</description>
<fileset dir="windows/apache-tomcat-6.0.32" targetdir="$INSTALL_PATH">
<os family="windows" />
</fileset>
<fileset dir="linux/apache-tomcat-6.0.32" targetdir="$INSTALL_PATH">
<os family="unix" />
</fileset>
<parsable targetfile="$INSTALL_PATH/conf/server.xml" type="xml" />
<parsable targetfile="$INSTALL_PATH/conf/tomcat-users.xml" type="javaprop" />
<parsable targetfile="$INSTALL_PATH/bin/catalina.bat" type="plain" />
<parsable targetfile="$INSTALL_PATH/bin/catalina.sh" type="plain" />
<executable targetfile="$INSTALL_PATH/bin/catalina.sh" keep="true" stage="never" />
<executable targetfile="$INSTALL_PATH/bin/startup.sh" keep="true" stage="never" />
<executable targetfile="$INSTALL_PATH/bin/shutdown.sh" keep="true" stage="never" />
<executable targetfile="$INSTALL_PATH/bin/digest.sh" keep="true" stage="never" />
<executable targetfile="$INSTALL_PATH/bin/setclasspath.sh" keep="true" stage="never" />
<executable targetfile="$INSTALL_PATH/bin/tool-wrapper.sh" keep="true" stage="never" />
<executable targetfile="$INSTALL_PATH/bin/version.sh" keep="true" stage="never" />
</pack>
You can use <executable> tags in your pack definitions
to specify which files are executables. The key is
to have stage="never" attribute so izpack does not execute
the file and to set keep="true" so izpack does not remove it.
For example:
<executable targetfile="$INSTALL_PATH/bin/some-secript"
os="unix" stage="never" failure="warn" keep="true"/>
documentation
[izpack-user] Setting file-permissions in Linux
I have had a NAnt/NAntContrib build running for a while on one machine:
(MS Windows Server 2003 Standard 32-bit SP2)
And I now need to run the same build script on a newer machine:
(Windows Server Standard 2008)
I have gotten NAnt and NAnt.Config installed and working on the new machine.
I am using NAnt.Core.Maillogger on the original machine, configured as such:
<property name="MailLogger.mailhost" value="mail.server.com" />
<property name="MailLogger.from" value="autobuild#hostredacted.com" />
<property name="MailLogger.failure.notify" value="true" />
<property name="MailLogger.success.notify" value="true" />
<property name="MailLogger.failure.to" value="team#hostredacted.com" />
<property name="MailLogger.success.to" value="team#hostredacted.com" />
<property name="MailLogger.failure.subject" value="AUTOBUILD: Failure on TEST" />
<property name="MailLogger.success.subject" value="AUTOBUILD: Success on TEST" />
<property name="MailLogger.failure.attachments" value="MailLogger.failure.files" />
<property name="MailLogger.success.attachments" value="MailLogger.success.files" />
<fileset id="MailLogger.failure.files">
<include name="build.log" />
</fileset>
<fileset id="MailLogger.success.files">
<include name="build.log" />
</fileset>
I run a very simple test .build file, to test mail functionality:
<target name="test_mail_pass">
<echo message="Test Success:
run by ${environment::get-user-name()}"/>
</target>
<target name="test_mail_fail">
<echo message="Test Fail:
run by ${environment::get-user-name()}"/>
<fail message="Some Failure occurred." />
</target>
The above works on the original machine, and seems to work on the new machine, except for the fact that no mail is sent.
There is no message in the console that indicates that anything went wrong (ignoring the obvious use of the <fail> task).
I don't even know where to begin figuring out what is wrong here, or how to troubleshoot this problem.
Any assistance would be greatly appreciated.
I have solved this problem with much Google-ing.
One of two things solved my problem, and I don't know which it was, but my problem is now solved.
My batch file needed to have the following command-line option:
-logger:NAnt.Core.MailLogger
The file that was referred to in the:
<fileset id="MailLogger.failure.files">
<include name="build.log" />
</fileset>
<fileset id="MailLogger.success.files">
<include name="build.log" />
</fileset>
Need to actually exist.
One post I read (lost the link) told of a problem where if the files to attach do not exist, the Mail will just not get sent.
I am a student developer and I have built several installers for the company I am working with now. So I am fairly familiar with WIX.
We recently decided to have a Build server that auto builds our solution. It builds both debug, and release, as well as Obfuscated (and non obfuscated) projects.
And you really don't have to understand any of this. All you have to understand is that I have the same Wix project building different MSIs dynamically.
So the way we build them is we call MSBuild.exe with several parameters. Parameters the wix project depends on.
So let's say we go into command prompt and write
C:\>\windows\Microsoft.NET\Framework\v3.5\MSBuild.exe MyApp.Install\MyApp.Install.wixproj /p:Configuration=Release /p:SpecialPath=Obfuscated /t:Build
The idea is that wix sees the "SpecialPath" parameter being assigned "Obfuscated"; and in the installer paths its source to
..\myApp\bin\$(var.SpecialPath)\myApp.exe which translates to ..\myApp\bin\Obfuscated\myApp.exe when built.
TheQuestion
How do you create those custom build parameters and have them passed to my .wxs file. As of now with this setup, $(var.SpecialPath) is not defined and the build CrashSplosions.
For obvious legal reasons I had to cut 90% of the project.wxs file out and rename some stuff, but for all intents and purposes this is what I have.
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Name="myApp" Language="1033" Version="$(var.Version)" Manufacturer="myApp" UpgradeCode="$(var.UpgradeCode)">
<Package Id="*" InstallerVersion="200" Compressed="yes" />
<Media Id="1" Cabinet="media.cab" EmbedCab="yes" />
<Directory Id="TARGETDIR" Name="SourceDir" >
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLLOCATION" Name="myApp">
<Component Id="myAppEXE" Guid="FD5EBC02-MY29-GUID-ACCA-61324C5F1B68">
<RegistryKey Root="HKLM" Key="Software\MyApp">
<RegistryValue Value="0" Type="string" KeyPath="yes"/>
</RegistryKey>
<File Id="MYAPPEXE" Name='myApp.exe' Source="..\myApp\bin\$(var.SpecialPath)\myApp.exe" />
</Component>
<Component Id="EngineDLL" Guid="*">
<File Id="ENGINEDLL" Name='Engine.dll' Source="..\myApp\bin\$(var.Configuration)\Engine.dll" />
</Component>
<Component Id="CommonDLL" Guid="*">
<File Id="COMMONDLL" Name='Common.dll' Source="..\myApp\bin\$(var.Configuration)\Common.dll" />
</Component>
</Directory>
</Directory>
</Directory>
<Feature Id="ProductFeature" Title="myApp" Description='All' Display='expand' Level="1" ConfigurableDirectory='INSTALLLOCATION'>
<ComponentRef Id="myAppEXE" />
<ComponentRef Id="EngineDLL" />
<ComponentRef Id="CommonDLL" />
</Feature>
</Product>
</Wix>
The reason it's not working for you is that you are setting msbuild properties on the command line, which are not getting passed through as wix variables. MSBuild properties and wix variables are two different concepts.
One way to fix this is to ignore the concept of msbuild properties and use environment variables to pass values directly to candle.exe. You can use environment variables in your wxs file like this:
$(env.SpecialPath)
You can then launch your setup build from a batch file which prepares the necessary environment variables like this:
#echo off
setlocal
set SpecialPath=foo
set Configuration=Release
set msbuild=C:\windows\Microsoft.NET\Framework\v3.5\MSBuild.exe
%msbuild% test.wixproj /t:Build || goto ERROR
exit /b 0
:ERROR
echo Failed to build setup!
exit /b 1
Alternatively, if you prefer to pass parameters via msbuild properties, you should first take a look at the msbuild candle task documentation. It shows you can set values in your wixproj file like this:
<DefineConstants>Variable1=value1;Variable2=value2</DefineConstants>
This still requires you to hardcode values in the wixproj file though. If you want to pass the values as msbuild properties on the command line, then you should probably do something like this:
<DefineConstants>Variable1=$(value1);Variable2=$(value2)</DefineConstants>
and then pass /p:value1=foo /p:value2=bar on the command line, or define these msbuild properties elsewhere.
As already answered, you need to pass the variables into WiX. We use Nant instead of MSBuild, but the concept remains the same.
Here's a Nant example passing in half a dozen variables to candle (it's not the cleanest example, but is lifted verbatim from a project I worked on)
<candle out="${dir.obj}\"
rebuild="true"
extensions="WixUIExtension;WixNetFxExtension">
<defines>
<define name="ProcessorArchitecture" value="${release.platform}" />
<define name="SourceDir" value="${dir.source}" />
<define name="version" value="${version}" />
<define name="releasetype" value="${release.type}" />
<define name="Language" value="${language}" />
<define name="product" value="${string.product}" />
<define name="productedition" value="${release.productedition}" />
</defines>
<sources>
<include name="*.wxs" />
<include name="..\Common\*.wxs" />
</sources>
</candle>
<!-- Define fallback culture for non-US -->
<property name="cultures" value="${language}" />
<property name="cultures" value="${language};en-US" unless="${language == 'en-US'}" />
<light
out="${dir.build}\setup_${release.platform}_${release.compressionlevel}.msi"
extensions="WixUIExtension;WixNetFxExtension;WixUtilExtension"
cultures="${cultures}"
rebuild="true"
suppressices="ICE03;ICE82"
suppresspdb="true" >
<arg line="-loc "setup-${language}.wxl"" />
<arg line="-sw1101" />
<arg line="-b ${dir.resources}" />
<arg line="-b ${dir.resources.common}" />
<arg line="-b ${dir.resources.common}\Microsoft" />
<arg line="-b ${dir.source}" />
<arg line="-dcl:${release.compressionlevel}" />
<arg line="-dWixUILicenseRtf=EULA_${language}.rtf" />
<sources>
<include name="${dir.obj}\*.wixobj" />
</sources>
</light>
I had a similar situation where the source path of the files was to be passed as a command line argument to the build script. This is what I did:
Edited the wixproj file and added the following content under the "PropertyGroup" node:
<Source Condition=" '$(Source)' == '' ">R:</Source>
where R: is the default directory/path from where to pick the source.
Now, the source can also be passed as a command line argument during build:
msbuild /t:Clean,Build "MyPath\MyWixProject.wixproj" /property:Source=MyConfigurablePath /p:Configuration=Release