]
Sent: 09 July 2015 15:22
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Bootstrap conditioned on OSbittage
Ah that's great, and I can hide the bundle ARP itself as well?
On 09/07/2015 11:51, Pally Sandher wrote:
Unless the 3rd party installer is an MSI (which from your
Unless the 3rd party installer is an MSI (which from your previous e-mails, it
appears they're executables), Burn won't do that regardless.
If it is an MSI you can set the Visible attribute on the MsiPackage element to
yes it won't do it either.
Palbinder Sandher
Software Platform Engineer
An executable will always be executed as a child process of the process which
launches it. Even if you ship a DLL as your custom action you'll need to call
RunDLL32.exe to actually execute the code.
I don't think this is the question you need to be asking. What are you actually
trying to
See https://msdn.microsoft.com/en-us/library/aa368599.aspx
Palbinder Sandher
Software Platform Engineer
T: +44 (0)141 945 8500
F: +44 (0)141 945 8501
http://www.iesve.com
Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456
Registered Office - Helix Building,
See http://robmensching.com/blog/posts/2012/8/20/the-wix-toolset-license/
Palbinder Sandher
Software Platform Engineer
T: +44 (0)141 945 8500
F: +44 (0)141 945 8501
http://www.iesve.com
Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456
Registered Office - Helix
See http://wixtoolset.org/documentation/manual/v3/overview/heat.html
The -t parameter allows you apply an XSLT to post-process the generated XML.
Palbinder Sandher
Software Platform Engineer
T: +44 (0)141 945 8500
F: +44 (0)141 945 8501
http://www.iesve.com
Integrated Environmental
A very simplistic way to do it would be to add a LaunchCondition to your MSI
which the bootstrapper provides.
Something like
Condition Message=[ProductName] can only be installed using the
executable. Exit and run the executable to
install![CDATA[VALIDPRODUCTKEY]]/Condition
In your MSI and
http://wixtoolset.org/documentation/manual/v3/xsd/wix/product.html
http://msdn.microsoft.com/en-us/library/aa368609.aspx
Palbinder Sandher
Software Platform Engineer
T: +44 (0)141 945 8500
F: +44 (0)141 945 8501
http://www.iesve.com
Integrated Environmental Solutions Limited. Registered
You can make a patch to update both A - C and B - C but I don't think you can
selectively make it also update A to B.
C is the what you specific in the UpgradeImage section of your Patch Family
(the 'destination').
A B should be specified as TargetImages (the 'source').
e.g.
Family
http://www.joyofsetup.com/2007/09/24/test-your-setups-virtually/
Palbinder Sandher
Software Platform Engineer
T: +44 (0)141 945 8500
F: +44 (0)141 945 8501
http://www.iesve.com
Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456
Registered Office - Helix
http://wixtoolset.org/documentation/manual/v3/wixui/dialog_reference/wixui_installdir.html
Palbinder Sandher
Software Platform Engineer
T: +44 (0)141 945 8500
F: +44 (0)141 945 8501
http://www.iesve.com
Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456
http://wixtoolset.org/documentation/manual/v3/xsd/wix/customaction.html
See the 'Impersonate' attribute.
Palbinder Sandher
Software Platform Engineer
T: +44 (0)141 945 8500
F: +44 (0)141 945 8501
http://www.iesve.com
Integrated Environmental Solutions Limited. Registered in Scotland No.
Why are you using xcopy at all? CopyFile is a thing which exists -
http://wixtoolset.org/documentation/manual/v3/xsd/wix/copyfile.html
And then your files will be part of uninstall/rollback/upgrade etc without any
extra work.
Palbinder Sandher
Software Platform Engineer
T: +44 (0)141 945
Unless you also change the Upgrade table when you're poking around in your MSI
with Orca, it's not going to see the 2.0.0.0 as a new package if you didn't
add a MajorUpgrade element when you authored your package.
See
Anyone seen this before? I've bundles built using WiX v3.6 which are failing to
apply a patch which has been signed by a renewed code signing certificate. The
bundle was signed by the previous certificate which expired last month but both
the bundle the patch show up as valid signatures when I
access and the proper
certificates aren't on the computer.
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: April-01-14 9:33 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Bundle fails to verify signature of payload
Anyone seen this before? I've
I'll give that a try but it doesn't help for existing Bundles I don't
particularly want to rebuild dozens of released Bundles just to fix this.
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate
BRB, doing that on every machine across the planet.
This just in, WiX error codes != Microsoft error codes.
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Update uses the MSI
Installer as the main method of distribution, so I tend to disagree in
this case.
Carter
Quoting Pally Sandher pally.sand...@iesve.com:
BRB, doing that on every machine across the planet.
This just in, WiX error codes != Microsoft error codes.
Palbinder Sandher
What happens if you run your installer without .NET 3.5 installed? Does it
exhibit the same behaviour on all the versions of Windows you expect it to be
run on?
Which version of the .NET framework are your custom action projects targeted
at? (in Visual Studio right click the project -
Other than increasing the size of your binaries I don't see much of an issue.
Why do you need CString specifically?
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Why aren't you simply using
Chain
PackageGroupRef Id=NetFx40Redist/
...
/Chain
As per the manual at
http://wixtoolset.org/documentation/manual/v3/howtos/redistributables_and_install_checks/install_dotnet.html
?
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141
You can't. I feature requested this back in June 2012 -
http://wixtoolset.org/issues/3659/
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental
You don't need the 2nd entry in the InstallUISequence you pasted below. Remove
it as it's likely giving you false results.
The next button on your GetRackspaceCreds dialog is being mapped to something
called PrepareDlg which doesn't exist in your authoring. However that's a
problem you'll hit
be respected and it should
place that file in the redist\mpi_x64.msi folder relative to the output
bundle.exe.
On Fri, Oct 18, 2013 at 7:02 AM, Pally Sandher pally.sand...@iesve.comwrote:
It'd be nice if there was some easy way to leverage the redist directory
in your own Packages without
This is covered on the insignia page in the docs -
http://wixtoolset.org/documentation/manual/v3/overview/insignia.html
You'll need to manually add those Elements to the relevant .wixproj as last
time I checked there were no fields for them in the project view in Visual
Studio.
Palbinder
.
Target Name=SignCabs
Exec Command=Signtool.exe sign /a quot;%(SignCabs.FullPath)quot; /
/Target
On Tue, Oct 22, 2013 at 6:03 AM, Pally Sandher pally.sand...@iesve.comwrote:
This is covered on the insignia page in the docs -
http://wixtoolset.org/documentation/manual/v3/overview
You are correct, it's the web installer.
The full redistributable is named dotNetFx40_Full_x86_x64.exe is 48.1 MB in
size.
Looking at the source for the WiX installer, in \src\Setup\Bundle\Bundle.wxs it
contains the following:
Chain
PackageGroupRef Id='NetFx40Web' /
So
It'd be nice if there was some easy way to leverage the redist directory in
your own Packages without a massive effort.
Setting Name attribute of MsiPackage only works if you have the package
embedded in your bundle. It completely ignores it in the case of a DownloadUrl
e.g.
MsiPackage
Your hunch is correct.
There are 2 main reasons for the use of Burn as far as I know.
1 - dogfooding
2 - WiX installs a bunch of packages now instead of one monolithic package. If
you look in \src\Setup\Bundle\Bundle.wxs you'll see it chains .NET 4.0 full,
ProjectAggregator.msi if you have
WiX doesn't have any such thing. Some WIX extensions such as NetFx have some
defined which are listed in their respective schemas but there's nothing in
'vanilla' WiX like what you're describing.
Windows Installer on the other hand has a whole bunch of properties any MSI can
use (such as the
http://wixtoolset.org/documentation/manual/v3/wixui/dialog_reference/wixui_installdir.html
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental
Rob M. wrote some articles on the subject a few years ago:
http://robmensching.com/blog/posts/2007/8/3/zen-and-the-art-of-custom-actions
http://robmensching.com/blog/posts/2007/8/10/zataoca-classes-of-custom-actions
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368012.aspx
http://msdn.microsoft.com/en-us/library/aa372495.aspx
http://msdn.microsoft.com/en-us/library/aa372497.aspx
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
You should only need a check for the .NET 4.0 Client Profile. If the full .NET
4.0 is installed it should also return success since the full package upgrades
the Client Profile.
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
I'd assume the full .NET 4.0 puts both keys into the registry for this type of
issue.
Have you actually tested this yet?
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual
Question is if these machines don't have internet access, why is keeping them
up to date an issue?
If the answer is they have network access but not internet access then why not
just set up a machine to run WSUS for you -
http://technet.microsoft.com/en-us/windowsserver/bb332157.aspx It's
get:
Condition 'Netfx4FullVersion AND (NOT VersionNT64 OR Netfx4x64FullVersion)'
evaluates to false.
Maybe the .NET Framework 4 Extended is not considered as a full version. I
don't know where I can find an exhaustive list of these conditions.
Pally Sandher wrote
Use WiXNetFxExtension instead
Use WiXNetFxExtension instead of reinventing the wheel -
http://wix.sourceforge.net/manual-wix3/wixnetfxextension.htm
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual
Change your condition to SitBundleInstalled OR Installed
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in
What I mean: the application is based on MSYS and when a new user starts the
unix shell, he needs write access to folders like /home, ... . And /home is
contained inside the Programfiles\aplications folder.
No it's not. On Windows the equivalent of Unix home directory would be the
location
Which Temp directory are you looking in?
The TempFolder property page on MSDN says Windows Installer uses the
GetTempPath function to retrieve the path
-http://msdn.microsoft.com/en-us/library/aa372067.aspx
GetTempPath retrieves the first valid path stored in certain environment
variables in
1 - use the -suid flag with heat.exe to make your id's more readable.
2 - what's the Component throwing that error actually contain? The opening tag
doesn't actually give enough info by itself.
3 - heat.exe isn't designed to be used directly after generation. You will more
often than not have to
I think you'd need to pass the property to a Custom Action to check that. The
only things you can do in Conditional Statements are listed at
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368012.aspx and I
can't see anything which you could use there to test for the length of the
Try building your Bundle using the x86 platform rather than x64.
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited.
http://msdn.microsoft.com/en-us/library/aa372835.aspx says error 2727 is The
directory entry '[2]' does not exist in the Directory table.
Without the log entries relating to this error there's only speculation and
conjecture.
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945
No it's not a bug.
See #3 from my previous message. Then read it again until you understand it.
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated
From your InstallExecuteSequence code it looks like the Custom Actions should
be called after the file is written to TempFolder. InstallFiles should be long
before your Custom Actions but I would double check by opening the generated
MSI in InstEd! or Orca (or any other package which you can
I noticed this earlier in the week I'm using v3.6.
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in
Rob the RSS feed for WiX 3.8 hasn't been updating since the 8th. I don't have
the WiX 4.0 feed subscribed to check it.
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual
Because the WiX team wrote the WiX pre-processor syntax kept it to regularly
accepted coding standards (hence != for 'not equal to' as per every other
modern programming language) while the Conditional Statement syntax was written
by the Windows Installer team back in the mists of time?
BTW this is covered in the WiX manual under the how to's -
http://wix.sourceforge.net/manual-wix3/major_upgrade.htm
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
The proper approach would be to not use regsvr32 to register DLL's OCXs
author the registration info yourself.
If you want to make this a lot simpler, use heat.exe to generate the Class,
TypeLib Interface elements for you instead of having reams of RegistryValues
-
?
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: April 18, 2013 06:42
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Why in Preprocessor the Not Equal To is !=
while in conditional string is .
Because the WiX
Without seeing your Upgrade or MajorUpgrade code it's hard to say what it's
actually doing. As Rob says, I suspect it's upgrading when the versions are
equal due to the way your Upgrade table is laid out.
Have you tried installing 4.1.1.8896 first and then trying to install
4.1.1.8878 seeing
http://msdn.microsoft.com/en-gb/library/windows/desktop/aa368009.aspx
Found under Operating System Properties in the Property Reference at
http://msdn.microsoft.com/en-us/library/aa370905.aspx
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
You're missing the .NET Framework. You need to install it from the Features
add-in in the Management Console on Server 2008. It's not enabled by default.
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate +
See
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Registration-of-COM-Executable-Server-td6557760.html
or any of the other dozen or so times this has been asked answered on this
list.
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945
There's more than just Install, Uninstall Repair to consider for your custom
actions. dblock (creator of dotnetinstaller) has a handy WiX include you can
use to save time writing all the conditions yourself -
http://code.dblock.org/msi-property-patterns-upgrading-firstinstall-and-maintenance
Create [INSTALLLOCATION]\Website\App_Config in your Directory Tree use the
DestinationDirectory attribute instead of DestinationProperty.
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the
Use WiXNetFXExtension -
http://wix.sourceforge.net/manual-wix3/install_dotnet.htm
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions
Burn's standard BA can be very minimal if you configure it to be. Mine is
simply a dialog with some images/text and install cancel buttons. Clicking
install will attempt to install .NET 4.0 client profile followed by my MSI(s).
Use something like
BootstrapperApplicationRef
No, that's what requesting elevation exists for.
You should be asking why you need to turn UAC off in the first place which I
suspect we can't answer.
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate +
Personally I find a wixlib is mostly only useful if you're going to be sharing
them with a third party. They're effectively WiX's own version of merge modules
(but without a bunch of the problems merge modules have).
If your products A B are being built from the same solution then feel free to
Probably because WiXUI doesn't have any idea what your INSTALLFOLDER property
is or does.
If you're trying to set the contents of the PathEdit in InstallDirDlg you
should probably use the WIXUI_INSTALLDIR property associated with it as
detailed in the manual -
.
Otherwise the user's system will have the (invisible) Burn bundle
still registered which could cause problems if they attempt to
reinstall or install a newer release at a later time etc.
How do I specify that?
//Sam
On Tue, Feb 12, 2013 at 6:04 PM, Pally Sandher pally.sand
http://wix.tramontana.co.hu/
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456
Download the WiX sources, find the HyperlinkTheme.xml file modify it to your
needs.
You can then supply it using
bal:WixStandardBootstrapperApplication LicenseUrl= SuppressOptionsUI=yes
LogoFile=yourlogo.jpg ThemeFile= HyperlinkTheme.xml /
Works for me.
Palbinder Sandher
Software Platform
http://wix.sourceforge.net/manual-wix3/install_dotnet.htm
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in
, 2013 at 1:06 PM, Pally Sandher
pally.sand...@iesve.com
wrote:
http://wix.sourceforge.net/manual-wix3/install_dotnet.htm
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate
http://wix.sourceforge.net/manual-wix3/install_dotnet.htm
Chain
PackageGroupRef Id=NetFx40ClientRedist/
...your msi stuff goes here...
/Chain
End.
Yes it's that simple using WiXNetFXExtension. All the extra code you have is
just duplicating effort causing you problems.
Palbinder Sandher
projectname... Not the original Msi name and version...
I thought that the Bootstrapper just would do its checks, and then handover to
the Msi UI, and not display any thing to the user if all is Okay (.NET version
are the right.).
Thanks!
//Sam
On Tue, Feb 12, 2013 at 3:37 PM, Pally Sandher
My Burn bundle is 105 MB (110,669,784 bytes) when built however the 3 MSI's
which go into it total 108 MB (113,602,560 bytes). I assume Burn is compressing
the MSI's to account for the smaller size of the bundle compared to the
individual MSIs (I use 'high' compression on my embedded cabs,
The tutorial explains how to use WiXUI_InstallDir -
http://wix.tramontana.co.hu/tutorial/user-interface/ui-wizardry
Do you have an INSTALLDIR under your TARGETDIR or are you simply setting
WiXUI_INSTALLDIR to TARGETDIR?
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F:
Windows 8 should have .NET 3.5 (and 4.0) support built in. I think the
WiXNetFxExtension you're using hasn't been updated to take this into account
when setting those properties. If you're using WiX v3.7 bug report it at
http://sourceforge.net/p/wix/bugs/
To work around it in the meantime,
You need to target Windows Installer 5.0 (which means Windows 7 and later only
I'm afraid) -
http://msdn.microsoft.com/en-us/library/windows/desktop/dd407936.aspx
Example code on Bob A's blog -
http://www.joyofsetup.com/2009/01/17/msi-v50-features-in-wix-v30/
Palbinder Sandher
Software
I've had to quote this to co-workers enough over the last 6 years that it
should probably be tattooed on my forehead at this point
See
http://msdn.microsoft.com/en-us/library/windows/desktop/aa511445.aspx#elevationgl
specifically the section titled To eliminate unnecessary elevation:
also see
This is what you're doing wrong -
http://msdn.microsoft.com/en-us/library/windows/desktop/bb204770.aspx#concurrent_installs
This is how you fix it -
http://wix.sourceforge.net/manual-wix3/authoring_bundle_intro.htm
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44
To start you off see
http://neilsleightholm.blogspot.co.uk/2008/08/customised-uis-for-wix.html
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated
For all those like myself whom have been updating regularly with the latest WiX
v3.6 builds, the release is version 3.6.3303.0 while the last weekly release
build was 3.6.3227.0 so you probably want to update one last time.
The RSS feed doesn't list 3.6.3303.0 (as yet) so like myself, you may
Upgrade to v3.6 not v3.5 as it's already had at release candidate status will
be officially released pretty soon. You can then use Burn to bootstrap the .NET
4.0 framework as part of your install process.
As far as I remember it's a straight upgrade from v3.0 to v3.5 or v3.6, should
be no
Sounds like your Component GUIDs are different thus you've broken the
Component Rules -
http://robmensching.com/blog/posts/2003/10/18/Component-Rules-101
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate +
LocalAppDataFolder is perfectly acceptable. The ICE38 error is telling you that
you need to change the KeyPath for your components to be compliant with Windows
Installer expected behaviour.
It sounds to me like you've written a per-machine package are trying to turn
it into a per-user
I wouldn't recommend circumventing Windows Installer practices just because you
refuse to do things the correct way.
As Rob said it's explained how to work with per-user components in
http://wix.sourceforge.net/manual-wix3/create_start_menu_shortcut.htm
Palbinder Sandher
Software Platform
Works fine for me. Have you modified the Burn UI? When an MSI is cancelled, the
cancel button becomes a close button for me.
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual
with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456
Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20
0SP
Email Disclaimer
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: 15 August
Try using the Suppress specific warnings field in the individual wixproj
files where appropriate.
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated
IIRC this worked a while ago with older WiX v3.6 builds but hasn't for a while.
If I run my Bundle with the /layout switch, it will download the .NET 4.0
Client Profile redistributable any other MSI's or MSPs I have in my bundle
which have a DownloadURL specified (and Compressed=no set).
My Burn package includes the .NET 4.0 client profile from WiXNetFxExtension
like so:
PackageGroupRef Id=NetFx40ClientRedist/
When I attempt to install on XP64, I get a spurious error in Burn 0x800713ec -
Asia
Log file -
for Windows Installer XML toolset.
Subject: Re: [WiX-users] Burn - .NET 4.0 client profile fails to install
onWindows XP 64-bit
WIC is definitely a prereq on Windows 2003 server so it probably is on Win xp
64 bit too. Looks like a bug to me.
-Original Message-
From: Pally Sandher
. WIC is one of them.
Wes
Sent from my iPad
On 2012-08-15, at 1:29 PM, Peter Shirtcliffe pshirtcli...@sdl.com wrote:
WIC is definitely a prereq on Windows 2003 server so it probably is on Win xp
64 bit too. Looks like a bug to me.
-Original Message-
From: Pally Sandher
Which is why I recommended you start with the tutorial rather than wade in knee
deep with the reference docs.
Have you looked at it yet?
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the
Another workaround is to make the size of the checkbox control only as large as
the box itself so there's no grey background visible use a separate text
control which can be set to have a transparent background. Breaks screen reader
compatibility though if you're willing to live with that.
The WiX Tutorial should help you get started - http://wix.tramontana.co.hu/
It's far superior to the help files for learning the basics.
Also you can't send attachments to the list, they get stripped by the
sourceforge list-bot. Better to paste your code into your message.
Palbinder Sandher
Also you can display RTF files in Windows installer using the RichText control
as per the LicenseAgreementDlg in WiX_UI.
Might be a simpler/more elegant solution than having a button launch the RTF.
Any reason why you need the RTF to be in the Binary table rather than part of
the install?
.NET 4.0 doesn't exist on Win 7/Server 2008 R2. It has to be installed.
http://wix.sourceforge.net/manual-wix3/wixnetfxextension.htm
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the
http://wix.sourceforge.net/manual-wix3/run_program_after_install.htm
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited.
Nope. Use a Bundle to sequence your installers.
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland
Disclaimer
-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com]
Sent: 29 May 2012 03:32
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Issues with Burn (WiX v3.6.2921.0)
On 22-May-12 08:22, Pally Sandher wrote:
On a machine which has an existing v2.0 or later MSI
If you're not using auto-generated Product Package GUIDs, you'll need to
manually change them every time if you want to use Major Upgrades.
Package GUIDs should be auto-generated regardless. Product GUIDs are dependent
on your patching policy (in a nutshell keep it the same if you want to use
1 - 100 of 952 matches
Mail list logo
