OK it seems like you're tripping over the way that some attributes are
of the Formatted type, while others aren't (see
http://msdn.microsoft.com/en-us/library/aa368609.aspx )
If you want a Property to expand into the text it is set to during
install of your package, the type of the string you're pu
Long Answer:
SourceDir -> http://msdn.microsoft.com/en-us/library/aa371857.aspx
TARGETDIR -> http://msdn.microsoft.com/en-us/library/aa372064.aspx
Short Answer:
You can't/shouldn't unless you're doing an administrative installation
in which case supply it on the command line.
Why do you want to
Try setting Execute="immediate" if you don't need the Custom Action to
run elevated (see
http://wix.sourceforge.net/manual-wix3/wix_xsd_customaction.htm). Have
you set the Return attribute in your CustomAction Element & what are you
doing with the output from the SQL query? Code samples go a long w
1 - http://msdn.microsoft.com/en-us/library/aa372497.aspx
2 - Nope you'll have to do it the long way.
You'll need 2 MSI's if you want to access the 64-bit areas of the
registry on x64 platforms. MSI's are platform architecture specific.
Palbinder Sandher
Software Deployment & IT Administrator
T:
Sounds to me like your original package is installed in a per-user
context but your patching system is forcing everything to run as
per-machine. If you want to force a package to always be per-machine,
set InstallScope="perMachine" in your Package Element (see
http://wix.sourceforge.net/manual-wix3
http://wix.sourceforge.net/manual-wix3/wix_xsd_binary.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
What happens if someone uninstalls the app your add-on is for then
uninstalls your add-on?
Use RemoveFolder don't suppress any ICE warnings/errors.
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulat
iX-users] ICE64, can't use RemoveFolder
But then the uninstall will remove the folder even when the original
application is still installed.
On 4 August 2010 14:59, Pally Sandher wrote:
> What happens if someone uninstalls the app your add-on is for then
> uninstalls your add-on?
>
&g
You need to set the Win64 attribute on your components. If it's not set
they default to 32-bit components in an x64 package.
An easy way to do it is to use a pre-processor variable set to "no" or
"yes" whether you're building x86 or x64 packages respectively. Then you
can simply use something like
rs] ICE64, can't use RemoveFolder
No, I was just assuming since I've read that RemoveFolder is often used to
delete folders to which the application has added files manually.
On 4 August 2010 15:55, Pally Sandher wrote:
> Have you actually tested it & seen that behaviour?
>
>
Email Disclaimer
-Original Message-
From: Lukasz Zalewski [mailto:lu...@eecs.qmul.ac.uk]
Sent: 04 August 2010 15:52
To: General discussion for Windows Installer XML toolset.
Cc: Pally Sandher
Subject: Re: [WiX-users] msi upgrade problems per-user vs per-machine
contextfailure
Hi Palbinder
Use XMLConfig
(http://wix.sourceforge.net/manual-wix3/util_xsd_xmlconfig.htm) or
XMLFile (http://wix.sourceforge.net/manual-wix3/util_xsd_xmlfile.htm) to
modify the XML file during installation. You can pass the installation
directory as a Property in the Value attribute of your XMLConfig or
XMLFil
That looks OK if it's passing the ICE tests now as it's much like the
sample in the How to create a shortcut
(http://wix.sourceforge.net/manual-wix3/create_start_menu_shortcut.htm).
Shortcuts are still files as far as the file system is concerned so
copying that sample for your own needs should be
http://lmgtfy.com/?q=how+to+enable+windows+installer+logging
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 Scotla
Check a verbose log & see what's changing & when. Are you using Terminal
Services on the 2k3 server? Tempfolder is known to work differently from a
console session & a remote desktop session.
If you can't lock it down you may need to move the files to somewhere which
won't change like LocalAppDa
Any reason why you need to write to the Registry using a Custom Action
instead of using RegistryValue/RegistryKey elements? Using those would
leave msiexec to deal with elevation instead of you having to even think
about it. Sounds to me like your code doesn't follow UAC guidelines & is
failing for
What do those custom actions actually do?
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
R
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. Register
http://msdn.microsoft.com/en-us/library/aa367591.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.
1 - http://blogs.msdn.com/b/astebner/archive/2005/12/24/507294.aspx
2 - http://www.joyofsetup.com/2007/09/24/test-your-setups-virtually/
3 - Debug the failure & fix it so it doesn't fail?
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
h
Don't use Windows Installer, use something else like a self-extracting
archive or some non-Windows Installer installation development package.
What you're trying to achieve is pretty much contrary to the basic
concepts & function of Windows Installer.
Palbinder Sandher
Software Deployment & IT Ad
http://lmgtfy.com/?q=WiX+installing+an+assembly+to+the+GAC
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
pect
this sort of functionality to be a 'given' in any Installer Framework.
Regards,
Jamie
On 11 August 2010 15:02, Pally Sandher wrote:
> Don't use Windows Installer, use something else like a self-extracting
> archive or some non-Windows Installer installation development
pa
Simply use [%Environment_Variable] as a Property. See ->
http://msdn.microsoft.com/en-us/library/aa368609.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 Env
older, as reflected in the property, is then created by
the installer.
Thanks,
Lionel
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: 11 August 2010 16:36
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Environment variables
http://lmgtfy.com/?q=WiX+Tutorial
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
I think your actual error may be happening earlier in the log than the pasted
section. According to MSDN there is no error 1625 ->
http://msdn.microsoft.com/en-us/library/aa372835.aspx
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
ht
Our illustrious/humble benefactor Rob M. wrote a blog entry on this very
topic a few months ago ->
http://robmensching.com/blog/posts/2010/5/2/The-WiX-toolsets-Remember-Pr
operty-pattern
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
h
Or just use the Date Property ->
http://msdn.microsoft.com/en-us/library/aa368261.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 Li
http://msdn.microsoft.com/en-us/library/aa372379.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.
Make your MSP's uninstallable?
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 Of
Yes you can use it to empty a directory & delete the directory itself but you
need to specify the directory/directories to empty. It can't do the equivalent
of "DEL /S". If you will always know the directory structure then use
RemoveFile table entries using the RemoveFile & RemoveFolder Elements
You should be able to achieve something similar in Votive maybe using
pre-processor definitions if you can't simply exclude files from the build.
However I make extensive use of Fragments & ComponentRef, ComponentGroupRef,
FeatureRef & FeatureGroupRef's to avoid duplicating any code where ever
ComponentRef, ComponentGroupRef, FeatureRef and/or FeatureGroupRef are
all fine with Fragments if the components are mostly changing for each
build. You only *really* need wixlibs or merge modules if you're sharing
installer development with other teams/people or if you need to save
yourself some b
1 - not without forcing your package to be Windows Installer 5.0 only.
Windows Installer 5.0 is only available on Windows 7, there's no
redistributables for any earlier versions of Windows. If you're happy
with that, knock yourself out.
2 - see above.
Palbinder Sandher
Software Deployment & IT Ad
,
Chunlin
-----Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Monday, August 23, 2010 3:44 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] MSP uninstall issue related to update shared
files
Make your MSP's uninstalla
90 projects & old hardware is my guess.
We have 120 projects across 3 solutions which takes my Core 2 Q6600
approximately 25 minutes to build from a command script. The C++, C# &
Fortran projects are done in the first 15 minutes & the installers take
the last 10 (could optimize more by using more
That is the correct solution. Heat.exe exports COM from .NET assemblies
without issue for anything I've given it including DLL/TLB pairs.
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
The answers are still the same as they were last week when you asked
this unless I've missed some massive Installation Development
announcements recently.
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Si
Why not author the hardware checks etc in the DLL rather than have a DLL
call an executable & then set the property?
There is a way to do what you are trying to do which involves extracting
both files to a known location & then cleaning up afterwards but it
seems a bit overly complex for your requi
Pre-reqs of *your* software are *your* fault. Your development team implemented
the specs which make your product require the crap packages. The ability not to
use them is fully within your control. This sounds a lot like sloping shoulders
syndrome.
I have personally fixed things like that myse
Try
As per the example at
http://wix.sourceforge.net/manual-wix3/create_start_menu_shortcut.htm
Also you shouldn't need the Win64 attribute on your Components except
for those which are 32-bit components in a 64-bit package. See
http://www.joyofsetup.com/2010/05/14/working-har
You can also follow the procedure listed at
http://support.microsoft.com/kb/223300 to enable logging for all Windows
Installer transactions.
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innov
If your application depends on another manufacturers package & they
don't provide merge modules for your package to consume, the best option
is either using LaunchConditions to block installation & leave the user
to install the packages or bootstrap the pre-requisites before your
package (or do bot
Use heat.exe to harvest the Assembly.
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 Li
http://lmgtfy.com/?q=WiX+how+to+use+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 **
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456
How are you getting CheckCPU.exe onto the target system? You may want to
change your Custom Action to a Type 2 rather than a Type 50 as it
appears you're trying to do if your supplying the CheckCPU.exe
application inside your package. Custom Action types are listed at
http://msdn.microsoft.com/en-u
In that case are you sure the MSI is finding the CheckCPU.exe
application to run it (check a verbose log)?
Actually I think I see what the problem is.
You're using DirectorySearch & FileSearch to set the path to the Custom
Action. This doesn't happen until AppSearch as you'd expect so you can't
ru
Put the long name in the Name attribute & drop the use of the LongName
attribute as it's been deprecated since WiX 3.0 was created. WiX will
generate a short name at compile time if you put a long name in the Name
attribute or you can use the ShortName attribute to specify it if you
feel the need.
Care to elaborate on why it's not easy to implement in dotnetinstaller?
Personally I'd ignore XP SP2 as SP3 has been out for 2 years+ so the
only thing you'd need to do is target Server 2003/XP 64 for the WIC
redistributable before the .NET 4 Framework. I could write the XML for
that in under 5 min
Try using the -suid switch when you run heat to get more readable ID's
generated rather than 'reg06989E0C50B7888525E711A46A9A609B'.
The code you've pasted isn't the problem. The error message says you've
got duplicated Id's in the RegistryTable, it has nothing to do with
Class & Prog Id's. Make sur
Bootstrap it as a pre-requisite instead & save yourself the hassle. Any
half-decent bootstrapper will do exactly that & your installer will never have
to even know about DirectX other than maybe a LaunchCondition to check it is
installed.
See dotnetinstaller -> http://dotnetinstaller.codeplex.c
Most people use a LaunchCondition
(http://wix.sourceforge.net/manual-wix3/wix_xsd_condition.htm) checking
a Property (http://wix.sourceforge.net/manual-wix3/wix_xsd_property.htm)
filled by a RegistrySearch ->
http://wix.sourceforge.net/manual-wix3/wix_xsd_registrysearch.htm
If you can't use Registr
suid switch. The
reg06989...
seems to be an id
that is generated by candle, I can only find it in setup.wixobj.
Should I post process the obj file and change certain id's and enforce
uniqueness to fix this ?
Thanks,
JB
2010/9/13 Pally Sandher
> Try using the -suid
Condition the components with "NOT VersionNT64".
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.
SC151
on for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Howto remove files before Installer terminates
Hi Pally,
I am already using dotnetInstaller (my App requires dotnetFX 2.0), but I don't
see, that dotnetInstaller could be of special help with DirectX ?
Regards
Peter
-U
http://www.tramontana.co.hu/wix/lesson6.php and/or
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 S
http://www.tramontana.co.hu/wix/
Knock yourself out.
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.
That seems like a rather nebulous requirement. In my experience packages
either live side-by-side with older versions or they upgrade older
packages, not both. I don't think it's going to be easy conditionally
doing either using default Windows Installer behaviour.
The Upgrade Table allows you to
Try changing your conditions to
(LEGACY_APPDATA) AND (WixUI_InstallMode = "InstallCustom" OR
WixUI_InstallMode = "InstallTypical" OR WixUI_InstallMode =
"InstallComplete")
and
(NOT LEGACY_APPDATA) AND (WixUI_InstallMode = "InstallCustom" OR
WixUI_InstallMode = "InstallTypical" OR WixUI_InstallMode
Sounds to me a lot like the symptoms of Component Rules violations.
Are there any common files, registry keys, etc. between feature1 &
feature2? If so have you duplicated the code for them? What's a verbose
log show when you do the Change operation? Does it try to start the
service & fail or does
ck and the second click..
Mark.
On 17/09/2010 12:53, Pally Sandher wrote:
> Try changing your conditions to
> (LEGACY_APPDATA) AND (WixUI_InstallMode = "InstallCustom" OR
> WixUI_InstallMode = "InstallTypical" OR WixUI_InstallMode =
> "InstallCo
egisty value is not set), and it only does it on the
SetupTypeDlg - I have the same check in CusomizeDlg.
Mark.
On 17/09/2010 16:29, Pally Sandher wrote:
> I didn't expect that to help much to be honest. WiXUI_InstallMode
> isn't being set until you click the button the fir
IIRC I had similar issues when attempting to create patches using the
Pyro method in WiX 3.0 hence I've stuck with the PatchWiz method. I'm
sure if I stuck at it I could probably work out what's going wrong when
I try using the Pyro method but since I have a method which works
there's not much ince
To answer Grant's query, the official & recommended method is that you
need to use separate x86 & x64 packages. Windows Installer won't let an
x86 package write to x64 file & registry locations as you've seen (logs
will show WIN64DUALFOLDERS modifying any property which references an
x64 location w
they
downstream it all the way to atleast Vista when they do otherwise it becomes
one of those "that's nice but doesn't help me at all" features.
Chris
Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know
a secret or read a really good thread that
Or do it the right way & use the CopyFile element ->
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 **
Integrated
You can use the LIMITUI property
(http://msdn.microsoft.com/en-us/library/aa369759.aspx) to force basic
UI but to force no UI would require running msiexec with the /qn switch
some how which generally requires a bootstrapper.
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 141
ltiple folders
Hi:
Ok, given that I won't know the number of files that need copying before
the installation starts. Given this is the situation, is it better to
populate the DuplicateFile table from a custom action?
Any help appreciated.
Sean.
-Original Message-
From: Pally Sandher
ide which files to
includein msp?
On 20-Sep-10 06:44, Pally Sandher wrote:
> IIRC I had similar issues when attempting to create patches using the
> Pyro method in WiX 3.0 hence I've stuck with the PatchWiz method. I'm
> sure if I stuck at it I could probably work out what'
You have to reference the "F.Plugin.Users.Sync" Feature in the
"F.Plugin.Users" Feature (as this is referenced in the "F.Plugins"
feature) for that tree to work.
As Bob A says, the problem here is your trying to refer to a parent
feature in a child fragment & WiX doesn't work like that (references
Windows Installer makes calls to the Cabinet API to decompress your cab
files. Other than using multiple cabs in your package I don't think
there's much you can do to change Windows Installer behaviour using WiX.
As the first read to the start of the cab file isn't always at the same
place & is alw
It may be caused by the use of "." in your ElementPath's. XPath syntax
uses "." to select the current node. See ->
http://www.w3schools.com/XPath/xpath_syntax.asp
Also if you're editing/modifying/creating attributes of your XMLConfig
elements, use ElementId to refer to them. See ->
http://wix.sour
Set Transitive="yes" on those Components ->
http://wix.sourceforge.net/manual-wix3/wix_xsd_component.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 Environm
What you actually want is a Type 2 Custom Action as there's no other
type which can target an executable in a Binary Stream such as
This is covered in the tutorial at
http://www.tramontana.co.hu/wix/lesson3.php#3.2
[#Foo.bin] refers to a File Id. If you're not installing Foo.bin you
can't use it.
I've read seems to indicate that it should work so I'll look
over it all again - but in the meantime, here is what I have:
INSTALLDESKTOPSHORTCUT
And in the feature:
..
..
I must be missing something.
Thanks,
Mark.
--
On 23/09/2010 12:19, Pally Sandher wrote:
Use a bootstrapper to install Ruby before your installer runs.
Concurrent installations are highly dangerous & just as unsupported.
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
Use properly supported methods instead of self-reg.
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.
SC
Try removing the ConfigurableDirectory attribute from all but your top
level feature. I think that could be confusing Windows Installer about
where to put the sub-features. Could be wrong though but it's worth a
try.
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500
You'll need to write your own bootstrapper or ExternalUI rather than use the
built in Windows Installer UI.
Burn will eventually offer something similar to that experience from what I've
heard/read but until it's done (which could be a while yet) your only option is
to roll your own. dotnetinst
http://msdn.microsoft.com/en-us/library/aa372432.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.
Try wix-d...@lists.sourceforge.net rather than the user list.
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 Scotl
Not with WiX.
I've seen other installation creation suites doing something like that
but you'll need to buy licenses to use them.
Windows Installer needs every file declared within the MSI for it to be
able to install them, any package which doesn't require you to do this
yourself is simply abstra
"The service executable installed will point to the KeyPath for the
Component. Therefore, you must ensure that the correct executable is
either the first child File element under this Component or explicitly
mark the appropriate File element as KeyPath='yes'."
>From the "Remarks" section at
http://
WiX v3.5 isn't technically more stable than WiX v3.0 (in development
beta code versus released final code) but if you want to use VS2010 you
have to use WiX v3.5 as VS 2010 didn't exist when WiX v3.0 was released.
Having said that unless you're using the new features in WiX v3.5 such
as IIS7 or .NE
Does the Windows 7 logo testing suite come with new ICE .cub files which
are more lenient for ICE43 & ICE57? I have code as below for All User
Start Menu shortcuts in an All User package & it passed logo testing but
that was around 6 months ago so the test suite has probably been updated
since then
Use a bootstrapper.
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 - Hel
The WiX bootstrapper "Burn" is in development for v3.6. Until then you
can either use something like dotnetinstaller
(http://dotnetinstaller.codeplex.com/), SharpSetup
(http://sharpsetup.eu/) or a commercial package.
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500
Is the upgrade shipped as an MSI or an MSP? I've seen that happen with
MSP's when doing stuff like deleting files from the new version without
authoring an appropriate RemoveFile.
If it's an MSI are you using a bootstrapper to deploy it or just the raw
MSI?
Palbinder Sandher
Software Deployment
The installer comes with WiX.chm as I expect the binaries do too.
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 S
I use dblock's dotnetinstaller to do exactly that (although my secondary
MSI is more of a pre-requisite rather than being optional).
http://dotnetinstaller.codeplex.com/
The way I could think of doing it using MSI only is with using an
external cab to provide the files of the optional component &
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 - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaim
It doesn't as far as I know unless you store the it in
ARPINSTALLLOCATION. You can't use that method for any other properties.
If you're not explicitly putting it in there then you're likely seeing
the same default path being generated whenever you run your MSI.
If you want to store & retrieve you
Patches don't have versions. The version would be the ProductVersion of
the new version your patch is upgrading the old version to.
I don't quite understand your question regarding passing properties to
Custom Actions. Can you elaborate on what you're trying to do?
Palbinder Sandher
Software Dep
houghts on this?
Regards,
Henk Roos
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Tuesday 16 November 2010 13:13
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching and properties
Patches don't have versions. The ve
Are you building an x86 & x64 MSI because you can't have the same MSI
install to both the x64 Program Files & the x86 Program Files.
An x86 MSI on an x64 platform will always install to "Program Files
(x86)", you can't target x64 specific directories from an x86 MSI &
MSI's must be platform specifi
In that case I don't see anything wrong with your Type 35 custom
actions.
Have you tried setting the Names on your Directories to something else &
checking a verbose log to see whether the Custom Actions are actually
trying to do anything. You pasted code makes it difficult to tell
whether the def
Use a Launch Condition. If you can use a RegistrySearch to set a
Property when Chartfx is installed you can use that as your Condition
(remember to add "OR Installed" to the condition in case someone
installs your app then uninstalls Chartfx).
Palbinder Sandher
Software Deployment & IT Administra
It really depends on what you're trying to achieve. You can use * for
Component GUIDs which means they'll be auto generated at compile time
which should work for most situations but there are times when that'll
not work as you intend & you may find yourself having to hard-code some
of the GUIDs.
T
Because you're using LicenseAgreementDlg
already has Publish events for the Next button set up. To make it work
like you would like see
http://wix.sourceforge.net/manual-wix3/WixUI_customizations.htm section
headed "Inserting a custom dialog into a built-in dialog set" and/or
http://neilsleighthol
501 - 600 of 1015 matches
Mail list logo
