Re: [WiX-users] WiX 2.0 created MSI occasionally fails to install on Vista
Been looking into this some more. I've asked the customer to log before
and after (nothing yet) but in the meantime they found this article on
how to elevate privileges for an MSI (
http://footheory.com/blogs/shane/archive/2007/08/03/vista-and-elevating-security-of-an-msi-to-run-as-administrator.aspx
).
Thats not the ONLY way to do this is it? Is the article author mistaken?
I see UAC prompts come up when I run my MSI so I thought it would be OK.
I'd hate to have to do a bodge because Vista has a security by obscurity
flaw.
Regards
Ryan
Rob Hamflett wrote:
The only thing that I can think to cause this would be if the command prompt
was elevated. Have you
tried logging the installation to see what the differences are? This article
explains how to turn
on global logging so you can get the logs for the double-click installation.
http://support.microsoft.com/kb/223300
Rob
Ryan O'Neill wrote:
Ah, sorry, didn't see you there amongst all the spam!
I mean that from a command prompt it installs the Browser Helper Object
DLL just fine, but when run via double clicking it does not. It appears
to work the same but the DLL is not registered properly and does not get
installed into IE. But, this is only on certain systems. I worry that
they are doing something silly which they are not telling me about.
Would the MSI run OK from UNC network share? I think they are doing
this, which is the only major difference in the way I would run anything.
Regards
Ryan
Rob Hamflett wrote:
You say it runs fine from a command prompt. How does it normally run?
Rob
Ryan O'Neill wrote:
Anyone got a clue about this? I can't resolve it.
Ryan O'Neill wrote:
Hi all,
I have an installer that works great for all Win platforms, except Vista
where it will fail to register a DLL on specific machines. It runs on
most Vista installations fine (under admin and limited user accounts
which prompt for admin access). I did manage to get to a machine that
exhibited the issue yesterday and after running the MSI from the command
prompt, it installed correctly. I understand what happened there with
the automatically elevated privileges using the command prompt but I
can't understand why the normal UAC prompts did not allow the installer
to write the DLL registration to the registry.
I think perhaps the systems it fails on have a policy that is
disallowing my installer registry writes, but I'm out of ideas.
In testing it has proved to install correctly with;
a) Admin accounts.
b) Non admin accounts.
c) Non default user admin account.
The method I am using to write to the registy is via the usual Registry
tag, as below;
Component Id=C_MainDll Guid={X}
Registry Root=HKLM
Key=Software\Microsoft\Internet Explorer\Toolbar
Registry Name={YY} Type=string
Value=My toolbar /
/Registry
Registry Root=HKCR Key=CLSID\{YY}
Value=My toolbar Type=string /
Obviously there are many more registry tags as well.
I'm really stuck here, it works on most Vista systems and then the
remainder it will work after being installed from the command prompt.
Any help would be very much appreciated.
Thanks in advance,
Ryan
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users
Re: [WiX-users] WiX 2.0 created MSI occasionally fails to install on Vista
That article is missing a few important bits, as far as my understanding goes.
An installer written
for Vista should be marked as needing elevation, or not needing elevation. If
it does, you get
prompted when the installer switches over to the server side, which does the
actual work. Microsoft
knew they would have to cope with a ton of installers that were written
pre-Vista, so there's code
in there to elevate anything that looks like an installer. Basically anything
called setup.exe, or
with 'installer' or 'setup' in the description. That kind of thing, and I
think MSI files get
included in there.
Going back to your problem, I get the impression that when you say you run it
from a command prompt,
you actually mean you run it from an 'elevated' command prompt. If this is the
case, then it sounds
like the DLL is being registered outside the elevated part of the install. Are
you using a Custom
Action to do this, and if so, is it scheduled somewhere between
InstallInitialize and
InstallFinalize in the InstallExecuteSequence?
Rob
Ryan O'Neill wrote:
Been looking into this some more. I've asked the customer to log before
and after (nothing yet) but in the meantime they found this article on
how to elevate privileges for an MSI (
http://footheory.com/blogs/shane/archive/2007/08/03/vista-and-elevating-security-of-an-msi-to-run-as-administrator.aspx
).
Thats not the ONLY way to do this is it? Is the article author mistaken?
I see UAC prompts come up when I run my MSI so I thought it would be OK.
I'd hate to have to do a bodge because Vista has a security by obscurity
flaw.
Regards
Ryan
Rob Hamflett wrote:
The only thing that I can think to cause this would be if the command prompt
was elevated. Have you
tried logging the installation to see what the differences are? This
article explains how to turn
on global logging so you can get the logs for the double-click installation.
http://support.microsoft.com/kb/223300
Rob
Ryan O'Neill wrote:
Ah, sorry, didn't see you there amongst all the spam!
I mean that from a command prompt it installs the Browser Helper Object
DLL just fine, but when run via double clicking it does not. It appears
to work the same but the DLL is not registered properly and does not get
installed into IE. But, this is only on certain systems. I worry that
they are doing something silly which they are not telling me about.
Would the MSI run OK from UNC network share? I think they are doing
this, which is the only major difference in the way I would run anything.
Regards
Ryan
Rob Hamflett wrote:
You say it runs fine from a command prompt. How does it normally run?
Rob
Ryan O'Neill wrote:
Anyone got a clue about this? I can't resolve it.
Ryan O'Neill wrote:
Hi all,
I have an installer that works great for all Win platforms, except Vista
where it will fail to register a DLL on specific machines. It runs on
most Vista installations fine (under admin and limited user accounts
which prompt for admin access). I did manage to get to a machine that
exhibited the issue yesterday and after running the MSI from the command
prompt, it installed correctly. I understand what happened there with
the automatically elevated privileges using the command prompt but I
can't understand why the normal UAC prompts did not allow the installer
to write the DLL registration to the registry.
I think perhaps the systems it fails on have a policy that is
disallowing my installer registry writes, but I'm out of ideas.
In testing it has proved to install correctly with;
a) Admin accounts.
b) Non admin accounts.
c) Non default user admin account.
The method I am using to write to the registy is via the usual Registry
tag, as below;
Component Id=C_MainDll Guid={X}
Registry Root=HKLM
Key=Software\Microsoft\Internet Explorer\Toolbar
Registry Name={YY} Type=string
Value=My toolbar /
/Registry
Registry Root=HKCR Key=CLSID\{YY}
Value=My toolbar Type=string /
Obviously there are many more registry tags as well.
I'm really stuck here, it works on most Vista systems and then the
remainder it will work after being installed from the command prompt.
Any help would be very much appreciated.
Thanks in advance,
Ryan
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
-
This SF.net
Re: [WiX-users] WiX 2.0 created MSI occasionally fails to install on Vista
The registration of the DLL is handled via RegistryValue elements
wrapped inside Component elements which are then inside three levels of
Directory elements (snippet below). So no custom actions involved for
the registry, I kind of got the impression they were not good. I do have
one however, to launch IE after the install (also shown below). I
upgraded to WiX v3 to see if I could get better error checking, then
cleared any warnings and still the same.
This may be relevant, I used InstallAware to create the initial bulk of
the installer but have edited by hand since then.
Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder Name=PFiles
Directory Id=INSTALLDIR Name=OSOYOU Internet
Explorer toolbar
Component Id=C_MainDll
Guid={DB020289-44CE-4A4C-9821-C96718B0FF3E}
File Id=FL_IEToolbar.dll ShortName=IETool
Name=IEToolbar.dll
Source=..\IEToolbar\ReleaseUMinDependency\IEToolbar.dll DiskId=1
KeyPath=yes /
RegistryKey Root=HKLM
Key=Software\Microsoft\Internet Explorer\Toolbar
RegistryValue Type=string Value= /
RegistryValue
Name={FD7DC3F5-F8EA-4F91-9665-4B8661392667} Type=string
Value=OSOYOU toolbar /
/RegistryKey
RegistryValue Root=HKCR
Key=CLSID\{FD7DC3F5-F8EA-4F91-9665-4B8661392667} Value=OSOYOU
toolbar Type=string /
CustomAction Id=CA_HelpInstall Return=asyncNoWait
Property=IEXPLORE ExeCommand=http://www.myurl.com/toolbarhelp;
Execute=immediate /
Thanks for keeping with me on this Rob, very much appreciated.
Regards
Ryan
Rob Hamflett wrote:
That article is missing a few important bits, as far as my understanding
goes. An installer written
for Vista should be marked as needing elevation, or not needing elevation.
If it does, you get
prompted when the installer switches over to the server side, which does the
actual work. Microsoft
knew they would have to cope with a ton of installers that were written
pre-Vista, so there's code
in there to elevate anything that looks like an installer. Basically
anything called setup.exe, or
with 'installer' or 'setup' in the description. That kind of thing, and I
think MSI files get
included in there.
Going back to your problem, I get the impression that when you say you run it
from a command prompt,
you actually mean you run it from an 'elevated' command prompt. If this is
the case, then it sounds
like the DLL is being registered outside the elevated part of the install.
Are you using a Custom
Action to do this, and if so, is it scheduled somewhere between
InstallInitialize and
InstallFinalize in the InstallExecuteSequence?
Rob
Ryan O'Neill wrote:
Been looking into this some more. I've asked the customer to log before
and after (nothing yet) but in the meantime they found this article on
how to elevate privileges for an MSI (
http://footheory.com/blogs/shane/archive/2007/08/03/vista-and-elevating-security-of-an-msi-to-run-as-administrator.aspx
).
Thats not the ONLY way to do this is it? Is the article author mistaken?
I see UAC prompts come up when I run my MSI so I thought it would be OK.
I'd hate to have to do a bodge because Vista has a security by obscurity
flaw.
Regards
Ryan
Rob Hamflett wrote:
The only thing that I can think to cause this would be if the command
prompt was elevated. Have you
tried logging the installation to see what the differences are? This
article explains how to turn
on global logging so you can get the logs for the double-click installation.
http://support.microsoft.com/kb/223300
Rob
Ryan O'Neill wrote:
Ah, sorry, didn't see you there amongst all the spam!
I mean that from a command prompt it installs the Browser Helper Object
DLL just fine, but when run via double clicking it does not. It appears
to work the same but the DLL is not registered properly and does not get
installed into IE. But, this is only on certain systems. I worry that
they are doing something silly which they are not telling me about.
Would the MSI run OK from UNC network share? I think they are doing
this, which is the only major difference in the way I would run anything.
Regards
Ryan
Rob Hamflett wrote:
You say it runs fine from a command prompt. How does it normally run?
Rob
Ryan O'Neill wrote:
Anyone got a clue about this? I can't resolve it.
Ryan O'Neill wrote:
Hi all,
I have an installer that works great for all Win platforms, except
Vista
where it will fail to register a DLL on specific machines. It runs on
most Vista installations fine (under admin and limited user accounts
which prompt for admin access). I did manage to get to a machine that
exhibited the issue yesterday and after running
[WiX-users] dark.exe : error DARK0001 :
Hi, When I apply dark.exe for an existing MSI, am getting following error. Can any one tell me how to resolve this C:\Documents and Settings\sai_teja\Desktop\wix-3.0.2925.0-binarieszipdark.e xe Control Client.msi Control Client.wxs Microsoft (R) Windows Installer Xml Decompiler Version 3.0.2925.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. Control Client.msi dark.exe : error DARK0001 : Cannot set column 'KeyColumn' with value 0 because i t is less than the minimum allowed value for this column, 1. Exception Type: System.InvalidOperationException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.ColumnDefinition.ValidateValue(Object value) at Microsoft.Tools.WindowsInstallerXml.Unbinder.UnbindDatabase(String databas eFile, Database database, OutputType outputType, String exportBasePath) at Microsoft.Tools.WindowsInstallerXml.Unbinder.UnbindDatabase(String databas eFile, OutputType outputType, String exportBasePath) at Microsoft.Tools.WindowsInstallerXml.Unbinder.Unbind(String file, OutputTyp e outputType, String exportBasePath) at Microsoft.Tools.WindowsInstallerXml.Tools.Dark.Run(String[] args) C:\Documents and Settings\sai_teja\Desktop\wix-3.0.2925.0-binarieszip -- View this message in context: http://www.nabble.com/dark.exe-%3A-error-DARK0001-%3A-tf4880903.html#a13968327 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Calling embedded binaries with dependencies in WIX
Just as a side note, cygwin and sed (what you seem to be using) are both licensed under GPL license hence you are required to provide source code access to all customers using the software (installer is also software), including any modifications. Furthermore, the installer would need to be rebuildable with the modified sed files (if customers wants to do that for whatever reason) so source code/object code of the wix would need to be provided as well. Adam, I'm not a lawyer, but I don't believe that this interpretation is correct. The GPL talks about derived works, and I don't believe that using sed in your installer makes your installer a derived work of sed. This quote from Wikipedia is helpful: The program must be GPL only if it includes GPL source code or it is linked with a GPL library (with the usual provisos about relying on Wikipedia). You would have to comply with the provisions about supplying source code to sed, but you it is sufficient to provide a written offer to supply the source code on demand: Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange Regards, John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 2.0 created MSI occasionally fails to install on Vista
If you're doing things via normal MSI methods (which you are, assuming the
values are correct) and
specifying [EMAIL PROTECTED]elevated (are you?), then I'm out of ideas, sorry.
Aha, hold on. When you run from the elevated command prompt, the entire
installation runs elevated.
This means that the Internet Explorer instance you launch at the end of the
installation is also
running elevated. Is this possibly the real problem? The installation is fine
but you need to run
IE elevated for it to work?
Rob
Ryan O'Neill wrote:
The registration of the DLL is handled via RegistryValue elements
wrapped inside Component elements which are then inside three levels of
Directory elements (snippet below). So no custom actions involved for
the registry, I kind of got the impression they were not good. I do have
one however, to launch IE after the install (also shown below). I
upgraded to WiX v3 to see if I could get better error checking, then
cleared any warnings and still the same.
This may be relevant, I used InstallAware to create the initial bulk of
the installer but have edited by hand since then.
Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder Name=PFiles
Directory Id=INSTALLDIR Name=OSOYOU Internet
Explorer toolbar
Component Id=C_MainDll
Guid={DB020289-44CE-4A4C-9821-C96718B0FF3E}
File Id=FL_IEToolbar.dll ShortName=IETool
Name=IEToolbar.dll
Source=..\IEToolbar\ReleaseUMinDependency\IEToolbar.dll DiskId=1
KeyPath=yes /
RegistryKey Root=HKLM
Key=Software\Microsoft\Internet Explorer\Toolbar
RegistryValue Type=string Value= /
RegistryValue
Name={FD7DC3F5-F8EA-4F91-9665-4B8661392667} Type=string
Value=OSOYOU toolbar /
/RegistryKey
RegistryValue Root=HKCR
Key=CLSID\{FD7DC3F5-F8EA-4F91-9665-4B8661392667} Value=OSOYOU
toolbar Type=string /
CustomAction Id=CA_HelpInstall Return=asyncNoWait
Property=IEXPLORE ExeCommand=http://www.myurl.com/toolbarhelp;
Execute=immediate /
Thanks for keeping with me on this Rob, very much appreciated.
Regards
Ryan
Rob Hamflett wrote:
That article is missing a few important bits, as far as my understanding
goes. An installer written
for Vista should be marked as needing elevation, or not needing elevation.
If it does, you get
prompted when the installer switches over to the server side, which does the
actual work. Microsoft
knew they would have to cope with a ton of installers that were written
pre-Vista, so there's code
in there to elevate anything that looks like an installer. Basically
anything called setup.exe, or
with 'installer' or 'setup' in the description. That kind of thing, and I
think MSI files get
included in there.
Going back to your problem, I get the impression that when you say you run
it from a command prompt,
you actually mean you run it from an 'elevated' command prompt. If this is
the case, then it sounds
like the DLL is being registered outside the elevated part of the install.
Are you using a Custom
Action to do this, and if so, is it scheduled somewhere between
InstallInitialize and
InstallFinalize in the InstallExecuteSequence?
Rob
Ryan O'Neill wrote:
Been looking into this some more. I've asked the customer to log before
and after (nothing yet) but in the meantime they found this article on
how to elevate privileges for an MSI (
http://footheory.com/blogs/shane/archive/2007/08/03/vista-and-elevating-security-of-an-msi-to-run-as-administrator.aspx
).
Thats not the ONLY way to do this is it? Is the article author mistaken?
I see UAC prompts come up when I run my MSI so I thought it would be OK.
I'd hate to have to do a bodge because Vista has a security by obscurity
flaw.
Regards
Ryan
Rob Hamflett wrote:
The only thing that I can think to cause this would be if the command
prompt was elevated. Have you
tried logging the installation to see what the differences are? This
article explains how to turn
on global logging so you can get the logs for the double-click
installation.
http://support.microsoft.com/kb/223300
Rob
Ryan O'Neill wrote:
Ah, sorry, didn't see you there amongst all the spam!
I mean that from a command prompt it installs the Browser Helper Object
DLL just fine, but when run via double clicking it does not. It appears
to work the same but the DLL is not registered properly and does not get
installed into IE. But, this is only on certain systems. I worry that
they are doing something silly which they are not telling me about.
Would the MSI run OK from UNC network share? I think they are doing
this, which is the only major difference in the way I would run anything.
Regards
Ryan
Rob Hamflett wrote:
Re: [WiX-users] WiX 2.0 created MSI occasionally fails to install on Vista
You could be right. The DLL could be doing something daft. I thought I
tallowed out all the registration. I'll check again.
Rob Hamflett wrote:
If you're doing things via normal MSI methods (which you are, assuming the
values are correct) and
specifying [EMAIL PROTECTED]elevated (are you?), then I'm out of ideas,
sorry.
Aha, hold on. When you run from the elevated command prompt, the entire
installation runs elevated.
This means that the Internet Explorer instance you launch at the end of the
installation is also
running elevated. Is this possibly the real problem? The installation is
fine but you need to run
IE elevated for it to work?
Rob
Ryan O'Neill wrote:
The registration of the DLL is handled via RegistryValue elements
wrapped inside Component elements which are then inside three levels of
Directory elements (snippet below). So no custom actions involved for
the registry, I kind of got the impression they were not good. I do have
one however, to launch IE after the install (also shown below). I
upgraded to WiX v3 to see if I could get better error checking, then
cleared any warnings and still the same.
This may be relevant, I used InstallAware to create the initial bulk of
the installer but have edited by hand since then.
Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder Name=PFiles
Directory Id=INSTALLDIR Name=OSOYOU Internet
Explorer toolbar
Component Id=C_MainDll
Guid={DB020289-44CE-4A4C-9821-C96718B0FF3E}
File Id=FL_IEToolbar.dll ShortName=IETool
Name=IEToolbar.dll
Source=..\IEToolbar\ReleaseUMinDependency\IEToolbar.dll DiskId=1
KeyPath=yes /
RegistryKey Root=HKLM
Key=Software\Microsoft\Internet Explorer\Toolbar
RegistryValue Type=string Value= /
RegistryValue
Name={FD7DC3F5-F8EA-4F91-9665-4B8661392667} Type=string
Value=OSOYOU toolbar /
/RegistryKey
RegistryValue Root=HKCR
Key=CLSID\{FD7DC3F5-F8EA-4F91-9665-4B8661392667} Value=OSOYOU
toolbar Type=string /
CustomAction Id=CA_HelpInstall Return=asyncNoWait
Property=IEXPLORE ExeCommand=http://www.myurl.com/toolbarhelp;
Execute=immediate /
Thanks for keeping with me on this Rob, very much appreciated.
Regards
Ryan
Rob Hamflett wrote:
That article is missing a few important bits, as far as my understanding
goes. An installer written
for Vista should be marked as needing elevation, or not needing elevation.
If it does, you get
prompted when the installer switches over to the server side, which does
the actual work. Microsoft
knew they would have to cope with a ton of installers that were written
pre-Vista, so there's code
in there to elevate anything that looks like an installer. Basically
anything called setup.exe, or
with 'installer' or 'setup' in the description. That kind of thing, and I
think MSI files get
included in there.
Going back to your problem, I get the impression that when you say you run
it from a command prompt,
you actually mean you run it from an 'elevated' command prompt. If this is
the case, then it sounds
like the DLL is being registered outside the elevated part of the install.
Are you using a Custom
Action to do this, and if so, is it scheduled somewhere between
InstallInitialize and
InstallFinalize in the InstallExecuteSequence?
Rob
Ryan O'Neill wrote:
Been looking into this some more. I've asked the customer to log before
and after (nothing yet) but in the meantime they found this article on
how to elevate privileges for an MSI (
http://footheory.com/blogs/shane/archive/2007/08/03/vista-and-elevating-security-of-an-msi-to-run-as-administrator.aspx
).
Thats not the ONLY way to do this is it? Is the article author mistaken?
I see UAC prompts come up when I run my MSI so I thought it would be OK.
I'd hate to have to do a bodge because Vista has a security by obscurity
flaw.
Regards
Ryan
Rob Hamflett wrote:
The only thing that I can think to cause this would be if the command
prompt was elevated. Have you
tried logging the installation to see what the differences are? This
article explains how to turn
on global logging so you can get the logs for the double-click
installation.
http://support.microsoft.com/kb/223300
Rob
Ryan O'Neill wrote:
Ah, sorry, didn't see you there amongst all the spam!
I mean that from a command prompt it installs the Browser Helper Object
DLL just fine, but when run via double clicking it does not. It appears
to work the same but the DLL is not registered properly and does not get
installed into IE. But, this is only on certain systems. I worry that
they are doing something silly which they are not telling me about.
Re: [WiX-users] uninstalling a product silently before installing a new one
hmm, thats bad :(Any good or bad hacks coming to anyone's minds. Any thing ?? ..ab On Nov 27, 2007 12:06 PM, Kelly Leahy [EMAIL PROTECTED] wrote: Nope... As far as I know, NOTHING will work in that scenario. AFAIK, there's no way to handle this properly - you pretty much want to require that users either only can install as Everyone, or only can install as Just Me. Personally, I think Just Me is silly and can't come up with any good reason for this installer choice. *Abubakar [EMAIL PROTECTED]* Sent by: [EMAIL PROTECTED] 11/26/2007 10:46 PM To John Lalande [EMAIL PROTECTED] cc wix-users@lists.sourceforge.net Subject Re: [WiX-users] uninstalling a product silently before installing a new one Thanks for the xml code, I have followed this and it is working in one scenerio. But tell me, should this work if product1 was installed using just me and the product2 is being installed using Everyone? Cuz i am testing this and this the case in which my product1 is not getting uninstalled. ..ab On Nov 27, 2007 3:23 AM, John Lalande [EMAIL PROTECTED][EMAIL PROTECTED] wrote: In theory (and in my projects), simply copy what you already have and replace 'product2guid' (which I hope is a uuid), with the UpgradeCode of the product you want uninstalled. In the new entry remove the UpgradeVersion that uses the NEWERPRODUCTFOUND property and replace PREVIOUSVERSIONSINSTALLED with something like OTHERPRODUCTFOUND or whatever makes sense for you. Make sure that OnlyDetect is No. I don't think you need the Property tags you have. They will be created on demand and will be set to the ProductCode of the detected products. Your updated Upgrade elements may look similar to this (adjust as necessary): Upgrade Id=product2guid UpgradeVersion Minimum=1.0.57 Property=NEWERPRODUCTFOUND OnlyDetect=yes IncludeMinimum=yes / UpgradeVersion Minimum= *1.0.0.0* http://1.0.0.0/ Maximum= 1.0.57 Property=PREVIOUSVERSIONSINSTALLED IncludeMinimum=yes / /Upgrade Upgrade Id=otherproductguid UpgradeVersion Minimum=*1.0.0.0* http://1.0.0.0/ Maximum=1.0.57 Property=OTHERPRODUCTFOUND IncludeMinimum=yes / /Upgrade Finally, take heed of Christopher's comments as there are some subtleties about individual file versions as well as where you have scheduled RemoveExistingProducts. Also, you may want to read the tutorial for more details on upgrades: * http://www.tramontana.co.hu/wix/lesson4.php*http://www.tramontana.co.hu/wix/lesson4.php . Good luck. John On Nov 26, 2007 8:55 AM, Abubakar [EMAIL PROTECTED][EMAIL PROTECTED] wrote: Hi, can you provide me the tags necessary to do this? Right now my Upgrade tags look like this: Upgrade Id=product2guid UpgradeVersion Minimum=1.0.57 Property=NEWERPRODUCTFOUND OnlyDetect=yes IncludeMinimum=yes / Property Id=NEWERPRODUCTFOUND Secure=yes / UpgradeVersion Minimum=*1.0.0.0* http://1.0.0.0/ Maximum=1.0.57 Property=PREVIOUSVERSIONSINSTALLED IncludeMinimum=yes / Property Id=PREVIOUSVERSIONSINSTALLED Secure=yes / /Upgrade regards, ..ab On Nov 26, 2007 7:16 PM, John Lalande [EMAIL PROTECTED][EMAIL PROTECTED] wrote: ab It is much simpler then what you are proposing. Simply add the UpgadeCode of the old product to the Upgrade table of your new product. The old one will be uninstalled in the same manner as a previous version...silently during the RemoveExistingProducts action. John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] uninstalling a product silently before installing a new one
Not really. I also agree with the notion that Per-User installs are evil. It's just such a royal pain to manage ( See Windows Installer Tao Rule #30 ). When I used to do SMS pushes in an enterprise environment, I'd never consider a per-user advertisement. All of my packages were hardwired Per-Machine installation and require Priviliged with no option to override. Abubakar [EMAIL PROTECTED] wrote: hmm, thats bad :( Any good or bad hacks coming to anyone's minds. Any thing ?? ..ab On Nov 27, 2007 12:06 PM, Kelly Leahy [EMAIL PROTECTED] wrote: Nope... As far as I know, NOTHING will work in that scenario. AFAIK, there's no way to handle this properly - you pretty much want to require that users either only can install as Everyone, or only can install as Just Me. Personally, I think Just Me is silly and can't come up with any good reason for this installer choice. Abubakar [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/26/2007 10:46 PM To John Lalande [EMAIL PROTECTED] cc wix-users@lists.sourceforge.net Subject Re: [WiX-users] uninstalling a product silently before installing a new one Thanks for the xml code, I have followed this and it is working in one scenerio. But tell me, should this work if product1 was installed using just me and the product2 is being installed using Everyone? Cuz i am testing this and this the case in which my product1 is not getting uninstalled. ..ab On Nov 27, 2007 3:23 AM, John Lalande [EMAIL PROTECTED] wrote: In theory (and in my projects), simply copy what you already have and replace 'product2guid' (which I hope is a uuid), with the UpgradeCode of the product you want uninstalled. In the new entry remove the UpgradeVersion that uses the NEWERPRODUCTFOUND property and replace PREVIOUSVERSIONSINSTALLED with something like OTHERPRODUCTFOUND or whatever makes sense for you. Make sure that OnlyDetect is No. I don't think you need the Property tags you have. They will be created on demand and will be set to the ProductCode of the detected products. Your updated Upgrade elements may look similar to this (adjust as necessary): Upgrade Id=product2guid UpgradeVersion Minimum=1.0.57 Property=NEWERPRODUCTFOUND OnlyDetect=yes IncludeMinimum=yes / UpgradeVersion Minimum= 1.0.0.0 Maximum=1.0.57 Property=PREVIOUSVERSIONSINSTALLED IncludeMinimum=yes / /Upgrade Upgrade Id=otherproductguid UpgradeVersion Minimum=1.0.0.0 Maximum=1.0.57 Property=OTHERPRODUCTFOUND IncludeMinimum=yes / /Upgrade Finally, take heed of Christopher's comments as there are some subtleties about individual file versions as well as where you have scheduled RemoveExistingProducts. Also, you may want to read the tutorial for more details on upgrades: http://www.tramontana.co.hu/wix/lesson4.php . Good luck. John On Nov 26, 2007 8:55 AM, Abubakar [EMAIL PROTECTED] wrote: Hi, can you provide me the tags necessary to do this? Right now my Upgrade tags look like this: Upgrade Id=product2guid UpgradeVersion Minimum=1.0.57 Property=NEWERPRODUCTFOUND OnlyDetect=yes IncludeMinimum=yes / Property Id=NEWERPRODUCTFOUND Secure=yes / UpgradeVersion Minimum=1.0.0.0 Maximum=1.0.57 Property=PREVIOUSVERSIONSINSTALLED IncludeMinimum=yes / Property Id=PREVIOUSVERSIONSINSTALLED Secure=yes / /Upgrade regards, ..ab On Nov 26, 2007 7:16 PM, John Lalande [EMAIL PROTECTED] wrote: ab It is much simpler then what you are proposing. Simply add the UpgadeCode of the old product to the Upgrade table of your new product. The old one will be uninstalled in the same manner as a previous version...silently during the RemoveExistingProducts action. John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Get easy, one-click access to your favorites. Make Yahoo! your homepage.- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Conditional installation of merge modules
Hi, I'm installing MFC71, CRT and STL merge modules together with my product. The problem I'm having is Windows Installer asks me to reboot at the end of the installation in case of a repair since some of those modules are held in use by Windows Explorer. At the installation, I don't have this problem. I assume is due to the way those merge modules are made. Is there a way to avoid this? I'm reading through blogs around Internet about policy_* merge modules (I don't really understand why do I need all those): http://msdn.technetweb3.orcsweb.com/astebner/archive/2007/02/13/building-an-msi-using-wix-v3-0-that-includes-the-vc-8-0-runtime-merge-modules.aspx I downloaded VC 2005 SP1 redistributable package from Microsoft but it doesn't install anything of that type (ie policy_* merge module files). http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647displaylang=en Any thoughts? Thanks, Dacian Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how. http://overview.mail.yahoo.com/- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 2.0 created MSI occasionally fails to install on Vista
I think I have found it, I'm not sure of a nice way to work around it
though. I've copied some code that launches IE after an install (this is
an IE only install, so no problem there) but it runs in the context of
the UI. I'm led to believe that this is where I'm mucking things up. You
can see from the code snippet below that CA_HelpInstall is the custom
action to launch IE.
Dialog Id=ExitDlg Title=!(loc.IDS_WIZDLG_CAPTION)
X=50 Y=50 Width=370 Height=270
Control Id=Finish Type=PushButton X=236 Y=243
Width=56 Height=17 Text=!(loc.IDS_BTN_FINISH) Default=yes
Cancel=yes
Publish Event=DoAction
Value=CA_HelpInstallInstallMode = Typical OR InstallMode =
Complete/Publish
Publish Event=EndDialog Value=Return1/Publish
/Control
Is it possible to move this outside of the UI and is it desirable?
Regards
Ryan
Rob Hamflett wrote:
If you're doing things via normal MSI methods (which you are, assuming the
values are correct) and
specifying [EMAIL PROTECTED]elevated (are you?), then I'm out of ideas,
sorry.
Aha, hold on. When you run from the elevated command prompt, the entire
installation runs elevated.
This means that the Internet Explorer instance you launch at the end of the
installation is also
running elevated. Is this possibly the real problem? The installation is
fine but you need to run
IE elevated for it to work?
Rob
Ryan O'Neill wrote:
The registration of the DLL is handled via RegistryValue elements
wrapped inside Component elements which are then inside three levels of
Directory elements (snippet below). So no custom actions involved for
the registry, I kind of got the impression they were not good. I do have
one however, to launch IE after the install (also shown below). I
upgraded to WiX v3 to see if I could get better error checking, then
cleared any warnings and still the same.
This may be relevant, I used InstallAware to create the initial bulk of
the installer but have edited by hand since then.
Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder Name=PFiles
Directory Id=INSTALLDIR Name=OSOYOU Internet
Explorer toolbar
Component Id=C_MainDll
Guid={DB020289-44CE-4A4C-9821-C96718B0FF3E}
File Id=FL_IEToolbar.dll ShortName=IETool
Name=IEToolbar.dll
Source=..\IEToolbar\ReleaseUMinDependency\IEToolbar.dll DiskId=1
KeyPath=yes /
RegistryKey Root=HKLM
Key=Software\Microsoft\Internet Explorer\Toolbar
RegistryValue Type=string Value= /
RegistryValue
Name={FD7DC3F5-F8EA-4F91-9665-4B8661392667} Type=string
Value=OSOYOU toolbar /
/RegistryKey
RegistryValue Root=HKCR
Key=CLSID\{FD7DC3F5-F8EA-4F91-9665-4B8661392667} Value=OSOYOU
toolbar Type=string /
CustomAction Id=CA_HelpInstall Return=asyncNoWait
Property=IEXPLORE ExeCommand=http://www.myurl.com/toolbarhelp;
Execute=immediate /
Thanks for keeping with me on this Rob, very much appreciated.
Regards
Ryan
Rob Hamflett wrote:
That article is missing a few important bits, as far as my understanding
goes. An installer written
for Vista should be marked as needing elevation, or not needing elevation.
If it does, you get
prompted when the installer switches over to the server side, which does
the actual work. Microsoft
knew they would have to cope with a ton of installers that were written
pre-Vista, so there's code
in there to elevate anything that looks like an installer. Basically
anything called setup.exe, or
with 'installer' or 'setup' in the description. That kind of thing, and I
think MSI files get
included in there.
Going back to your problem, I get the impression that when you say you run
it from a command prompt,
you actually mean you run it from an 'elevated' command prompt. If this is
the case, then it sounds
like the DLL is being registered outside the elevated part of the install.
Are you using a Custom
Action to do this, and if so, is it scheduled somewhere between
InstallInitialize and
InstallFinalize in the InstallExecuteSequence?
Rob
Ryan O'Neill wrote:
Been looking into this some more. I've asked the customer to log before
and after (nothing yet) but in the meantime they found this article on
how to elevate privileges for an MSI (
http://footheory.com/blogs/shane/archive/2007/08/03/vista-and-elevating-security-of-an-msi-to-run-as-administrator.aspx
).
Thats not the ONLY way to do this is it? Is the article author mistaken?
I see UAC prompts come up when I run my MSI so I thought it would be OK.
I'd hate to have to do a bodge because Vista has a security by obscurity
flaw.
Regards
Ryan
Rob Hamflett wrote:
The only thing
[WiX-users] FW: Error LIT0103: The system cannot find the file 'License.rtf' with type ''.
Having this error message when adding the -bf switch to the lit command, no such file name is included in my project any guess? Needless to mention that project is succeeding to built when removing the -bf switch. Command line is: C:\Program Files\Windows Installer XML v3\bin\lit.exe -out C:\Generic_Dialogs\bin\Debug\Generic_Dialogs.wixlib -bf -loc WixUI_en-us.wxl -sv obj\Debug\CancelDlg.wixobj obj\Debug\Common.wixobj obj\Debug\DiskCostDlg.wixobj obj\Debug\ErrorDlg.wixobj obj\Debug\ErrorProgressText.wixobj obj\Debug\ExitDialog.wixobj obj\Debug\FatalError.wixobj obj\Debug\FilesInUse.wixobj obj\Debug\LicenseAgreementDlg.wixobj obj\Debug\MaintenanceTypeDlg.wixobj obj\Debug\MaintenanceWelcomeDlg.wixobj obj\Debug\MsiRMFilesInUse.wixobj obj\Debug\OutOfDiskDlg.wixobj obj\Debug\OutOfRbDiskDlg.wixobj obj\Debug\PatchDlg.wixobj obj\Debug\PrepareDlg.wixobj obj\Debug\ProgressDlg.wixobj obj\Debug\ResumeDlg.wixobj obj\Debug\UserExit.wixobj obj\Debug\VerifyReadyDlg.wixobj obj\Debug\WaitForCostingDlg.wixobj obj\Debug\WelcomeDlg.wixobj obj\Debug\WelcomeEulaDlg.wixobj TIA - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] MSI does not auto elevate on Vista
Hi All,
I've moved on from my earlier problems with Vista to new exciting
problems! Since moving a custom action for launching IE out of the UI
sequence the installer is now not elevating privileges under Vista at
all during install (but does so during uninstall).
So I created a batch file to launch the MSI and right clicked on the
batch file (run as admin) and now, even when the product is completely
uninstalled I get 'another version' is already installed. So I think a
previous install went on a per machine basis and the tests I have been
doing are on a per user basis. I never intended to create a per user app
so I need to look at this.
My questions are;
1) Should it not automatically ask for elevation (the shield icon is
showing up nicely on my button, which sounds correct) according to code
snippet 1 below?
2) Somehow I am creating a per-user / hybrid install, will creating a
shortcut under program files do this?
Thanks in advance
Ryan
Snippet 1:
Product Name=MY Internet Explorer toolbar
Id={2A426A63-3F69-48AD-B28A-2EA97457B08C} Language=1033
Codepage=1252 Version=1.0 Manufacturer=ME
UpgradeCode={5608688A-0582-48C4-8900-1C65E2FB5345}
Package Languages=1033 Keywords=Installer Description=MY
toolbar installer Comments=blah Manufacturer=ME
InstallerVersion=100 Compressed=yes SummaryCodepage=1252
InstallPrivileges=elevated /
Media Id=1 Cabinet=ME.cab EmbedCab=yes DiskPrompt=CD-ROM
#1 /
Property Id=DiskPrompt Value=My toolbar Installation [1] /
Property Id=IEXPLORE
RegistrySearch Id=FIND_IEXPLORE Root=HKLM
Key=SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\IEXPLORE.EXE
Type=raw /
/Property
Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder Name=PFiles
Directory Id=INSTALLDIR Name=MY Internet Explorer
toolbar
Component Id=C_MainDll
Guid={DB020289-44CE-4A4C-9821-C96718B0FF3E}
File Id=FL_IEToolbar.dll ShortName=IETool
Name=IEToolbar.dll
Source=..\IEToolbar\ReleaseUMinDependency\IEToolbar.dll DiskId=1
KeyPath=yes /
RegistryKey Root=HKLM
Key=Software\Microsoft\Internet Explorer\Toolbar
RegistryValue Type=string Value= /
RegistryValue
Name={FD7DC3F5-F8EA-4F91-9665-4B8661392667} Type=string Value=My
toolbar /
/RegistryKey
RegistryValue Root=HKCR
Key=CLSID\{FD7DC3F5-F8EA-4F91-9665-4B8661392667} Value=My toolbar
Type=string /
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Conditional installation of merge modules
Are you installing into the System folder? The 71 Dlls can be side by side, so you can install them into your application folder. Visual Studio 2005 support Dlls are SxS in the WinSxS folder - they're installed differently. Was MFC71 a typo? That's the Visual Studio 2003 MFC support, but elsewhere you're referring to 2005. I'm not sure what you're getting at with that in case of a repair - this is just at install time, right? Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of fiordean dacian Sent: Tuesday, November 27, 2007 7:07 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Conditional installation of merge modules Hi, I'm installing MFC71, CRT and STL merge modules together with my product. The problem I'm having is Windows Installer asks me to reboot at the end of the installation in case of a repair since some of those modules are held in use by Windows Explorer. At the installation, I don't have this problem. I assume is due to the way those merge modules are made. Is there a way to avoid this? I'm reading through blogs around Internet about policy_* merge modules (I don't really understand why do I need all those): http://msdn.technetweb3.orcsweb.com/astebner/archive/2007/02/13/building -an-msi-using-wix-v3-0-that-includes-the-vc-8-0-runtime-merge-modules.as px I downloaded VC 2005 SP1 redistributable package from Microsoft but it doesn't install anything of that type (ie policy_* merge module files). http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4 A14-984D-389C36F85647displaylang=en Any thoughts? Thanks, Dacian Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how. http://us.rd.yahoo.com/evt=51732/*http:/overview.mail.yahoo.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] outlook com addin
Ben, I've created an installer for a C# COM addin using Wix, and I ran into some of the same problems. The best way to get the necessary COM settings for a registration seems to be to use a registry sniffer that can compare snapshots. I took a registry snapshot, registered the assembly, and then took another snapshot and grabbed the diff between the two. Then I put all of these registry settings into my wxs file, and everything seemed to work. Probably not the most elegant solution, but another one that you can try out. Just remember to try it on as clean a system as possible-a virtual PC is a good place to start. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Reichelt Sent: Saturday, November 24, 2007 5:40 PM To: Ben Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] outlook com addin I tried running heat on the directory with my .dlls and .ocxs, but it would just hang :( I tried the suggestion of setting the SelfRegCost='1' on each component and that did the trick, thanks for the replies. ben On Nov 23, 2007 7:20 PM, Ben [EMAIL PROTECTED] wrote: Try running heat on a directory (not just a file) that contains all the assemblies you need to register. Ben Reichelt wrote: I am making an installer for an Outlook vb6 COM addin. The addin consists of 7 COM assemblies that need to be copied to the target machine and then have regsvr32 called on each assembly. I have read that calling out to regsvr32.exe from the msi is not recommended and instead you should manually create the registry keys needed for each assembly. The problem is that when I run heat.exe on my main assembly, it only generates a TypeLib wix element, not everything that is needed to registry the assembly as an Outlook addin. When I manually run regsvr32 after installation, then the assembly is correctly added to Outlook. I can't locate all the steps necessary to property register an assembly as an Outlook addin, so I can't do it manually at this point. I have scoured the internet looking for someone else who has done this, but I can't find anyone. Does anyone have experience in making Outlook (or Office) addin installers? Thanks - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Searching this list - Why do I get all day long Timed out waiting for response from Search Server? eom
- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Recreating duplicate .msi from revision control system
Kelly is exactly correct. In this case, the first autogenerated GUID that is getting you is the Package/@Id. The MSI SDK says that the Package/@Id should be unique for every MSI file. Arguably you could say the Ids should be the same in this case (and you could override the autogenerate) but typically, people just save the gold bits. Kelly Leahy wrote: I don't know if it's possible to produce exactly the same MSI, but I think your problem is related to automatically generated package codes or product codes. If you want to be able to rebuild an MSI that acts exactly the same as one that already went out the door (I think this is generally a bad idea and that you should save every MSI that you release somewhere 'special' rather than relying on being able to rebuild them), you need to force all the autogenerated IDs to be identical from one build to the next. The only way to do this is to fully specify all those IDs (packagecode productcode upgradecode, etc.) and then make sure you update them when appropriate (when building a new version of the MSI). Kelly - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] how to use quiet custom action
There are topics in the WiX.chm file about the Quite Exec custom action. diwakar09 wrote: Hi, In my installation i am using custom action for changing the file contents, I need to change 8-9 files. It shows many command window at installation, I want to hide these windows, I am very new to wix, So if any one can provide some sample that can clarify how to use quiet custom action, will good for me Please help me Thanx in advance. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] New Windows Group Permissions
1. No. The documentation for the Group element clearly states, Searches for an existing group in the specified domain. Groups cannot be created by this element. 2. Even if the directory already exists you can use CreateFolder to ensure it exists and set permissions. Dhaval Patel wrote: Couple of questions: 1) Is it possible to create a new Windows group in WIX2.X? 2) We have some application-level users that need write permissions to the TempFolder for compiling Web Services' related temporary files - only issue is that I can't access the Permission element outside a CreateFolder / element. Is there a way to alter permissions on a pre-exisiting folder? Thanks in advance for any responses/ideas. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Error 1721 - How to resolve
Your custom action failed (i.e. returned non-zero). SaiTeja wrote: Hi, Below is my custom action CustomAction Id=LQ_UninstallComService Return=check HideTarget=no Execute=deferred Impersonate=yes TerminalServerAware=no ExeCommand=UninstallComService FileKey=qmireg.exe /CustomAction InstallExecuteSequence Custom Action=LQ_UninstallComService Sequence=1700Installed And REMOVE=ALL/Custom /InstallExecuteSequence When am trying to uninstall am getting following error. Can any one tell me what is the probelm??? Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: LQ_UninstallComService, location: C:\Program Files\LQ\manifests\qmireg.exe, command: UninstallComService Thanks - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] RegistryKeys on x64 always deleted?
Well, when a Component is uninstalled all of its contained resources are supposed to be removed. You can prevent the Component from being removed by marking it permanent. I have no idea why it works in one case and not another. A verbose log file would tell you what's being removed when and why. Mailinglist wrote: Hi, in our x64 Setup we write some registry keys to the native registry hive, using this pattern: RegistryValue Id='EWS.User.Path' Root='HKLM' Key='Software\XXX\XXX' Name='UserExePath' Action='write' Type='string' Value='[User]User.exe' / On uninstall those keys are removed, but I do not want to remove them. Is it a bug? Same code as x86 package works just as expected. Any hints welcome */Oliver Friedrich/* /IT-Consultant/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
