Thanks Blair.
I set ALLUSERS to 1 in order to install to c:\program files by default
in both setups.
Anyway you're right: I actually don't need a per-user installation.
What I'm looking for is an option to make the program available in the
All users start menu.
On Tue, Jul 20, 2010 at 8:17 PM,
heat.exe /? or http://wix.sourceforge.net/manual-wix3/heat.htm or
http://www.tramontana.co.hu/wix/lesson6.php#6.1 might be good places to
start.
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate +
I do this because when you try and add the localsystem account as: NT
AUTHORITY\SYSTEM, it will not check the Local System account
radiobutton under the Log On tab in the service properties.
It will instead select the This account: radiobutton and add NT
AUTHORITY\SYSTEM as the username.
So
This link may be of use to you
http://catb.org/~esr/faqs/smart-questions.html#before
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
Thanks guys!
On Wed, Jul 21, 2010 at 11:54 AM, Pally Sandher pally.sand...@iesve.com wrote:
You'd need a per-machine installation to do that anyway (see
http://msdn.microsoft.com/en-us/library/aa370882.aspx)
The How to guide at
Why don't you try resolve your linking errors when trying to build
wix-contrib instead of trying to reinvent the wheel failing?
Also why are you storing user specific data under the installation
directory instead of somewhere like My Documents or CommonAppData as per
Microsoft's platform
Hi All,
I get the following error when trying to run VS2010 Custom Action Project
with Wix 3.5.
Invoking remote custom action. DLL: C:\Windows\Installer\MSI24A2.tmp,
Entrypoint: ValidateSerialNumberKey
Generating random cookie.
Created Custom Action Server with PID 1224 (0x4C8).
Running as
You're propably using a 64 bit dll while using the 32 bit SFXCA. You
should point to the 64 bit version of SFXCA.
in my machine for example, C:\Program Files (x86)\Windows Installer XML
v3.5\SDK\x64\sfxca.dll
rather than C:\Program Files (x86)\Windows Installer XML
v3.5\SDK\x86\sfxca.dll
When
I think you can simplify what you have:
Property Id=SERVICEUSER SuppressModularization=yes/
Property Id=SERVICEPASSWORD SuppressModularization=yes/
Directory Id=TARGETDIR Name=SourceDir
Directory Id=MergeRedirectFolder
Component Id=ServiceInstaller Guid=* DiskId=1
I was wondering if it is possible to re-evaluate the NETFRAMEWORK20 property
after it was previously evaluated.
My setup is that, when the next button is pressed on the welcome dialog, if
the .NET Framework 2.0 is not installed, a dialog appears with a link to the
website to install the .NET
I doubt it's possible without modifying the WiXNetFxExtension code.
Use a bootstrapper to sequence your pre-requisites. Concurrent
installations are *very* dangerous highly unsupported by Windows
Installer. Also consider how your scenario would support basic or no UI
levels (/qb or /qn).
Is there a bootstrapper that I can use that will detect if the OS is 32-bit or
64-bit and then install the correct .NET Framework?
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Wednesday, July 21, 2010 10:00 AM
To: General discussion for Windows Installer
I don't know. Perhaps looking at the URL I pasted in my earlier reply or
maybe even looking for yourself on one of those newly invented search
engine things such as www.google.com might find you an answer?
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44
Thanks. I have been looking on google for several days and I've also looked
into dotNetInstaller. I had a bootstrapper working on a 32-bit system but
there was an error on a 64-bit system. Based on my research on google, it
sounded as though the dotNetInstaller didn't work on a 64-bit system
Apparently, there's hyperlink support with MSI 5.0. Bob Arnson blogs about it
here:
http://www.joyofsetup.com/2009/01/17/msi-v50-features-in-wix-v30/
Going back to your earlier question, about re-evaluating whether .NET is
installed, the reason you're getting the same result even after .NET has
Even after simplifying, the data was not passed to the merge module.
I am working on the configuration/substitution nodes now.
Any idea what the table name would be for the substitution for what I am trying
to do?
-Original Message-
From: bpackard [mailto:bill.pack...@kepware.com]
dotnetinstaller works perfectly fine on x64 platforms. I use it to do
exactly what you're trying to achieve which is why I suggested looking
at it yourself.
You can't use hyperlinks in Windows Installer dialogs unless you
specifically target Windows Installer v5 which is only available on
Windows
I was wondering if it is possible to re-evaluate the NETFRAMEWORK20
property after it was previously evaluated.
The NetFramework detection properties are all implemented via
RegistrySearch. I don't know of a good way to reevaluate them.
MergeModules don't have a ProductCode. modu...@id is a value that identifies
the module to enable modularization of properties, directories, and whatnot
for the contents of merge modules in MSIs.
You can't influence (except in a negative way) upgrade types from a merge
module. Those are 100%
The directory ProgramMenuFolder is defined as the All-Users Start menu when
ALLUSERS is 1.
http://msdn.microsoft.com/library/aa370882.aspx
-Original Message-
From: David Louis [mailto:clientlo...@gmail.com]
Sent: Wednesday, July 21, 2010 2:03 AM
To: General discussion for Windows
I assume Property
-Original Message-
From: John Bergman [mailto:john.berg...@xpedienttechnologies.com]
Sent: Wednesday, July 21, 2010 9:51 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Passing Values from the ProductModule to a
MergeModule
Even
Thanks for all of your responses. If I can't get the bootstrapper up and
running, then I am just going to go with a descriptive message.
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Wednesday, July 21, 2010 11:57 AM
To: General discussion for Windows
That is what I thought, but I was still having problems. I have resolve the
issue for what I need, (at least for now).
In the main product module, you need to declare the properties as follows:
Property Id=DOMAIN SuppressModularization=yes Secure=yes /
Property Id=USER
I have a custom action that does not log no matter what method is used to
turn logging on. Even though it executes correctly. I can see the property
being set in the log and the custom action begin and end.
Code example (made generic):
extern C UINT __stdcall MyCustomAction(MSIHANDLE install)
I am trying to use some environment variables in a WXL file where I store the
localized strings for my MSPs. However, they don't seem to be resolved!
Assuming 'Var' is my environment variable, I tried $(env.Var), just the
env.Var, etc. but none of them worked. Is this even possible? If so,
Hi,
Today I began creating my first WiX project. Until now I used
SetupSpecialist but as I am facing serious problems with it I want to
use WiX in future.
This is my first big question: On clients' computers there will be an
old instance of my program (with SetupSpecialist) installed. Even
Hi,
My setup project consists of a bunch of static files (application,
DLL), a huge databasefile and a vast amount of PDF files. The PDF files
are very volatile, they change from update to update (some are removed,
some are added but no of them are changed).
As they are many files I would
Dear Pally,
I have the same problem. BIG HINT for all users!
When you get
heat.exe : warning HEAT5150 : Could not harvest data from a file that
was expected to be a SelfReg
DLL: TestProtocol.dll. If this file does not support SelfReg you can
ignore this warning. Otherwise, this error detail
Here's a link for XP 64-bit and Windows 2003 x64 .NET 2.0
Redistributable Package
http://www.microsoft.com/downloads/details.aspx?familyid=B44A-ACF8-4
FA1-AFFB-40E78D788B00displaylang=en
-Original Message-
From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com]
Sent:
No. The preprocessor runs as part of loading the WXS files in the candle
tool, and WXL files are not even accessed until either the light tool or the
lit tool, which don't use the preprocessor.
-Original Message-
From: Sharat Janapareddy [mailto:sharat.janapare...@microsoft.com]
Sent:
In your settings for heat, you should use automatic component guids (they
come out as Guid=*) and you should setup a component group for your PDF
files (then you can simply refer to them from your feature using the
ComponentGroupRef element).
-Original Message-
From: Lukas Haase
Hi,
Does the filename of the msi file matter in any way?
I really DO NOT hope so! Because I have no influence if the user renames
the file before installing?!
[1] says: There are cases when the Windows Installer forces you to use
a major upgrade [...] You have to when you change the name of
Registry entries created with an action of 'write' are removed upon
uninstall of the component. The action called 'createAndRemoveOnUninstall'
applies to keys and removes all entries of that key, whether created by
Windows Installer or not, and is not needed in most cases. It is a case of
the name
It is true that changing the MSI file name forces a major upgrade. If you are
concerned that your user will interfere with your servicing strategy by
renaming
the MSI, you can use the OriginalDatabase property in a LaunchCondition to
abort
the install if they have renamed the MSI. I would
Dear Blair,
I do not fully understand. You mean the -ag switch?
But then on every compile the PDF files get a different GUID, don't
they? Then back to the original question: Does it matter in ANY way if
they get a different GUID on upgrades?
I.e. In a few months I will make the first upgrade
That could help reduce the chance of that problem, but depending on which
file the user changes (the initial or the update) you may not get a chance
to warn the user to not rename the MSI.
In most of the failure cases I have seen due to not finding the MSI file at
the indicated directory caused
Am 22.07.2010 00:07, schrieb Lukas Haase:
Dear Blair,
I do not fully understand. You mean the -ag switch?
But then on every compile the PDF files get a different GUID, don't
they? Then back to the original question: Does it matter in ANY way if
they get a different GUID on upgrades?
I.e.
Dear Blair, Dear Christopher,
Thank you for your reply.
Am 22.07.2010 00:11, schrieb Blair:
[...]
This is part of the reason huge numbers of software producers distributing
over the internet use self-extract-and-launch-style wrappers (zip-exe style)
for their MSI distribution.
Do you have a
-ag switch: sets the guid of each generated component as *. This cause the
compiler to compute a GUID based on the directory tree the component is in
and the name of the keypath. This results in stable GUIDs that don't change
between builds unless you change the directory or the filename (and in
But a key point is that this is only a possible** problem for minor upgrades.
If you do major upgrades you can ignore it.
**I say possible because I have never seen an issue but I mainly stick to major
upgrade because they are less hassle.
Neil
-Original Message-
From: Blair
1. You can build MSIs with WiX that don't require running the setup as
administrator. Nothing that can be done outside of Windows Installer without
elevation requires elevation in Windows Installer to also do.
2. Windows Installer has no built-in support for detecting/removing non-MSI
packages.
InstallShield grin/
Seriously, I'm warming up to WiX but I still only use it for my merge module
development ( hundreds of them ). I still consume them with InstallShield
Product Configurations to support dozens of products with upwards to 15,000
files each and dozens of third party packages
Same here. I've heard people post for years about how Major Upgrades are a
pain
and you better follow the component rules to a letter if you want minor
upgrades, small updates and patching to work. I've choosen to only support
Major Upgrades and it's a bit of a vindication to now see the
I have often said (even on this list) that for most products, Major Upgrades
are the way to go. Until your distribution strategy requires supporting MSP
files, and you feel more technically confident in your abilities in Windows
Installer deployment technologies, just set things up for Major
#1
How long before you ship?
Search for self-extract and many of what comes up can be set to run a
command-line at the end of the extract. I recently used some sort of
WinZip-like program. I've also successfully used IExpress in the past.
#2
As far as I have been able to gather the reason is that
WcaLog just calls MSI APIs. You might try debugging down to see if the MSI
API calls are return failures.
I've never seen a problem with logging except that you can't log at all from
a button push.
On Wed, Jul 21, 2010 at 1:05 PM, Fangren tim.kr...@shavlik.com wrote:
I have a custom action
Uhh, I personally always recommend Major Upgrades over all the other
options. IMHO, the other options (minor updates and small updates) add pain
that is rarely worth it (i.e. you have to be really big with lots of
customers to bother with .msp's).
I'd be curious to see who actually recommends
I left a comment on the blog post. Why did you transform things into an
Include file?
On Tue, Jul 20, 2010 at 2:50 PM, Leif Ringstad lei...@gmail.com wrote:
Hi
After struggling for too many hours to get this transform working, I
thought
I would share it with the list.
Rob- I seem to recall several blog articles years ago talking about how major
upgrades are ugly. One was from an active blogger at the time ( Vagmi ) but
I don't remember the others.
http://geekswithblogs.net/Vagmi.Mudumbai/archive/2006/06/11/81426.aspx
Blair- My MSI mojo is good, but
I think you have me confused with someone else. I've always had the stance:
If you can use a Major Upgrade do so. Life is too short to deal with the
difficulties otherwise.
What else have you told people I believe? smile/
On Wed, Jul 21, 2010 at 7:53 PM, Christopher Painter
I wrote thatI had read several blog posts over the years and cited one of them
as Vagmi and couldn't recall who the others were. I didn't say any of them
were
from you. In fact, I recall you writing a post about why WiX uses Major
Upgrades and I referred to that as vindication; evidence that
Hi all. I would like to avoid showing that last dialog when the user clicks
Cancel before installation has begun. I would still like the dialog to be
shown if the user cancels an installation that has been started, as this
tells them the cancellation was successful, but if no install is taking
52 matches
Mail list logo
