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, and
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. Furth
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
> 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
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
installing t
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 (s)
Blair 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?
>
> If
> 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 wo
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 action
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?
-
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 un
Blair 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 of direc
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: [WiX-users
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).
F
(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 wil
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 wrote:
> med...@layout attribute is used during the build to facilitate placement of
> the fi
Thank you very much. This helped me a lot!
On Mon, Jun 7, 2010 at 1:20 PM, Blair 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 must use MSI
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 wrote:
> WiX v2.0 source code is on CodePlex in the wix20 branch. The WiX 2.0 MSI is
> at h
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 is
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
a
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
In
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
Blair 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 it is only
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) [mailto:pierson@microsoft.com]
Sent: Frid
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 i
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
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 the
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 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 work. It o
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
> > 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-
> ordinary-rights-from-an-administr
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 c
"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,
> 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 chang
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 untarnishe
> > > 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
>
> > 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-regi
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 organize
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 P
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, pleas
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
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 a
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
The
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 releat
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 wrote:
> Binary Elements are extracted to temporary directo
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
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 **
Integrated Environmental Solutions Limited. Registered in S
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
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
49 matches
Mail list logo