The bootstrapper instructions you supplied use a bootstrapper that creates a
setup.exe file that runs the project-associated target file (your MSI file)
after all other packages indicated in your build instructions are run. It is
expected that the user will run the setup.exe, or that you will
if i have a deferr=red custom action with Impersonate=yes. then on Windows
Vista with UAC enabled i get a prompt asking if the user wishes the allow
the program to access your computer. now if the user presses allow in UAC
prompt. Will my custom action be able to connect to SQL server on another
ModuleInstallExecuteSequence doesn't exist in an MSI, only an MSM -
http://msdn.microsoft.com/en-us/library/aa370049(VS.85).aspx
Even if you get your Custom Action into it, your MSI is still going to
have the same problem once the merge module is consumed if the Custom
Action is not Conditioned
http://www.joyofsetup.com/2007/09/24/test-your-setups-virtually/
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
Binary Elements are extracted to temporary directories using auto
generated filenames (see a verbose log for an example). It's not
possible to use an application in a Binary Element with QtExec (I looked
at the same thing a while ago for a plug-in installer). You'll either
need to change it to use
Thanks for the responses - I've gone with the file element. I don't really
want the executable written to disk (it serves no purpose to the end user),
but there's no harm in it being there.
On Fri, Jun 18, 2010 at 7:28 AM, Pally Sandher pally.sand...@iesve.comwrote:
Binary Elements are
Mergemod.dll takes the rows in the ModuleInstallExecuteSequence table and
inserts them into the InstallExecuteSequence table. As I said in a previous
post, the key is to use Component Action states not Feature Action states
in the conditional expressions. Anything else creates an akward
Thanks Blair for clarification, my setup is now working as expected. Appreciate
your help!
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: June 18, 2010 12:19 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Install .Net Framework 4
I want to GAC an assembly already present on target machines, I know where
this assembly is on every machine (you can assume, that path is static for
all target machines and wont change) I do not want to include the assembly
to be GAC'd in the MSI since it can change with each software deployment
The traditional way to do this (discussed on this list a few times a few years
ago) is a little hacky, but works well enough.
1) Put your executable in a self-extracting archive, using iexpress for example;
2) execute the self-extracting archive from the binary table in a 'quiet' mode,
putting
Hi
My name is Ivo Beltchev. I am working on the open source project Classic
Shell: http://classicshell.sourceforge.net/
Currently I use a Visual Studio setup project to create my installer,
but I'm hitting some of its limitations and I'm looking for a better
solution.
Here's what I need,
Has anyone created a clustered share using WiX before? I'm looking for an
elegant way to do this.
Best Regards,
Andrew
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE
1) This isn't a limitation of Visual Studio or WiX. This is a limitation with
Windows Installer. You'll need to have two MSI packages. A bootstrapper might
help you consolidate them so that it appears like one installer.
2) These sound like Features in Windows Installer parlance. As you
1) I need a single EXE that can be installed on both 32-bit and 64-bit
platforms (Vista and Windows 7). Most of the files (art assets, help
files) are common between platforms. There are 32-bit and 64-bit
executables, which need to register themselves in the registry
(self-registered
1) I need a single EXE that can be installed on both 32-bit and 64-
bit
platforms (Vista and Windows 7). Most of the files (art assets,
help
files) are common between platforms. There are 32-bit and 64-bit
executables, which need to register themselves in the registry
To Bob's list (which is a little out of date) I'll add that Server 2008 also
has Hypervisor, Microsoft's newer VM technology. If you can get an x64 Server
2008 box you can have x64 and x86 VMs. VMs really are the best way to test
setups when you can do your tests and then revert to an
Windows Installer caches a copy of your MSI but it strips out any embedded
cabinets. You'll need the original source for repairs. I'll let somebody
with more knowledge provide advice.
I have heard mentioned that Windows Installer requires that the MSI package
filename does not change
Microsoft Hyper-V Server 2008 R2 is free to download and use, if you don't
have a Server 2008 license available. It requires an x64 box with certain
CPUs that support hardware virtualization.
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: Friday, June 18,
Forwarding to the list as it was accidentally removed from the TO line.
-Original Message-
From: i...@roadrunner.com [mailto:i...@roadrunner.com]
Sent: Friday, June 18, 2010 11:47 AM
To: Castro, Edwin G. (Hillsboro)
Subject: RE: [WiX-users] Can this be done with WiX?
I compile 2
You should be able to set the impersonation appropriately to launch
your exe as the user.
Are you sure WiX can do this? When I was searching for a solution
before I came across this:
http://stackoverflow.com/questions/2206646/create-a-process-with-
Hi all,
I created an installer that consists several dlls and exes. I also
supports updates so the user can update our product instead of
reinstalling our product.
So far it's pretty good.
However, when the user either updates or uninstall our product,
windows display the message asking the user
Hi
I'm trying to change the media layout through the command line when running
msiexec.
I thought it should be enough to have a property and set that to the
Layout of the Media, but I cannot get it to work properly.
I'm wondering if this is possible, as I've tried this, and it doesn't seem
to
There are some properties you can set, such as REBOOT=ReallySuppress. In your
situation I'd do the update/uninstall and create a verbose MSI log to see why
Windows wants to reboot, or if there is something like a spurious
ScheduleReboot in there. You don't really want to suppress a reboot if
I have used the v3.5 version with VS2010 to create MSIs. I noticed that if I
create a custom appPool and assign it a real user that this step in the basic
logging displays the password in clear text:
Property(S): WriteIIS7ConfigChange
Can that line be encrypted or the password not be displayed
Also, most people starting an application at the end of an installation do so
from the final UI screen of the installation, often with a checkbox selecting
whether to start the installation or not. WiX has this functionality pretty
much built in (such that it is only offered if the UI was used
Property Id=WriteIIS7ConfigChange Hidden=yes/
It would hide the property, so if you need other parts of that property in
the log for diagnosis you would need to set the Debug policy appropriately.
http://msdn.microsoft.com/library/aa370308.aspx
-Original Message-
From: Pierson Lee (PIE)
Blair os...@live.com wrote:
Also, most people starting an application at the end of an installation do so
from the final UI screen of the installation, often with a checkbox selecting
whether to start the installation or not. WiX has this functionality pretty
much built in (such that
Aren't most shell extensions DLLs that Explorer.exe loads when needed? I never
had to run one I installed...
-Original Message-
From: i...@roadrunner.com [mailto:i...@roadrunner.com]
Sent: Friday, June 18, 2010 2:39 PM
To: General discussion for Windows Installer XML toolset.
Cc: Blair
med...@layout attribute is used during the build to facilitate placement of
the files into your media layout (the way you transfer your build output
onto your multiple CDs or whatever). The data in that attribute is not
preserved in the MSI and is not available/doesn't alter the way that Windows
This is not a proper shell extension. It is a DLL that is injected into the
Explorer process. There is an EXE that does the injection and re-injects the
DLL when Explorer is restarted (due to crash or other reason).
For regular shell extensions the users will expect them to be automatically
Certificates are not based on ProductCode. So how do I make sure that my
cert is not deleted during a major upgrade, but deleted during an uninstall?
Also, my msi's functionality does not change from language to language, like
it doesn't install any language specific packs etc... All my MSI does
I somehow couldn't find the sources in that folder. Downloaded from this
location - http://wix.sourceforge.net/releases/. Hope it would be helpful
for others.
On Tue, Jun 8, 2010 at 8:41 PM, Rob Mensching r...@robmensching.com wrote:
WiX v2.0 source code is on CodePlex in the wix20 branch. The
Thank you very much. This helped me a lot!
On Mon, Jun 7, 2010 at 1:20 PM, Blair os...@live.com wrote:
In v2 it was $(loc.StringId). That was changed to !(loc.StringId) in v3
(IMHO to make it more obvious when the replacement happens [precompile vs.
late-stage linking/binding]).
V2 users
Thanks for the reply.
I was afraid it was so. I ended up packaging the msi's + files into a nsis
installer which unpacks to temp and then installs.
cheers,
Leif
On Fri, Jun 18, 2010 at 11:56 PM, Blair os...@live.com wrote:
med...@layout attribute is used during the build to facilitate
(keeping the thread on the list so future generations can benefit)
The source list is described here:
http://msdn.microsoft.com/library/aa369795.aspx and here:
http://msdn.microsoft.com/library/aa371859.aspx along with a few other places.
It is the list of directories that Windows Installer
Typically Windows Installer will only delete what it writes. You have to do
extra work to delete other things (like stuff generated during an
installation). You can easily condition that extra work to only operate when
a removal is NOT part of an upgrade. (See the UPGRADINGPRODUCTCODE
property).
Will making that change affect the property itself? It isn't a property I
create, its from the IIS custom action.
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Friday, June 18, 2010 2:35 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re:
Blair os...@live.com wrote:
(keeping the thread on the list so future generations can benefit)
The source list is described here:
http://msdn.microsoft.com/library/aa369795.aspx and here:
http://msdn.microsoft.com/library/aa371859.aspx along with a few other
places. It is the list
Is there a way to get a list of properties from an MSI? I can install it if
necessary.
A
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental
It doesn't create the property itself (although it does create a record for
the linker of that property). It simply and only adds that property's name
to the property described in the MSDN page I provided.
However, after glancing in the WiX sources, are you sure it isn't
WriteIIS7ConfigChanges?
There are properties that are defined by the system, properties that are
defined by the package (initial values are in the Property table), and
properties that are created while the installation transaction proceeds
(whether by searches or custom actions).
To see final values for all custom
I see. So as I understand it, I have to keep the MSI around while the
software is installed. Is there a
recommended location for such cached MSIs? And is it even possible for the
MSI to delete itself during
uninstall?
How does Burn handle this?
If the MSI is installed per-user, it would
Blair os...@live.com wrote:
I see. So as I understand it, I have to keep the MSI around while the
software is installed. Is there a
recommended location for such cached MSIs? And is it even possible for the
MSI to delete itself during
uninstall?
How does Burn handle this?
My goal is to take an msi and find out what properties I can pass it on the
command line when I run msiexec. I see a number of entries from the log when
I install it that look like the following:
MSI (s) (D8:D0) [17:07:48:626]: PROPERTY CHANGE: Adding BIN property. Its
value is 'redacted'.
MSI
Two solutions I have seen to deal with this:
1- Use a custom action to cache the MSI and add the cache directory to the
source list.
2- Use a bootstrapper that launches asInvoker, then relaunches either itself or
some extracted code as administrator. You then have elevated code for
installing
Is there any way to set the packa...@description property dynamically? It does
seem to accept bracket-style properties, but it only uses the values that those
properties are initialized to on startup. If I change the value during
install, I still get the original value displayed in Add/Remove
Two solutions I have seen to deal with this:
1- Use a custom action to cache the MSI and add the cache directory to the
source list.
2- Use a bootstrapper that launches asInvoker, then relaunches either itself
or some extracted code as administrator. You then have elevated code for
The summary information stream is MSI metadata outside of the MSI SQL
database (but inside of the MSI file) and uses a different set of APIs to
access than the rest of the data in the file. Changing it would have to
occur before you start an installation transaction, and if you codesign your
MSIs
Those would be some, yes.
Depending on how the MSI and the various custom actions in it work, some
subset of all the properties that are in all CAPS may be set from the
commandline. However, it is possible for custom actions to override any of
those properties you set with values of its own.
How does that file get on customers' machines and why didn't the original
author have it GAC'd in their distribution of that file? Could it possibly
not be intended for use from the GAC? Might that create a security issue?
What if the original installation needs to remove or upgrade that file,
50 matches
Mail list logo