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,
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:
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
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
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
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
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
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
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 +
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
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
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
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
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
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
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
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
My moneys on it being this -
http://msmvps.com/blogs/installsite/archive/2009/09/12/microsoft-s-recen
t-security-updates-for-visual-studio-break-windows-installer-updates.asp
x
See also -
http://www.msigeek.com/microsofts-recent-security-updates-for-visual-stu
dio-break-windows-installer-updates/
You are running the MS procedure for building a patch. All WiX is being
used for in this instance is to create the PCP file.
Sigh.
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate
John that doesn't necessarily generate a UAC prompt. It will simply
check if the user has the permissions necessary to generate a UAC prompt
before the MSI installs.
Sachin is your custom action running during the InstallUISequence or
InstallExecuteSequence? What is the Execute attribute of the
Essentially two installers listing the same component GUID in separate
locations is how things like the VC++ redistributable merge modules
work.
For example, your installer puts the VC++ 2008 redistributables onto a
users machine. My installer then does the same. Both of our installers
use the
Perhaps trying OR Installed as Blair suggested earlier might give you
better results.
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated
That's known as a Minor Update but it's only one of the available upgrade types.
See http://msdn.microsoft.com/en-us/library/aa370579.aspx
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate +
Use tallow.exe from the WiX v2.0 toolset. You can then process the .wxs
files you output with WiXCop.exe in WiX v3.0 to update the XML in the
.wxs files from the v2.0 schema to the v3.0 schema.
Unfortunately that functionality was never replicated in heat.exe even
though it is the tallow.exe
I asked a very similar question in September last year on this list. See
- http://n2.nabble.com/util-InternetShortcut-td838589.html for my
question Bob Arnson's reply.
More info on util:InternetShortcut on Bob A's blog at -
http://www.joyofsetup.com/2008/03/18/new-wix-feature-internet-shortcuts/
Remove the Condition elements in the code you pasted.
That will however enable the Browse button for all Features regardless
of installation status. To selectively enable it for Features which
haven't been installed yet and disable it for those which have you'll
have to modify the inner text of
Use a LaunchCondition in your MSI to detect for .NET 3.5 SP1 and deny
installation if it's not present. See
http://wix.sourceforge.net/manual-wix3/check_for_dotnet.htm
Also the following page may be of use to you if you're trying to create
a bootstrapper to install .NET 3.5 SP1 before running
Not unless you can re-write the standard error messages thrown by error
codes in Windows Installer (I'm guessing you don't work for the Windows
Installer team at Microsoft so that'd be a no). See error code 1633 on
http://msdn.microsoft.com/en-us/library/aa368542.aspx
Note that error codes are
Server 2008 is x64 only (unless you're using an Itanium system which is
rather unlikely). Try looking in C:\Program Files (x86)\Windows
Installer XML v3\bin\
Does WiX show up in the ARP list?
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945
a bad drop. Sorry.
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Thursday, January 07, 2010 11:26 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] HELP ...
Server 2008 is x64 only (unless you're using an Itanium system
Sounds like the user is downloading your MSI from a web page using Internet
Explorer clicking Run rather than Save in the download prompt. The MSI is
being run from the users Temporary Internet Files when the time comes for
them to install the later version, the old MSI simply doesn't exist
Use Win64=yes in your RegistrySearch Elements to force them to check
the normal areas of the Registry rather than the WOW6432Node. You will
get ICE warnings for this in an x86 package.
However you can't have one MSI which works natively for both x86 x64
platforms.
An MSI has a platform attribute
: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Wednesday, January 13, 2010 10:49 AM
...
An MSI has a platform attribute which must be set to Intel for x86
packages or Intel64 for x64 packages (can also use AMD64 for x64
packages but it's deprecated by Intel64).
...
Some confusion here
Directory Id=TARGETDIR Name=SourceDir
Merge
Id=msvcr71dllLanguage=1033DiskId=1SourceFile=My_MSM.msm /
/Directory
FeatureId=ProductFeature1Title=MergeMod321Level=1
MergeRefId=msvcr71dll/
/Feature
That is all you should Ricky need assuming you're using the VC++ 7 merge
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 you are running Windows in safe mode, or if the Windows
Installer is not correctly installed. Contact your support personnel for
assistance..
Until Burn is feature complete I'd recommend looking at dotnetinstaller
(http://dotnetinstaller.codeplex.com/). Been using it for a while now
it's quite easy to configure build in my experience.
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945
Regarding the ICE38 errors, it sounds like the directory your Component
is under is a per-user location. Try moving the Component to a
per-machine location like SystemFolder (even though you're not writing
any actual files or folders to the location in your Component) if it's
not there already. If
Looks like it's a bug in ICE61.
According to the MSDN documentation, VersionMin VersionMax both must
be a valid product version as described for the ProductVersion
property. See -
http://msdn.microsoft.com/en-us/library/aa372379(VS.85).aspx
ProductVersion properties are valid if The third field
Post the relevant sections of code e.g. the dialog where you ask the
user for the installation directory, any associated properties and/or
custom actions the section of the directory tree it relates to so we
can try see what's going wrong. Also looking at a verbose log (msiexec
/a yourmsi /l*vx
Have you tried using the -cc and -reusecab switches with light.exe?
Palbinder Sandher
Software Deployment IT Administrator
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
If you want your users to do the work you could use a simple
LaunchCondition in Product B which checks something that indicates
Product A is installed before it will allow installation of Product B.
However if you want automation with separate packages you're going to
have to bundle Product B with
Looks like the weekly releases only keeps the last 2 for the active
development branch - http://wix.sourceforge.net/releases/
unfortunately for you 3.5.1309.0 is 3 versions old.
If you're lucky someone might have 3.5.1309.0 lying around which they
can upload somewhere for you. Other than that
LaunchConditions are package wide hence are an all or nothing solution
(either you pass the LaunchConditions can attempt an install or you
trigger one or more don't get install anything). You can have Feature
Conditions or Component Conditions as Cody has shown below.
A Condition Element in the
http://msdn.microsoft.com/en-us/library/aa372457(VS.85).aspx
Palbinder Sandher
Software Deployment IT Administrator
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://wix.sourceforge.net/manual-wix3/heat.htm
Palbinder Sandher
Software Deployment IT Administrator
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
Either use something like dotnetinstaller
(http://dotnetinstaller.codeplex.com/ plenty discussion on this list of
it), wait for Burn to be feature complete or roll your own
bootstrapper.
Until Burn is ready I'm happy using dotnetinstaller it appears I'm not
the only one on this list. There are
http://wix.sourceforge.net/manual-wix3/shellexec.htm
Palbinder Sandher
Software Deployment IT Administrator
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.
Regular list contributor Neil Sleightholm wrote a pretty good article on
this topic -
http://neilsleightholm.blogspot.com/2008/08/customised-uis-for-wix.html
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
InstallUISequence runs before InstallExecuteSequence. If you change something
don't have a time machine handy would you expect to see it change before you
changed it?
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
Have you tried using heat.exe in WiX 3.0? The post you're referring to
is 3 years old which is very much pre-WiX 3.0. Unless there's some
requirement which means you can't upgrade to WiX 3.0 I'd strongly
suggest migrating. If you can't you could still try to use heat.exe to
generate the .wxs for
Unless you're pushing out .NET 4.0 Framework betas, you can't install
any earlier .NET Framework on Windows 7, they're already embedded into
it. I suggest looking at what your bootstrapper is trying to do when
it's launching your MSI as it sounds like you're attempting to do
something impossible
Install WiX 3.0 run WiXCop.exe on your .wxs files to upgrade them to
the WiX 3.0 schema.
Shouldn't need to do anything more than that although I would recommend
looking at the things WixCop.exe changes as you could potentially clean
up/tighten your code by removing and/or replacing some things.
, this
error detail may be helpful to d iagnose the failure: Unable to load
file: c:\TEMP\station.dll, error: 193.
Thanks
Lian
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Thursday, February 11, 2010 3:12 AM
To: General discussion for Windows Installer XML
Download WiX 3.5 take a look. See http://wix.sourceforge.net/releases/
for the latest releases.
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
In the words of Chandler Bing.
Can open, worms everywhere.
Palbinder Sandher
Software Deployment IT Administrator
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.
That's not what merge modules are for. Remove them from your installer
bootstrap the redistributable instead.
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual
Sounds like a bug in signtool.exe or one of its dependencies (if any) if
it works OK on smaller MSIs on the same machine.
Which version of the Windows SDK are you using? I'm using signtool from
the v6.1 SDK (have installed v7.0 but I've not gotten around to
modifying my build scripts as yet) but
Hi,
I've unfortunately made a bad decision a few months ago which is the
cause of this query.
We have an installer which we've released 3 versions of in the past. All
cosmetic changes to UI etc, components were unchanged between all 3
versions.
V1.0 v1.1 have product code A.
I (stupidly) released
, Simulate + Innovate 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
Are File Id's unique?
I'm impressed you can even get as far as light running the ICE's if you
have the same file in 2 components although quite how you managed that
is beyond me. Code snippets would be a big help as would pasting the ICE
errors from the build log.
Your approach sounds fine from
, Pally Sandher wrote:
Moral of the story, be absolutely certain when you're changing Product
Codes (still can't believe I made such an error, hoist by ones own
petard).
A higher-level moral: Test serviceability before shipping; afterward is
too late to fix whole classes of bugs. (Heath
Package Elements are children of Product Elements
(http://wix.sourceforge.net/manual-wix3/wix_xsd_package.htm). That's
what the error is essentially saying. You've tried to put a Package
Element under the WiX element.
You may want to get a basic knowledge of WiX before you try building
entire
Windows Installer won't allow concurrent installations as it's a
transactional system. Use a bootstrapper.
Also WiX != Windows Installer. WiX is a tool for making MSI's. Windows
Installer does all the actual installation work.
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0)
If you want to ship updates as MSP's (Small Update or Minor Upgrade in
Microsoft terminology) don't use auto-generated GUIDs. If you're only
ever going to ship updates as MSI's (Major Upgrades) you need to change
the Product Code every time anyway so auto-generating is fine. See -
The CopyFile element should do what want.
http://wix.sourceforge.net/manual-wix3/wix_xsd_copyfile.htm
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
I've seen people pushing MSI building packages which have buttons on UI
pages to launch stuff like .NET Framework installers, XNA etc. during
the InstallUISequence to bypass this issue. Personally I'd never do this
as when a sys admin pushes your package out across their domain your app
could
Make sure your RTF is a 'plain' RTF. Easiest way to do that is open it
in Wordpad save it. If you created or edited it in Microsoft Word it
will have a load of extra formatting all over it which causes problems
in ScrollableText Controls.
Are you using a stock WiX UI or a Custom/Customized one?
You're basically asking if the Component Rules exist if so how do they
work.
See http://msdn.microsoft.com/en-us/library/aa370561.aspx the pages
its last paragraph links to.
Rob M wrote some very good blogs regarding the above which I'd recommend
as further reading
The stock UI's only have one as described in the How To page
(http://wix.sourceforge.net/manual-wix3/run_program_after_install.htm)
however there's nothing stopping you modifying the ExitDialog in the
stock UI you're using to add anything you would like. Neil Sleightholm
wrote a blog post on
Add WiXUtilExtension as a Project reference (or supply it to light using
the -ext switch if you don't use a wixproj in Visual Studio) remove
your Binary Element below as it's not needed in WiX 3.0/3.5.
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0)
Upgrade to WiX 3.0/3.5 or write your own ShellExec custom action.
Palbinder Sandher
Software Deployment IT Administrator
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
Not without using a Custom Action to do it out with your installation
sequence. ExitDialog is shown after InstallFinalize (assuming successful
installation), WriteRegistryValues must be between InstallInitialize
InstallFinalize.
Palbinder Sandher
Software Deployment IT Administrator
T: +44
I'd suggest looking at what's causing the problem rather than assuming a
blanket upgrade to Windows Installer 4.5 as being a solution since
Windows Installer 4.5 isn't even pushed to Windows XP machines by
Windows Update, it's a manual upgrade. Considering I have people
complaining about things
I'd do something similar to the checkbox on the LicenseAgreementDlg. You can
find it in the WiX sources at
src\ext\UIExtension\wixlib\LicenseAgreementDlg.wxs (WiX sources distributions
can be found on SourceForge).
Disable the Next button on the dialog page where they select the installation
It's been a while since I used WiX 2.0 but I would check what your
Execute Impersonate attributes are for your custom action. AFAIK you
should set Execute=deferred Impersonate=no but I may be wrong as
it's been a long time since I've messed with UAC Custom Actions (Rob M
others on the list
Not using the standard Windows Installer UI. ScrollableText controls
don't have that sort of functionality.
You'd need to write your own UI replacement to achieve that.
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
1 - correct but by Vista you actually mean Windows Installer 4.0/4.5 as this
also applies to Server 2008 (Vista/2k8 RTM SP1 ship with Windows Installer
4.0, SP2 ships with Windows Installer 4.5).
2 - correct but again by Windows 7 you actually mean Windows Installer 5.0.
Same thing in practice
No.
What's the error heat.exe is giving you?
Palbinder Sandher
Software Deployment IT Administrator
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
Yes.
Remember to use -svb6 though.
Palbinder Sandher
Software Deployment IT Administrator
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.
Verbose log will show what msiexec is doing between clicking Repair or
Remove when it shows the Progress Dialog.
My guess is it's doing the stuff in InstallExecuteSequence before
InstallInitialize but I could be wrong. Since your installer appears to be
pretty large, checking all the stuff it
1 - 100 of 952 matches
Mail list logo
