What are you setting REINSTALL to?
REINSTALL="Feature1,Feature2,Feature3NewFeature" should work. You
will need to reference all your Features individually as REINSTALL="ALL"
only installs those features previously installed (hence the new one
will be ignored since it didn't exist previously to
There is no "Uninstall Sequence". InstallExecuteSequence
(http://msdn.microsoft.com/en-us/library/aa369500.aspx) &
InstallUISequence
(http://msdn.microsoft.com/en-us/library/aa369543.aspx) run during
Install & Uninstall (and Modify/Repair/etc) unless actions within them
are conditioned appropriatel
You can safely ignore them. They're caused by having either of the VC++
runtime merge modules consumed by your MSI. It's not an artifact of
having both v8.0 & v9.0.
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
*
Any file you put on the machine during install will be removed during
uninstall unless you specifically say not to.
Same goes for any directories created during install as long as they are
empty when msiexec tries to remove them. If your application has created
any logs or configs in those directo
If you're referring to the Microsoft platform testing, those tests are
flawed. They failed an MSI of ours due to having a null entry for
VersionMax in an Upgrade Table entry even though the MSDN documentation
on Windows Installer tells you to do this if you want to check for all
versions greater th
1 - References are probably Visual Studio's doing since you have your
projects all in the same solution. Dark simply creates XML from an MSI,
it doesn't create a .wixproj or modify any .sln.
2 - yes you should be using heat.exe to harvest your .NET assemblies.
3 - Surprisingly you'll find informa
LOGDIRECTORY is a Property not a variable & since it's all upper case
it's a Public one
(http://msdn.microsoft.com/en-us/library/aa370912.aspx). Essentially
Properties are Windows Installers variables but you can use variables in
WiX so confusing the two now might cause you problems later on.
I th
You have to individually include each file into the installer. However
there's a quick way to do that called heat.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 **
Integr
Sounds like the 1.0 & 1.1 MSI's have different Product Codes. Did you
implement major upgrade functionality for 1.0 MSI -> 1.1 MSI? I had this
exact same problem as I'd released v1.0 & v1.1 of a product with the
same Product Code then released v1.2 with a different Product Code so I
could add major
I'm looking into your suggestion of making one patch for each msi and
then merging them to make one that will work for both. I'll let you know
if I make progress!
Thanks,
Richard
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: 25
MSI's themselves are built for either x86 or x64 platforms (or Intel64 aka
Itanium but they're so rare it's not worth mentioning).
Build your MSI for x86 as you normally do & if a user tries to install it on an
x64 system msiexec/WoW will take care of it.
Ignore everything Harshil says, you don'
nts to 1.2 and from
there everything should work great.
Thanks for your help! This should now work for me going forwards.
Regards,
Richard
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: 25 March 2010 10:53
To: General discussion for Windows Installer XML
Use a bootstrapper to install the redistributable from Microsoft which
updates that file to the version you require before you install your
MSI. Any other solution has massive potential for problems.
If you're looking for a bootstrapper I recommend dotNetInstaller ->
http://dotnetinstaller.codeple
und so I can stop causing myself
problems in the future, so thanks a lot for your help!
Many thanks,
Richard
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: 25 March 2010 11:59
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-us
would be.
>
> What would probably solve my problem is being able to have a separate
> directory tree, defined in a separate fragment from the base directory
tree.
> I'll go read that tutorial and see if that gets me further.
>
> Thanks!
>
>
> On Wed, Mar 24, 2010 at 4
1 - post your WiX code for creating the Registry Entries otherwise we're
all just guessing at the problem. Also extracts from a verbose log when
the registry entries are created on the machine with the problem may
also help.
2 - Which other systems have you tested? Is it fine on x64 Vista? What
ab
you get a chance to install your x86 msi on 64 bit OS, please share your
results with me. It will help me in future.
-- H
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Thursday, March 25, 2010 5:21 PM
To: General discussion for Windows Installer XML tool
The uninstaller fails your Launch Condition because when you remove it
using Add/Remove programs it runs in basic UI which I'm guessing means
the UILevel != 5. It should probably work if uninstalled using the MSI
itself by running "msiexec /x " but you may need to append
"/qf" to that command to fo
UI works fine for uninstall. Your problem is that when uninstalling from
Add/Remove programs it automatically runs in basic UI. You need to find
some way of changing this behaviour. MSDN is probably a good place to
start.
Also don't cross post to the wix-dev list. Like the majority of
questions on
Use LocalAppDataFolder
(http://msdn.microsoft.com/en-us/library/aa369768.aspx) not
AppDataFolder (http://msdn.microsoft.com/en-us/library/aa367565.aspx)
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simu
Tallow.exe in WiX v2.0 should be able to harvest the registry entries
required for COM registration (assuming the DLL exports
DLLRegisterServer function). Tallow.exe is with the WiX v2.0 equivalent
of heat.exe in WiX v3.0. I don't have a WiX v2.0 install lying around
but running "tallow.exe /?" sho
This came up with someone else a few months ago. As the error message
says make sure the Windows Installer service is running and accessible
by the user account running the build process on the build machine. The
other chap was running some sort of restricted account or something
which didn't give
Considering there's absolutely no registration information in your
fragment I'm not surprised it's not registering the DLL.
Heat will only harvest what DLLRegisterServer does. If your DLL doesn't
export that function & uses some random custom method for COM
registration instead then heat has no id
What happens if your Q&A find bugs in your application? Do you fix those
in the installer too?
Use a Component Condition on your RemoveFile so it doesn't get touched
during major upgrades. However the copy procedure Sascha explained to
would be outside of the installation process. If you do it wit
Don't use advertised shortcuts.
http://wix.sourceforge.net/manual-wix3/create_start_menu_shortcut.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 **
Integrated Environmen
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 **
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC15
Can you paste the section of your Directory tree where you reference
INSTALLDIR? The UI sections appear to be OK as they look the same as the WiX
ext sources so I don't think that's where the error is being caused. Since
WIXUI_INSTALLDIR is mapped to INSTALLDIR it's likely that's where the probl
For username you could try passing the USERNAME or LogonUser property to
your custom action
(http://msdn.microsoft.com/en-us/library/aa372385.aspx &
http://msdn.microsoft.com/en-us/library/aa369780.aspx). That may also
give you the domain but as the MSDN pages don't tell you what the format
of thos
What Alex means is you can set the ARPINSTALLLOCATION property
(http://msdn.microsoft.com/en-us/library/aa367589.aspx) to do that for
you using a type 51 custom action. The following code should work for
you Thomas:
That will (should) set the "InstallLocation" value under
H
Yes you have to modify the Directory identifiers in the Fragment
generated by heat in your example. You don't need to use the Fragment
Element if you don't want to, you can copy the code into your Directory
tree if you wish. Personally I only use 1 Product/Fragment per file to
separate my WiX proje
First question would be "Why?"
You could do something like that by engineering a rollback right at the
end of the installation but you're trying to do something so bizarre
I've no idea where you'd even begin. I guess you could have a Custom
Action at the end which intentionally fails to start the
You only need to put that code into your newer releases which will be
doing the upgrading e.g. v1.0.0.1
Your v1.0.0.0 has nothing to upgrade so the code isn't needed. I'd
suggest commenting it out for your first release so you can add it back
for subsequent releases.
You may find that code doesn't
Be as pushy as you like. Bear in mind everyone who replies to queries on
this list is doing it *voluntarily*. None of us get paid in anything
other than kudos or a feeling of self-fulfilment for spending our time &
using our knowledge to answer your queries. If people don't know how to
help you fix
Which language code are you using in your Product Element?
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 **
Integrated Environmental Solutions Limited. Registered in Scotlan
Posting this in case anyone else runs into this & because I'm not sure
if this is a bug or expected behaviour.
I'm updating a plug-in installer to work with a new product which will
be imminently released. After (at least) 4 years of complaining the
developers of said product have caved in & final
http://wix.sourceforge.net/manual-wix3/patching.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 **
Integrated Environmental Solutions Limited. Registered in Scotland No.
S
You're in the right area with that code. I do something similar for a
plug-in installer using the following:
You may find it easier to build the Directory tree under A
RegSpy2 may be able to help. See
http://www.installsite.org/pages/en/msi/tips.htm about 1/3 down the
page. It'll output a .reg file which you run through tallow.exe to
output WiX code.
However I would ask the vendor of this adxloader.dll for support first.
Palbinder Sandher
Software Deployment &
Tell candle.exe where to find WiXUtilExtension.dll like it says.
Adding ' -ext "C:\Program Files\Windows Installer XML
v3\bin\WixUtilExtension.dll" ' should work assuming you have WiX v3.0
installed to the default location on a 32-bit O/S.
Palbinder Sandher
Software Deployment & IT Administrator
1 - not possible using Windows Installer. You need to use a bootstrapper
to sequence installation of multiple products.
2 - Sounds simple enough.
3 - Someone else with experience of installing & configuring SQL
databases with WiX will need to answer as I've never had to do this
myself (as yet).
CDATA is allowed in Properties & you can set the Value attribute of a
RegistryValue or RegistryKey to a Property.
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 **
Integrated
That sounds pretty bizarre. Which bootstrapper are you using which is
causing that? A bootstrapper should either simply ShellExecute your MSI
or call msiexec.exe /i (which amount to the same thing essentially). I
don't think you can set something like "Installed" on the command line,
AFAIK only pub
A quick check in dependency walker (http://www.dependencywalker.com/) of
any of the WiX v3.0.5419.0 binaries shows them needing mscoree.dll
version 2.0.50727.x so yes you need the .NET 2.0 Framework installed.
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500
F: +
I use a private key to sign my MSI's (.pfx file) & it works fine in
Votive using the "Post-build Event Command Line" section in the projects
property page if you use Visual Studio to build your MSI's. I build
using both the IDE & devenv.exe in a command script with no problems.
Palbinder Sandher
eem right passing the buck completely given that I can cause
the error without their bootstrapper.
Rob
On 06/04/2010 16:51, Pally Sandher wrote:
> That sounds pretty bizarre. Which bootstrapper are you using which is
> causing that? A bootstrapper should either simply ShellExecute your
MSI
> or
You don't need a Custom Action DLL.
Use a RegistrySearch to detect installation of IIS 6.0 (search the mail
archives, other people have posted what they use to do this reliably)
then condition the Publish tags which show your dialog with this
Property.
e.g.
NOT DETECTIIS6
DETECTIIS6
What doesn't work? What does a verbose log tell you about the things
which don't work?
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 **
Integrated Environmental Solutions Li
Put a greater than '>' before the equals in your condition?
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 **
Integrated Environmental Solutions Limited. Registered in Scotlan
http://msdn.microsoft.com/en-us/library/aa367588.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 **
Integrated Environmental Solutions Limited. Registered in Scotland No.
Properties should be set after msiexec parameters. Move the "/lv*!
install.log" to before you declare your properties.
If that doesn't work try without the # in your properties or try
changing the Feature Level to something arbitrarily high like which
will be above your standard INSTALLLEVEL.
Easy way to do it would be to condition the WelcomeDlg in the
InstallUISequence with "NOT Installed AND NOT PREVFOUND".
Then you could make a new dialog (make the buttons a copy of the
VerifyReadyDlg ones so you get UAC shields where appropriate) &
condition it with "Installed AND PREVFOUND" so it
Your "temporary workaround" sounds like the proper solution. Allow
Windows Installer to request elevation if/when required rather than
forcing it everywhere from the start. If you're using a stock WiX UI
your user will be prompted with a UAC shield on the VerifyReadyDlg
before the elevation request
Look at the InstallUISequence of your built MSI (sort by sequence).
You'll see only MaintenanceWelcomeDlg, ResumeDlg & WelcomeDlg sequenced
before ProgressDlg so conditioning the WelcomeDlg appropriately will
also skip all the dialogs it calls if it is skipped since the user never
clicks on the nex
APPFOUND="false" is wrong. Just use APPFOUND.
This is covered in the tutorial extensively ->
http://www.tramontana.co.hu/wix/lesson1.php#1.4
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Inno
Windows Installer only removes empty directories during install. If your
application dirties those directories during execution & doesn't clean
up after itself, you'll need to do it yourself in your MSI or fix your
application to write to somewhere under CommonAppData or LocalAppData
(or some other
ronmental 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: 09 April 2010 10:48
To: General discussion for Wi
Windows Installer only uses the first 3 fields of version numbers so you
can change the 4th one as much as you'd like. See ->
http://msdn.microsoft.com/en-us/library/aa370859.aspx
Personally I stay away from Small Updates for this reason. Minor
upgrades work just as well with no ambiguity.
Palbin
Something like the following should work:
...
That assumes your old application will be under ProgramFilesFolder so
modify as appropriate.
You could condition the Feature for those components using somethi
You're trying to install on a system which already has that product
installed.
Stop using the same product code for all your products if they are
different products.
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
arch runs
each time the MSI gets installed (which was actually what I liked to
ask)?
> -Original Message-
> From: Pally Sandher [mailto:pally.sand...@iesve.com]
> Sent: Freitag, 9. April 2010 12:29
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-us
InstallPrivileges can only be set to either "limited" or "elevated". I'm
assuming you mean InstallScope in which case yes that's all it does
according to the documentation ->
http://wix.sourceforge.net/manual-wix3/wix_xsd_package.htm
How are you elevating the MSI on UAC systems? Are you elevating
Everyone on this list with the exception of Rob M, Bob A & the rest of
the core WiX dev team was a beginner with WiX at one time. However a
large number of people (myself included) took it upon themselves to
learn about the tools they're trying to use. Most of us would've done
that by going through
http://neilsleightholm.blogspot.com/2008/08/customised-uis-for-wix.html
You may find http://www.google.com a useful resource in future.
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
-Original Message-
From: Viv Coco [mailto:vcotirl...@hotmail.com]
Sent: 12 April 2010 12:05
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Remove the license page
Thx a lot for the link!
Viv
On 4/12/2010 12:30 PM, Pally Sandher wrote:
> http://
An easy workaround would be to create child Features under your main
Feature to split the components up into smaller chunks without affecting
the functionality. If your components are within separate Fragments you
could consider creating FeatureGroups containing the Components in each
Fragment & re
Use v3.5
Bob Arnson answered this exact same question on Thursday last week
(subject: Wix 3.0 with VS2010).
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 **
Integrated Envir
http://msdn.microsoft.com/en-us/library/aa367750.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 **
Integrated Environmental Solutions Limited. Registered in Scotland No.
You can use a LaunchCondition with the NETFRAMEWORK35 Property in
WixNetfxExtension to check for .NET 3.5 Framework
(http://wix.sourceforge.net/manual-wix3/wixnetfxextension.htm)
Non-administrator users can't write to ProgramFilesFolder so author your
installer to default to LocalAppDataFolder
(ht
Your XMLConfig code looks correct so it appears your IISROOT property
isn't being set. Check a verbose log.
Also there may be a property in IIS Extension which does the searching
work for you. However seeing as I can't even find IISMAJORVERSION &
IISMINORVERSION anywhere in the v3.0 WiX.chm you ma
The first example (Property Id="JDK32") will work for both x86 & x64
platforms. The second property is unnecessary. Modify the example
LaunchCondition appropriately.
MSI's must be authored for x86 or x64 platforms. x86 MSI's will install
on x64 systems & be redirected to the WOW64 areas automatica
Modify your WiX element in wixImsClient.wxs to
http://schemas.microsoft.com/wix/2006/wi";
xmlns:difxapp="http://schemas.microsoft.com/wix/DifxAppExtension";>
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design
Crashing & hanging are 2 very different things, confusing them will
cause you a lot of problems. It doesn't even sound like this is hanging,
it's just taking time to do the operation & you're not patient enough to
wait for it.
Windows Installer & WiX are also 2 different things. If you have Window
As far as I've been able to explore, you can't write to x64 areas of the
registry in an x86 MSI. You can however read from them using RegistrySearch's
with Win64="yes" (although this causes ICE80 warnings).
Thomas to do what you want to do you'll need 2 MSI's, one for x86 platforms &
one for x6
Use XMLConfig 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 **
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456
Registered Office -
Your error says that the variable "WixSchedFirewallExceptionsInstall" is
undefined.
It works for en-us as from looking at the sources there is an en-us.wxl
compiled into the WixFirewallExtension.dll which contains
Configuring Windows Firewall
I suggest downloading the WiX v3.0 sources & usin
Just as an example I decided to try this out with a large installer of
ours (900 MB uncompressed, 400 MB MSI with embedded CAB).
With a single Media Element (CompressionLevel="high") it took 23 minutes
to build (approximately).
As I've a quad core CPU (Intel Core2 Q6600 running at stock 2.4 GHz p
Check a verbose log.
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 **
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456
Registered Office - He
Not possible. Rollback Custom Actions executed differently to normal
ones so you will need both. See ->
http://msdn.microsoft.com/en-us/library/aa371369.aspx
Also you don't need an Execute attribute on Type 51 custom actions.
They're only setting properties so they happen immediately anyway.
Pal
Trying to reference a Property in a RegistrySearch which sets that
Property would do that.
Your original code:
I wouldn't expect Windows Installer to support recursion in that manner
(or at all, it's a transactional system).
Also you can reference environment vari
Turn verbose output on in your project or run light.exe with -v if you
don't use votive & check the logs?
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 **
Integrated Environm
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
**Design, Simulate + Innovate with the **
Integrated Environmental Solutions Limited. Registere
Don't take this personally but this discussion should really be on the wix-devs
not wix-users.
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 **
Integrated Environmental Solu
Merge modules (.msm) can be used by any MSI building package. They are
the Windows Installer version of libraries. See
http://msdn.microsoft.com/en-us/library/aa369820.aspx
Wix Libraries (.wixlib) are only usable by WiX AFAIK. See
http://robmensching.com/blog/posts/2008/10/10/What-are-.wixlibs-and-
http://msdn.microsoft.com/en-us/library/aa370912.aspx (short version: by
Windows Installer design).
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 **
Integrated Environmental
ited. 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: 27 April 2010 12:28
To: General discussion for Windows Installer XML too
You have to do it manually.
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 **
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456
Registered Offic
heat.exe /? goes a long way
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 **
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456
Registered Off
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 + Innovate with the **
Integrated Environmental Solutions Limited. Registered in Scotland No.
Build an x64 package to write to x64 areas of the registry. You can't do
it in an x86 package. Nothing to do with WiX, Windows Installer
limitation.
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate
is used in our open
source CA as well; look into the source and maybe it'll set you on the
correct path
:)
You can found it here: http://madbutcher.dyndns.org/snippets/SQLMsiCA
Regards,
Albert van Peppen
- Original Message -
From: "Pally Sandher"
To: "General discussion
Good luck with changing the UpgradeCode every time you build. You may as
well just remove it instead as it's about as useful as a chocolate
fireguard with that requirement.
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.ie
Don't use Self-Reg?
You can't modify that error dialog unless you have the ability to start
re-writing parts of the operating system.
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 wi
Condition the InstallDirDlg Events with "NOT Installed" & it will only
show during the first install, not upgrades.
See
http://neilsleightholm.blogspot.com/2008/08/customised-uis-for-wix.html
if you need help modifying the stock WiX UI sets.
As long as you use a RegistrySearch to set INSTALLDIR ap
Post your Directory Tree where INSTALLDIR is used (not the entire thing
just a decent snippet) & the Property element you use for
WIXUI_INSTALLDIR.
Your RegistrySearch looks fine but the Custom Action may not be
necessary (also you need a capital C in LaunchConditions).
Palbinder Sandher
Softwar
Code samples would help us help you.
Also that tutorial refers to Major Upgrades. Small Updates & Minor
Upgrades are built, shipped & applied in a different manner. See ->
http://msdn.microsoft.com/en-us/library/aa370579.aspx
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 14
1 - yes write your own external UI instead of using Windows Installer.
2 - No idea, ask Microsoft. My guess is because installing something on
a removable drive which puts entries in registry for ARP & other stuff
isn't going to be well received by the O/S when the removable drive
isn't connected.
You can't in that case. Use a different RegistryValue for the KeyPath of that
directory if you need that one to persist in certain situations (try something
like ).
Move that one to it's own Component & add the requisite Condition Element.
Palbinder Sandher
Software Deployment & IT Administra
I don't think you understand what KeyPaths are. Every Component has a KeyPath.
WiX hides this from you most of the time by picking the first File or
RegistryKey/RegistryValue in a Component & making it the KeyPath for that
Component unless you explicitly tell it otherwise. See ->
http://msdn.mi
Just looked at a couple of their tutorials from that link.
The one for installing a COM DLL
(http://www.dalun.com/wix/02.03.2005.htm) uses self-reg which has never
been a good idea.
The one for adding a License Agreement dialog
(http://www.dalun.com/wix/02.18.2005.htm) they decompiled an existing
http://msdn.microsoft.com/en-us/library/aa368276.aspx
Not possible without some serious custom coding.
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 **
Integrated Environmen
201 - 300 of 1015 matches
Mail list logo
