Re: [WiX-users] Error 1721 - How to resolve

[SaiTeja]

Yaa I understand.

Could you tell me how to resolve this


Thanks


Rob Mensching-4 wrote:
> 
> Your custom action failed (i.e. returned non-zero).
> 
> SaiTeja wrote:
>> Hi,
>>
>> Below is my custom action
>>
>> > HideTarget="no"
>> Execute="deferred" Impersonate="yes" TerminalServerAware="no"
>> ExeCommand="UninstallComService" FileKey="qmireg.exe">
>> 
>>
>>  
>>   Installed And
>> REMOVE="ALL"
>>
>>
>>
>>
>> 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
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Error-1721---How-to-resolve-tf4859815.html#a13986591
Sent from the wix-users mailing list archive at Nabble.com.


-
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] Services + Vista + GAC

[Christopher Painter]

I would have thought that the design bug would have been obvious based merely 
on understanding of CA scheduling.Stefan has a great article on the subject 
that I frequently refer InstallShield users to.  I can remember a day years ago 
when I read it ( and your component rules truth statemetns blog ) where I said 
to myself `I don't really understand this completely, but I can tell that  it's 
super important and I'm going to keep reading it everyday until I do.`
   
  I know transacted installations are a `good thing` but it's pretty darn 
impossible if the underlying technology that is being configured doesn't 
support it.   It's not like you can create an RBF file and use it to bring the 
user back to life.And last time I checked, the Winnt:// provider's computer 
object only has a delete method and not a commit and revert method.
   
  I'll stop there because if I go any further I'd be giving a reccomendation on 
what I think it should do
  

Rob Mensching <[EMAIL PROTECTED]> wrote:
  Today it doesn't.

This is a bug a dev in VS (Mike) pointed out fairly recently and is 
going through the exercise of investigating the options to see which is 
the lesser of all evils. He also found that the extended permission 
custom action didn't correctly reset ACLs on rollback and is working 
through that bug right now. Of course, the Windows Installer made it 
tricky because it appears to revert permissions on registry keys on 
rollback no matter what.

Ahh, the joys of writing system modifying custom actions for the Windows 
Installer.


Christopher Painter wrote:
> How does WiX handle the deletion of the user if rollback is disabled 
> by policy? 
>
>



   
-
Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how.-
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] XmlFile From Property

[Rob Mensching]

The Xml custom actions are configured to run after files are installed for
exactly the case you list below.

-Original Message-
From: James Renton [mailto:[EMAIL PROTECTED] 
Sent: Monday, November 05, 2007 13:14
To: Rob Mensching
Subject: RE: [WiX-users] XmlFile From Property

That's great!

But with these "standard" custom actions, how do I configure when they
run?  I want to make sure the file exists that I am editing...

Thanks,

James A. Renton
Castel, Inc.

-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 04, 2007 5:08 PM
To: James Renton
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] XmlFile From Property

No, the columns for data in XmlFile and XmlConfig should all be
Formatted.  That means you can use the syntax "[PropertyName]" to get
the value of a Property.  The MSI SDK has more info.

James Renton wrote:
>
> I was looking at using the XmlFile custom action.
>
>
>
> I wanted to store the values in the Property table; and issue various
> installs with setting customized (by me) using Orca.  However, it
> appears as if you have to hard code the value attribute of the xml
> tag; and that it therefore cannot reference the properties table.
>
>
>
> Is this in fact true, or is there a way for me to do what I suggest?
>
>
>
> Let me know,
>
>
>
> James
>
> Beverly, MA
>
>

>
>

-
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a
browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
>

>
> ___
> 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] Services + Vista + GAC

[Rob Mensching]

Today it doesn't.

This is a bug a dev in VS (Mike) pointed out fairly recently and is 
going through the exercise of investigating the options to see which is 
the lesser of all evils.  He also found that the extended permission 
custom action didn't correctly reset ACLs on rollback and is working 
through that bug right now.  Of course, the Windows Installer made it 
tricky because it appears to revert permissions on registry keys on 
rollback no matter what.

Ahh, the joys of writing system modifying custom actions for the Windows 
Installer.


Christopher Painter wrote:
> How does WiX handle the deletion of the user if rollback is disabled 
> by policy?   
>
>


-
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?

[Rob Mensching]

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:
>
>  
>
>  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

Re: [WiX-users] Error 1721 - How to resolve

[Rob Mensching]

Your custom action failed (i.e. returned non-zero).

SaiTeja wrote:
> Hi,
>
> Below is my custom action
>
>  Execute="deferred" Impersonate="yes" TerminalServerAware="no"
> ExeCommand="UninstallComService" FileKey="qmireg.exe">
> 
>
>  
>   Installed And
> REMOVE="ALL"
>
>
>
>
> 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] New Windows Group & Permissions

[Rob Mensching]

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
>  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] Deleting SHortcuts(Start->Prgs-> ...)

[Rob Mensching]

Look in a verbose log file and make sure the Component that contains the 
Shortcut is scheduled to be uninstalled.

SaiTeja wrote:
> Hi,
>
> I created short cuts using following code
>
>  Name="Foobar10" 
>   LongName="Foobar 1.0" WorkingDirectory='INSTALLDIR'
>   Icon="Foobar10.exe" IconIndex="0" />
>   
>  LongName="Programs">
>LongName="Foobar 1.0" />
> 
>
>  
>
>
> But at the time of un installing created short cut is not deleted.
>
> Can  any one tell me what is the problem here???
>
>
>
>
>   


-
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

[Rob Mensching]

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] Recreating duplicate .msi from revision control system

[Rob Mensching]

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] Reuse merge module in same product

[Rob Mensching]

As you've found, the design of Merge Modules prevent them from being 
merged twice.

si wrote:
> Hi,
>
> Trying to get a product built for Reporting Services for a custom data
> and security extension.
>
> Reporting Services has ReportServer and ReportManager directories,
> and I need to copy files from the same merge modules into each of
> their respective bin directories.
>
> Is this possible?  Can't find any examples and my attempts all fall over
> (duplicate file identifiers, etc)
>
> Or do I need to create separate products?  The problem with that
> is they are really dependent upon each other (i.e. configuration)
>
> Thanks for any guidance.
>
> cheers
> si
>
> -
> 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] outlook com addin

[Andrew Sampson]

I've had a similar problem - our Wise MSIs were previously using
regasm/regsvr32 custom actions to register DLLs. In the switch to WiX
though, I've written a CompilerExtension to get the registration info on
compile and output it into the registry table of the generated MSI. It's
fairly rough still, but seems to do the job well. It also handles ongoing
development of the DLL - if the interfaces change or get added to, the new
registration info is pulled in automatically the next time the MSI is built.


 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris Bardon
Sent: Wednesday, 28 November 2007 3:45 AM
To: Ben Reichelt; Ben
Cc: wix-users@lists.sourceforge.net
Subject: 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  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
  

 

 

-
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

[WiX-users] Searching this list - Why do I get all day long "Timed out waiting for response from Search Server"?

[Serge Gart (Implement.Com)]

-
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] outlook com addin

[Chris Bardon]

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  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

Re: [WiX-users] Conditional installation of merge modules

[Wilson, Phil]

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-389C36F85647&displaylang=en

Any thoughts?

Thanks,
Dacian

 



Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See
how.  

-
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

[Ryan O'Neill]

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:




















-
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] FW: Error LIT0103: The system cannot find the file 'License.rtf' with type ''.

[Albert Shamsiyan]

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

Re: [WiX-users] WiX 2.0 created MSI occasionally fails to install on Vista

[Ryan O'Neill]

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.



InstallMode = "Typical" OR InstallMode = 
"Complete"
1


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.
>>
>> 
>> 
>> 
>> > Guid="{DB020289-44CE-4A4C-9821-C96718B0FF3E}">
>> > Name="IEToolbar.dll" 
>> Source="..\IEToolbar\ReleaseUMinDependency\IEToolbar.dll" DiskId="1" 
>> KeyPath="yes" />
>> > Key="Software\Microsoft\Internet Explorer\Toolbar">
>> 
>> > Name="{FD7DC3F5-F8EA-4F91-9665-4B8661392667}" Type="string" 
>> Value="OSOYOU toolbar" />
>> 
>> > Key="CLSID\{FD7DC3F5-F8EA-4F91-9665-4B8661392667}" Value="OSOYOU 
>> toolbar" Type="string" />
>>
>> > 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
>
> Ro

[WiX-users] Conditional installation of merge modules

[fiordean dacian]

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-389C36F85647&displaylang=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] uninstalling a product silently before installing a new one

[Christopher Painter]

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): 



  
   

 
  


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: 
  

 
  
 
  

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

Re: [WiX-users] uninstalling a product silently before installing a new one

[Abubakar]

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):
>
>
> 
>   OnlyDetect="yes" IncludeMinimum="yes" />
>   http://1.0.0.0/>" Maximum="
> 1.0.57" Property="PREVIOUSVERSIONSINSTALLED" IncludeMinimum="yes" />
> 
> 
>  http://1.0.0.0/>" Maximum="1.0.57"
> Property="OTHERPRODUCTFOUND" IncludeMinimum="yes" />
> 
>
> 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]<[EMAIL PROTECTED]>>
> wrote:
> Hi, can you provide me the tags necessary to do this?
> Right now my Upgrade tags look like this:
>
> 
>   OnlyDetect="yes" IncludeMinimum="yes" />
>  
>  http://1.0.0.0/>" Maximum="1.0.57"
> Property="PREVIOUSVERSIONSINSTALLED" IncludeMinimum="yes" />
>  
>
> 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] WiX 2.0 created MSI occasionally fails to install on Vista

[Ryan O'Neill]

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.
>>
>> 
>> 
>> 
>> > Guid="{DB020289-44CE-4A4C-9821-C96718B0FF3E}">
>> > Name="IEToolbar.dll" 
>> Source="..\IEToolbar\ReleaseUMinDependency\IEToolbar.dll" DiskId="1" 
>> KeyPath="yes" />
>> > Key="Software\Microsoft\Internet Explorer\Toolbar">
>> 
>> > Name="{FD7DC3F5-F8EA-4F91-9665-4B8661392667}" Type="string" 
>> Value="OSOYOU toolbar" />
>> 
>> > Key="CLSID\{FD7DC3F5-F8EA-4F91-9665-4B8661392667}" Value="OSOYOU 
>> toolbar" Type="string" />
>>
>> > 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 somethi

Re: [WiX-users] WiX 2.0 created MSI occasionally fails to install on Vista

[Rob Hamflett]

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.
> 
> 
> 
> 
>  Guid="{DB020289-44CE-4A4C-9821-C96718B0FF3E}">
>  Name="IEToolbar.dll" 
> Source="..\IEToolbar\ReleaseUMinDependency\IEToolbar.dll" DiskId="1" 
> KeyPath="yes" />
>  Key="Software\Microsoft\Internet Explorer\Toolbar">
> 
>  Name="{FD7DC3F5-F8EA-4F91-9665-4B8661392667}" Type="string" 
> Value="OSOYOU toolbar" />
> 
>  Key="CLSID\{FD7DC3F5-F8EA-4F91-9665-4B8661392667}" Value="OSOYOU 
> toolbar" Type="string" />
> 
>  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

Re: [WiX-users] Calling embedded binaries with dependencies in WIX

[John Hall]

> 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

[WiX-users] dark.exe : error DARK0001 :

[SaiTeja]

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-binarieszip>dark.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] WiX 2.0 created MSI occasionally fails to install on Vista

[Ryan O'Neill]

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.












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 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 re

Re: [WiX-users] WiX 2.0 created MSI occasionally fails to install on Vista

[Rob Hamflett]

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;
>> 
>> > Key="Software\Microsoft\Internet Explorer\Toolbar">
>> > Value="My toolbar" />
>> 
>> > 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/direc

Re: [WiX-users] WiX 2.0 created MSI occasionally fails to install on Vista

[Ryan O'Neill]

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;
> 
>  Key="Software\Microsoft\Internet Explorer\Toolbar">
>  Value="My toolbar" />
> 
>  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/
>> 
>
>