date:20110222

[WiX-users] running uninstallation as administrator

2011-02-22 Thread MYFLEX


Hi all,

our installer will run the different custom actions at the time of
uninstallation. these custom actions needs the administrator previleges. how
to run my uninstallation "as administrator" from the Add Or Remove Programs
panel. if I run the uninstallation with the EXE(run as administrator) ,
Everything is fine. but If I run from add/Programs , it is giving the access
denied error. Please suggest me how can I solve it.
-- 
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/running-uninstallation-as-administrator-tp6055283p6055283.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Disallowing uninstallation of patch

2011-02-22 Thread Tom Crozier

I still need help. 

The 1st patch is created by using msimsp between the RTM and patched version is 
around 35MB and contains the new components and UI sequence items I added and 
works as expected. 

The second patch is created by using the same procedure diffing the 2nd patched 
version (which is identical to the 1st patch version with a couple of updated 
files) with the 1st patched version. When inspecting the 2nd patch msi (via 
orca) the new components are included but the generated msp file is only 11KB. 
And when I try to run this patch with MSIENFORCEUPGRADECOMPONENTRULES=1 I get a 
2771 error and none of the new components that were added in the 1st patch and 
are included in the 2nd are listed in the log file.
Below is the Patch Creation file I used to create the 2nd patch (This is almost 
identical to the one I used to create the first patch except the first patch is 
a small update and does not allow removal since it adds a new directory and 
files)


http://schemas.microsoft.com/wix/2006/wi";>

  
  
  

  







  



  





  



-Original Message-
From: Tom Crozier [mailto:tcroz...@rackwise.com] 
Sent: Tuesday, February 22, 2011 1:03 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Disallowing uninstallation of patch

One more piece of information. When I run the second patch I get the following 
message for each component (1 per file) for each of the files that were added 
in the first patch and are still part of the second patch.

Patch Supersedence: Component 'CompPatchedContentDir' is added by a superseded 
patch and will become orphaned.

I looked at both the msi packages via Orca and the component exists in both the 
1st and 2nd patch msi's. Why does it say they will be orphaned?

I had tried this but when I run the second patch the UI sequence does not get 
run. Any ideas why this would happen?

-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Sent: Tuesday, February 22, 2011 11:58 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Disallowing uninstallation of patch

If you base the second patch on the RTM, itll need the new createfolder table
entries in case the first patch is never applied. You need to base the second
patch on the patched MSI (RTM + patch 1).


-Original Message-
From: Tom Crozier [mailto:tcroz...@rackwise.com] 
Sent: 22 February 2011 16:44
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Disallowing uninstallation of patch

Hi,

What I am trying to accomplish is to first install an unremovable Small
Update patch that adds new files into a new directory. (This works)
Next is to install a removable Minor Update patch that delivers new versions
of the files that were added in the first patch as well as modifications of
existing dlls etc... (This does not)
What I am getting is the following message in the msi log file:
Disallowing uninstallation of patch {D40C91BE-8619-426B-8B11-2AEA5106A767}
because it adds new entries to table CreateFolder
Even though these files were added in the first patch as well.

The first patch is set with AllowRemoval='no' and Supersede="no" and is built
against the RTM version.

The second patch is set with AllowRemoval='yes' and Supersede=" yes" and is
also built against the RTM version.

I had tried creating a small test installer and this same sequence seems to
work.

Thanks - Tom

-
-
Index, Search & Analyze Logs and other IT data in Real-Time with Splunk 
Collect, index and harness all the fast moving IT data generated by your 
applications, servers and devices whether physical, virtual or in the cloud.
Deliver compliance at lower cost and gain new business insights. 
Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.


--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
WiX-user

Re: [WiX-users] Trigger custom action on NEWERFOUND

2011-02-22 Thread Andy Clugston

I believe I found a way to accomplish this. Using the OnExit=error as well
as some other properties I already had setup seems to be working.

On Tue, Feb 22, 2011 at 3:38 PM, Andy Clugston  wrote:

> All,
>
> I currently have the "prevent downgrade custom action" below...
>
>  After='FindRelatedProducts'>NEWERFOUND
> 
>
> One thing that I am tasked to support is updating of a product at runtime.
> So, shutting down the app(s), invoking msiexec, and starting them back up.
> The "starting them back up" is handled by custom actions in the MSI. The one
> use case that I am having trouble with is when an older version of the
> product is attempted to be installed on a system when a newer version
> already exists. The action above takes care of it, but I still need to
> restart the application. It appears that the "Error" handler causes an
> immediate exit of msiexec. I have tried to place my app-startup action
> before and after NoDowngradeAction, but in both cases the custom action is
> not called. The app-startup custom action is of type "immediate".
>
> As always, any advice is appreciated.
>
> Thanks.
>
--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to change the Windows Integrity level in Vista/Win7 when launching the application

2011-02-22 Thread little.forest

If you happen to know the answer, please let us know.

Basically, there are some strange problems if the app is launched right after 
installation. But it works fine if the app is triggered from the system Start 
menu. Initially I thought this is our app's problem. But some of our developers 
dug in and try to convince me that the Integrity Level is different between 
launching it right after installation and triggered from Start menu. But I'm 
not 
sure they are correct or not. 

So my question is, why they have different Integrity Level? And how to make it 
the same as normal cases.

Thanks. 

From: little.forest 
To: General discussion for Windows Installer XML toolset. 

Sent: Mon, February 21, 2011 1:12:51 PM
Subject: Re: [WiX-users] How to change the Windows Integrity level in 
Vista/Win7 
when launching the application

Thanks Rob for your reply.

Honestly, I'm not sure when the custom action is scheduled because I took the 
example("How To: Run the Installed Application After Setup") from Wix.chm. 
Here's our code:

WIXUI_EXITDIALOGOPTIONALCHECKBOX = 1 and NOT Installed

As you can see, it's almost identical to the original example code in Wix.chm.

Anyways, I also run the installer and checked the log. Here's some log:
MSI (c) (B8:D4) [11:44:33:697]: Decrementing counter to disable shutdown. If 
counter >= 0, shutdown will be denied.  Counter after decrement: -1
MSI (c) (B8:D4) [11:44:33:697]: PROPERTY CHANGE: Deleting SECONDSEQUENCE 
property. Its current value is '1'.
Action ended 11:44:33: ExecuteAction. Return value 1.
MSI (c) (B8:D4) [11:44:33:697]: Doing action: ExitDialog
Action 11:44:33: ExitDialog. 
Action start 11:44:33: ExitDialog.
Action 11:44:33: ExitDialog. Dialog created
MSI (c) (B8:DC) [11:44:35:785]: Doing action: LaunchApplication
Action 11:44:35: LaunchApplication. 
Action start 11:44:35: LaunchApplication.
MSI (c) (B8:EC) [11:44:35:787]: Invoking remote custom action. DLL: 
C:\Users\UserA\AppData\Local\Temp\MSI8A32.tmp, Entrypoint: WixShellExec
Action ended 11:44:36: LaunchApplication. Return value 1.
Action ended 11:44:36: ExitDialog. Return value 1.
Action ended 11:44:36: INSTALL. Return value 1.
MSI (c) (B8:D4) [11:44:36:124]: Destroying RemoteAPI object.
MSI (c) (B8:48) [11:44:36:124]: Custom Action Manager thread ending.

So the question now is: is there a way to launch the application by giving the 
same Integrity Level as we start it from the system Start menu?

Thanks a lot.

From: Rob Mensching 
To: General discussion for Windows Installer XML toolset. 

Sent: Sat, February 19, 2011 9:26:54 AM
Subject: Re: [WiX-users] How to change the Windows Integrity level in 
Vista/Win7 

when launching the application

When is your custom action scheduled?

On Fri, Feb 18, 2011 at 3:17 PM, little.forest wrote:

> We found a problem in Vista/Win7:
> If we launch the application from the installer for the fresh installation,
> the
> Integrity level is empty. The process is on the same level as
> "explorer.exe".
> If we start the application from Start menu after the installation, the
> Integrity level is Medium(just like other applications). And the process is
> under "explorer.exe".
>
> The question is, how to launch the application from installer to make it
> have
> "Medium" Integrity level.
>
> By the way, by using "Process Explorer" from SystemInternals and turning on
> the
> Integrity field, the Integrity level field will show up.
>
> The reason we ask this is because: we have a bug which seems related to
> this
> Integrity Level thing. If the app is started from the Start menu, things
> are
> fine. If the app is launched from the installer for the 1st time
> installation,
> some functionalities don't work. I tried to set the 'Impersonate' field to
> be
> 'no'. But it doesn't help.
>
> Here's our launch app code:
> Value="[INSTALLLOCATION]$(var.ExeFile)" />
>  BinaryKey="WixCA"
> DllEntry="WixShellExec"
> Impersonate="no"
> />
>
>
> Thanks in advance.
>
>
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>

-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel

Re: [WiX-users] Running a custom action with elevated privileges

2011-02-22 Thread Jeff Wisgo

I am working on a upgrade scenario and have to get rid of a process from one
of many possible old versions. Killing the process is the only way to make
sure the upgrade succeeds cleanly, as there are no hooks in the legacy code
for a clean shutdown.

There *has* to be some way to force the MSI to run as the same privileges as
the user I am running it from, I just cant seem to figure out what it is.


Jeff

On Tue, Feb 22, 2011 at 1:22 PM, Wilson, Phil wrote:

> Exactly - the MSI team apparently uses the least privilege rule, which is
> why it runs without a bunch of privileges that are considered non-essential
> to an install.
>
> What is special about this process that you have to go into it and kill it?
> Is there really no other way to get it to go away?
>
> Phil Wilson
>
>
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Tuesday, February 22, 2011 7:54 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Running a custom action with elevated privileges
>
> IIRC, Windows Installer purposefully removes the Debug privilege from its
> custom action servers (which are what call you).I think the MSI SDK lists
> the priveleges removed somewhere...
>
> On Tue, Feb 22, 2011 at 6:13 AM, Jeff Wisgo  wrote:
>
> > Phil,
> >
> > I checked and you are correct, the msiexec.exe that is the parent process
> > is
> > running with limited privileges. But isn't the purpose of "deferred" mode
> > to
> > run with elevaged privileges? Or are you saying that it will only elevate
> > as
> > far as msiexec's privileges are?
> >
> > I ran msiexec.exe from a SYSTEM (full privileged) command prompt, and
> > msiexec.exe still downgrades its privileges. Is this something being done
> > by
> > the OS or the binary itself? I'm hoping there is some way to force
> msiexec
> > to run with full privileges.
> >
> > Thanks,
> >
> > Jeff
> >
> > On Mon, Feb 21, 2011 at 3:00 PM, Wilson, Phil  > >wrote:
> >
> > > The system account is irrelevant here. What matters is the list of
> rights
> > > that the msiexec process is running with, and it does not have all
> > possible
> > > rights enabled all of the time. I think you've already discovered that,
> > so I
> > > don't know what to advise. I forget where this is documented, but that
> > code
> > > (and therefore your custom action) is running with a limited list of
> > rights
> > > (something that started on MSI 4.0) that does not include the one
> > required
> > > to terminate processes.
> > >
> > > Phil Wilson
> > >
> > > -Original Message-
> > > From: Jeff Wisgo [mailto:locksl...@gmail.com]
> > > Sent: Sunday, February 20, 2011 3:32 PM
> > > To: General discussion for Windows Installer XML toolset.
> > > Subject: Re: [WiX-users] Running a custom action with elevated
> privileges
> > >
> > > Umesh,
> > >
> > > Thanks for responding to my question.
> > >
> > > I am using OpenProcess(PROCESS_TERMINATE, ...). When I execute the same
> > > exact code from a system account with elevated privileges using PSEXEC,
> > it
> > > works, so I know there is something wrong with the privileges when my
> > code
> > > runs as a Custom Action. I also have verified this by looking at the
> > > privileges with Process Explorer.
> > >
> > > Any other ideas?
> > >
> > > Thanks,
> > >
> > > Jeff
> > >
> > > On Sat, Feb 19, 2011 at 12:56 AM, Umeshj 
> > > wrote:
> > >
> > > >
> > > >
> > > > What access level are you using for OpenProcess() ?
> > > >
> > > > A simple PROCESS_TERMINATE is sufficient. If you are using
> > > > PROCESS_ALL_ACCESS it will fail.
> > > > I had experienced the same problems and after changing the
> > > dwDesiredAccess
> > > > param it worked well.
> > > >
> > > > Umesh
> > > > --
> > > > View this message in context:
> > > >
> > >
> >
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Running-a-custom-action-with-elevated-privileges-tp6041158p6042577.html
> > > > Sent from the wix-users mailing list archive at Nabble.com.
> > > >
> > > >
> > > >
> > >
> >
> --
> > > > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
> > XE:
> > > > Pinpoint memory and threading errors before they happen.
> > > > Find and fix more than 250 security defects in the development cycle.
> > > > Locate bottlenecks in serial and parallel code that limit
> performance.
> > > > http://p.sf.net/sfu/intel-dev2devfeb
> > > > ___
> > > > WiX-users mailing list
> > > > WiX-users@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > > >
> > >
> > >
> >
> --
> > > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
> XE:
> > > Pinpoint memory and threading errors before they happen.
> > > Find and fix more than 250 security defects in the development cycle.
> >

[WiX-users] Trigger custom action on NEWERFOUND

2011-02-22 Thread Andy Clugston

All,

I currently have the "prevent downgrade custom action" below...

NEWERFOUND


One thing that I am tasked to support is updating of a product at runtime.
So, shutting down the app(s), invoking msiexec, and starting them back up.
The "starting them back up" is handled by custom actions in the MSI. The one
use case that I am having trouble with is when an older version of the
product is attempted to be installed on a system when a newer version
already exists. The action above takes care of it, but I still need to
restart the application. It appears that the "Error" handler causes an
immediate exit of msiexec. I have tried to place my app-startup action
before and after NoDowngradeAction, but in both cases the custom action is
not called. The app-startup custom action is of type "immediate".

As always, any advice is appreciated.

Thanks.
--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] State of WiX 3.6 - Burn?

2011-02-22 Thread John Robbins

Hi Chris,

Funny you should ask. :) I am in the middle of working on a Burn-based boot 
strapper as I type. I hacked together a prototype and was able to a C# Windows 
Form UI working for install, repair, and remove. The biggest hurdle is that the 
only documentation is the WiX 3.6 EXE installer. However, since the team now 
gives out the PDB files, I just debugged through the C++ and C# code to see how 
things worked. That was plenty of documentation for me and gave me the 
confidence to choose Burn even though it's a work in progress. In fact, I've 
been disappointed that I haven't found a bug to report yet. :)

The project I'm working on has a list of prereqs a mile long, with all sorts of 
odd validations that have to be done before anything can be installed so the 
boot strapper was critical to our success. Having looked at everything I felt 
that Burn is plenty good enough to use. 

As for your requirement that you run the MSI native UI, that's not supported.

As I am doing this work under contract, I'm trying to see if my client will 
give me permission to blog about my sample so I can share it with others.

John
Wintellect
http://www.wintellect.com
+1-877-968-5528


-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com] 
Sent: Tuesday, February 22, 2011 9:55 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] State of WiX 3.6 - Burn?

I haven't really been following the status of the weekly builds so I was hoping 
someone could give me an honest assessment of the current state of Burn.

If I had an MSI that needed to bootstrap Windows Installer 4.5 and .NET 
Framework 3.5sp1 then run 1 single MSI,  is v3.6 currently stable enough to do 
this?

Is Burn capable of using the MSI's native UI after running the prereqs or must 
Burn provide the UI?

My thanks in advance as I may not be able to respond to this email in the near 
future but I will read follow ups.

---
Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know 
a secret or read a really good thread that deserves attention? E-Mail Me


  

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Running a custom action with elevated privileges

2011-02-22 Thread Wilson, Phil

Exactly - the MSI team apparently uses the least privilege rule, which is why 
it runs without a bunch of privileges that are considered non-essential to an 
install. 

What is special about this process that you have to go into it and kill it? Is 
there really no other way to get it to go away? 

Phil Wilson 


-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: Tuesday, February 22, 2011 7:54 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Running a custom action with elevated privileges

IIRC, Windows Installer purposefully removes the Debug privilege from its
custom action servers (which are what call you).I think the MSI SDK lists
the priveleges removed somewhere...

On Tue, Feb 22, 2011 at 6:13 AM, Jeff Wisgo  wrote:

> Phil,
>
> I checked and you are correct, the msiexec.exe that is the parent process
> is
> running with limited privileges. But isn't the purpose of "deferred" mode
> to
> run with elevaged privileges? Or are you saying that it will only elevate
> as
> far as msiexec's privileges are?
>
> I ran msiexec.exe from a SYSTEM (full privileged) command prompt, and
> msiexec.exe still downgrades its privileges. Is this something being done
> by
> the OS or the binary itself? I'm hoping there is some way to force msiexec
> to run with full privileges.
>
> Thanks,
>
> Jeff
>
> On Mon, Feb 21, 2011 at 3:00 PM, Wilson, Phil  >wrote:
>
> > The system account is irrelevant here. What matters is the list of rights
> > that the msiexec process is running with, and it does not have all
> possible
> > rights enabled all of the time. I think you've already discovered that,
> so I
> > don't know what to advise. I forget where this is documented, but that
> code
> > (and therefore your custom action) is running with a limited list of
> rights
> > (something that started on MSI 4.0) that does not include the one
> required
> > to terminate processes.
> >
> > Phil Wilson
> >
> > -Original Message-
> > From: Jeff Wisgo [mailto:locksl...@gmail.com]
> > Sent: Sunday, February 20, 2011 3:32 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Running a custom action with elevated privileges
> >
> > Umesh,
> >
> > Thanks for responding to my question.
> >
> > I am using OpenProcess(PROCESS_TERMINATE, ...). When I execute the same
> > exact code from a system account with elevated privileges using PSEXEC,
> it
> > works, so I know there is something wrong with the privileges when my
> code
> > runs as a Custom Action. I also have verified this by looking at the
> > privileges with Process Explorer.
> >
> > Any other ideas?
> >
> > Thanks,
> >
> > Jeff
> >
> > On Sat, Feb 19, 2011 at 12:56 AM, Umeshj 
> > wrote:
> >
> > >
> > >
> > > What access level are you using for OpenProcess() ?
> > >
> > > A simple PROCESS_TERMINATE is sufficient. If you are using
> > > PROCESS_ALL_ACCESS it will fail.
> > > I had experienced the same problems and after changing the
> > dwDesiredAccess
> > > param it worked well.
> > >
> > > Umesh
> > > --
> > > View this message in context:
> > >
> >
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Running-a-custom-action-with-elevated-privileges-tp6041158p6042577.html
> > > Sent from the wix-users mailing list archive at Nabble.com.
> > >
> > >
> > >
> >
> --
> > > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
> XE:
> > > Pinpoint memory and threading errors before they happen.
> > > Find and fix more than 250 security defects in the development cycle.
> > > Locate bottlenecks in serial and parallel code that limit performance.
> > > http://p.sf.net/sfu/intel-dev2devfeb
> > > ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> >
> >
> --
> > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> > Pinpoint memory and threading errors before they happen.
> > Find and fix more than 250 security defects in the development cycle.
> > Locate bottlenecks in serial and parallel code that limit performance.
> > http://p.sf.net/sfu/intel-dev2devfeb
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> > *** Confidentiality Notice: This e-mail, including any associated or
> > attached files, is intended solely for the individual or entity to which
> it
> > is addressed. This e-mail is confidential and may well also be legally
> > privileged. If you have received it in error, you are on notice of its
> > status. Please notify the sender immediately by reply e-mail and then
> delete
> > this message from your system.

Re: [WiX-users] Disallowing uninstallation of patch

2011-02-22 Thread Tom Crozier

One more piece of information. When I run the second patch I get the following 
message for each component (1 per file) for each of the files that were added 
in the first patch and are still part of the second patch.

Patch Supersedence: Component 'CompPatchedContentDir' is added by a superseded 
patch and will become orphaned.

I looked at both the msi packages via Orca and the component exists in both the 
1st and 2nd patch msi's. Why does it say they will be orphaned?

I had tried this but when I run the second patch the UI sequence does not get 
run. Any ideas why this would happen?

-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Sent: Tuesday, February 22, 2011 11:58 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Disallowing uninstallation of patch

If you base the second patch on the RTM, itll need the new createfolder table
entries in case the first patch is never applied. You need to base the second
patch on the patched MSI (RTM + patch 1).


-Original Message-
From: Tom Crozier [mailto:tcroz...@rackwise.com] 
Sent: 22 February 2011 16:44
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Disallowing uninstallation of patch

Hi,

What I am trying to accomplish is to first install an unremovable Small
Update patch that adds new files into a new directory. (This works)
Next is to install a removable Minor Update patch that delivers new versions
of the files that were added in the first patch as well as modifications of
existing dlls etc... (This does not)
What I am getting is the following message in the msi log file:
Disallowing uninstallation of patch {D40C91BE-8619-426B-8B11-2AEA5106A767}
because it adds new entries to table CreateFolder
Even though these files were added in the first patch as well.

The first patch is set with AllowRemoval='no' and Supersede="no" and is built
against the RTM version.

The second patch is set with AllowRemoval='yes' and Supersede=" yes" and is
also built against the RTM version.

I had tried creating a small test installer and this same sequence seems to
work.

Thanks - Tom

-
-
Index, Search & Analyze Logs and other IT data in Real-Time with Splunk 
Collect, index and harness all the fast moving IT data generated by your 
applications, servers and devices whether physical, virtual or in the cloud.
Deliver compliance at lower cost and gain new business insights. 
Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.


--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] State of WiX 3.6 - Burn?

2011-02-22 Thread Christopher Painter

I haven't really been following the status of the weekly builds so I was hoping 
someone could give me an honest assessment of the current state of Burn.

If I had an MSI that needed to bootstrap Windows Installer 4.5 and .NET 
Framework 3.5sp1 then run 1 single MSI,  is v3.6 currently stable enough to do 
this?

Is Burn capable of using the MSI's native UI after running the prereqs or must 
Burn provide the UI?

My thanks in advance as I may not be able to respond to this email in the near 
future but I will read follow ups.

---
Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me


  

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Disallowing uninstallation of patch

2011-02-22 Thread Tom Crozier

I had tried this but when I run the second patch the UI sequence does not get 
run. Any ideas why this would happen?

-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Sent: Tuesday, February 22, 2011 11:58 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Disallowing uninstallation of patch

If you base the second patch on the RTM, itll need the new createfolder table
entries in case the first patch is never applied. You need to base the second
patch on the patched MSI (RTM + patch 1).

-Original Message-
From: Tom Crozier [mailto:tcroz...@rackwise.com] 
Sent: 22 February 2011 16:44
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Disallowing uninstallation of patch

Hi,

What I am trying to accomplish is to first install an unremovable Small
Update patch that adds new files into a new directory. (This works)
Next is to install a removable Minor Update patch that delivers new versions
of the files that were added in the first patch as well as modifications of
existing dlls etc... (This does not)
What I am getting is the following message in the msi log file:
Disallowing uninstallation of patch {D40C91BE-8619-426B-8B11-2AEA5106A767}
because it adds new entries to table CreateFolder
Even though these files were added in the first patch as well.

The first patch is set with AllowRemoval='no' and Supersede="no" and is built
against the RTM version.

The second patch is set with AllowRemoval='yes' and Supersede=" yes" and is
also built against the RTM version.

I had tried creating a small test installer and this same sequence seems to
work.

Thanks - Tom

-
-
Index, Search & Analyze Logs and other IT data in Real-Time with Splunk 
Collect, index and harness all the fast moving IT data generated by your 
applications, servers and devices whether physical, virtual or in the cloud.
Deliver compliance at lower cost and gain new business insights. 
Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Disallowing uninstallation of patch

2011-02-22 Thread Peter Shirtcliffe

If you base the second patch on the RTM, itll need the new createfolder table
entries in case the first patch is never applied. You need to base the second
patch on the patched MSI (RTM + patch 1).

-Original Message-
From: Tom Crozier [mailto:tcroz...@rackwise.com] 
Sent: 22 February 2011 16:44
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Disallowing uninstallation of patch

Hi,

What I am trying to accomplish is to first install an unremovable Small
Update patch that adds new files into a new directory. (This works)
Next is to install a removable Minor Update patch that delivers new versions
of the files that were added in the first patch as well as modifications of
existing dlls etc... (This does not)
What I am getting is the following message in the msi log file:
Disallowing uninstallation of patch {D40C91BE-8619-426B-8B11-2AEA5106A767}
because it adds new entries to table CreateFolder
Even though these files were added in the first patch as well.

The first patch is set with AllowRemoval='no' and Supersede="no" and is built
against the RTM version.

The second patch is set with AllowRemoval='yes' and Supersede=" yes" and is
also built against the RTM version.

I had tried creating a small test installer and this same sequence seems to
work.

Thanks - Tom

-
-
Index, Search & Analyze Logs and other IT data in Real-Time with Splunk 
Collect, index and harness all the fast moving IT data generated by your 
applications, servers and devices whether physical, virtual or in the cloud.
Deliver compliance at lower cost and gain new business insights. 
Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Disallowing uninstallation of patch

2011-02-22 Thread Tom Crozier

Hi,

What I am trying to accomplish is to first install an unremovable Small Update 
patch that adds new files into a new directory. (This works)
Next is to install a removable Minor Update patch that delivers new versions of 
the files that were added in the first patch as well as modifications of 
existing dlls etc... (This does not)
What I am getting is the following message in the msi log file:
Disallowing uninstallation of patch {D40C91BE-8619-426B-8B11-2AEA5106A767} 
because it adds new entries to table CreateFolder
Even though these files were added in the first patch as well.

The first patch is set with AllowRemoval='no' and Supersede="no" and is built 
against the RTM version.

The second patch is set with AllowRemoval='yes' and Supersede=" yes" and is 
also built against the RTM version.

I had tried creating a small test installer and this same sequence seems to 
work.

Thanks - Tom

--
Index, Search & Analyze Logs and other IT data in Real-Time with Splunk 
Collect, index and harness all the fast moving IT data generated by your 
applications, servers and devices whether physical, virtual or in the cloud.
Deliver compliance at lower cost and gain new business insights. 
Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Why is WiX UI executed after CostFinalize?

2011-02-22 Thread John Mersh


So I assume that the AddLocal and Remove events wouldn't function if I ran
the UI earlier? That certainly isn't documented anywhere that I can find. It
is certainly the case that ADDLOCAL and REMOVE can be set before
CostFinalize for example on the command line so I am surprised. The nearest
to a reference I can find is
http://msdn.microsoft.com/en-us/library/aa367842(v=vs.85).aspx - is that
what you are referring to?

The whole thing of having two almost independent and mutually exclusive ways
of specifying if components and features should be installed really confused
me when I first came to WiX and I still have to experiment to find out how
things work in real world cases. I am reduced in most cases to programming
by trial and error and hoping I don't end up relying on a bug or accidental
feature which will disappear in a later version which is unpleasant.

I haven't found any documentation which says that you can re-run the
standard actions and it is an approach I would never have thought of. I
would expect the effect of re-running them would be un-defined behaviour
messing up your whole installation at worst and a crash at best. I'd
certainly expect lots of custom actions scheduled after CostFinalize to get
rather confused - would they get run twice?
-- 
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Why-is-WiX-UI-executed-after-CostFinalize-tp6047911p6053067.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Index, Search & Analyze Logs and other IT data in Real-Time with Splunk 
Collect, index and harness all the fast moving IT data generated by your 
applications, servers and devices whether physical, virtual or in the cloud.
Deliver compliance at lower cost and gain new business insights. 
Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Running a custom action with elevated privileges

2011-02-22 Thread Rob Mensching

IIRC, Windows Installer purposefully removes the Debug privilege from its
custom action servers (which are what call you).I think the MSI SDK lists
the priveleges removed somewhere...

On Tue, Feb 22, 2011 at 6:13 AM, Jeff Wisgo  wrote:

> Phil,
>
> I checked and you are correct, the msiexec.exe that is the parent process
> is
> running with limited privileges. But isn't the purpose of "deferred" mode
> to
> run with elevaged privileges? Or are you saying that it will only elevate
> as
> far as msiexec's privileges are?
>
> I ran msiexec.exe from a SYSTEM (full privileged) command prompt, and
> msiexec.exe still downgrades its privileges. Is this something being done
> by
> the OS or the binary itself? I'm hoping there is some way to force msiexec
> to run with full privileges.
>
> Thanks,
>
> Jeff
>
> On Mon, Feb 21, 2011 at 3:00 PM, Wilson, Phil  >wrote:
>
> > The system account is irrelevant here. What matters is the list of rights
> > that the msiexec process is running with, and it does not have all
> possible
> > rights enabled all of the time. I think you've already discovered that,
> so I
> > don't know what to advise. I forget where this is documented, but that
> code
> > (and therefore your custom action) is running with a limited list of
> rights
> > (something that started on MSI 4.0) that does not include the one
> required
> > to terminate processes.
> >
> > Phil Wilson
> >
> > -Original Message-
> > From: Jeff Wisgo [mailto:locksl...@gmail.com]
> > Sent: Sunday, February 20, 2011 3:32 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Running a custom action with elevated privileges
> >
> > Umesh,
> >
> > Thanks for responding to my question.
> >
> > I am using OpenProcess(PROCESS_TERMINATE, ...). When I execute the same
> > exact code from a system account with elevated privileges using PSEXEC,
> it
> > works, so I know there is something wrong with the privileges when my
> code
> > runs as a Custom Action. I also have verified this by looking at the
> > privileges with Process Explorer.
> >
> > Any other ideas?
> >
> > Thanks,
> >
> > Jeff
> >
> > On Sat, Feb 19, 2011 at 12:56 AM, Umeshj 
> > wrote:
> >
> > >
> > >
> > > What access level are you using for OpenProcess() ?
> > >
> > > A simple PROCESS_TERMINATE is sufficient. If you are using
> > > PROCESS_ALL_ACCESS it will fail.
> > > I had experienced the same problems and after changing the
> > dwDesiredAccess
> > > param it worked well.
> > >
> > > Umesh
> > > --
> > > View this message in context:
> > >
> >
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Running-a-custom-action-with-elevated-privileges-tp6041158p6042577.html
> > > Sent from the wix-users mailing list archive at Nabble.com.
> > >
> > >
> > >
> >
> --
> > > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
> XE:
> > > Pinpoint memory and threading errors before they happen.
> > > Find and fix more than 250 security defects in the development cycle.
> > > Locate bottlenecks in serial and parallel code that limit performance.
> > > http://p.sf.net/sfu/intel-dev2devfeb
> > > ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> >
> >
> --
> > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> > Pinpoint memory and threading errors before they happen.
> > Find and fix more than 250 security defects in the development cycle.
> > Locate bottlenecks in serial and parallel code that limit performance.
> > http://p.sf.net/sfu/intel-dev2devfeb
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> > *** Confidentiality Notice: This e-mail, including any associated or
> > attached files, is intended solely for the individual or entity to which
> it
> > is addressed. This e-mail is confidential and may well also be legally
> > privileged. If you have received it in error, you are on notice of its
> > status. Please notify the sender immediately by reply e-mail and then
> delete
> > this message from your system. Please do not copy it or use it for any
> > purposes, or disclose its contents to any other person. This email comes
> > from a division of the Invensys Group, owned by Invensys plc, which is a
> > company registered in England and Wales with its registered office at 3rd
> > Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023).
> For
> > a list of European legal entities within the Invensys Group, please go to
> >
> http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_id=77
> > .
> >
> > You may contact Invensys plc on +44 (0

Re: [WiX-users] Problem with RemoveExistingProducts action

2011-02-22 Thread James Johnston

In that case you have to be following component rules.  See
http://www.joyofsetup.com/2008/12/30/paying-for-upgrades/  Also with your
placement, if the old version fails to uninstall then the user will have
both old & new versions installed - something to keep in mind.

Try putting it after InstallInitialize.  The old version will be uninstalled
first before anything new is installed.  If the install of the new product
fails then the rollback will restore the old version.

If you use DIFxApp for driver installs then it needs to be put between
InstallValidate and InstallInitialize due to a bug in DIFxApp.  In that case
a failed install of the new product but after the successful uninstall of
the old product will leave the computer with no product installed at all.  I
think that must be a good place to put it if there are buggy custom actions
and component rules aren't being well-followed.

James

-Original Message-
From: Igor Lemsky [mailto:igor.lem...@gmail.com] 
Sent: Tuesday, February 22, 2011 06:04
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Problem with RemoveExistingProducts action

I have upgrade scenario for my system from 2.0 version to 2.1 version. I
have file for example aaa.xml in 2.1 version and no such file in 2.0
version. It lies in independent component i feature Afeature (it was in 2.0
also). During install there are no problems: file installs to the right
location. But during upgrade from 2.0 version it copies and then deleted.
It seems that RemoveExistingProducts deletes it during uninstall of older
2.0 product. It planned after InstallFinalize action (the most right place
as I understand).
Due to the log Installer unpublish features and the delete files...
MSI (s) (DC:B8) [11:54:05:148]: Executing op:
FileRemove(,FileName=aaa.xml,,ComponentId={369A88EA-F2DD-4124-9560-13E5694E2
EEB})
RemoveFiles: File: aaa.xml, folder: C:\Mag\

I dont understand - what happened? Why it deletes files? May be I didnt
configured installer correctly? But how?

--
Index, Search & Analyze Logs and other IT data in Real-Time with Splunk
Collect, index and harness all the fast moving IT data generated by your
applications, servers and devices whether physical, virtual or in the cloud.
Deliver compliance at lower cost and gain new business insights. 
Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Index, Search & Analyze Logs and other IT data in Real-Time with Splunk 
Collect, index and harness all the fast moving IT data generated by your 
applications, servers and devices whether physical, virtual or in the cloud.
Deliver compliance at lower cost and gain new business insights. 
Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Running a custom action with elevated privileges

2011-02-22 Thread Jeff Wisgo

Phil,

I checked and you are correct, the msiexec.exe that is the parent process is
running with limited privileges. But isn't the purpose of "deferred" mode to
run with elevaged privileges? Or are you saying that it will only elevate as
far as msiexec's privileges are?

I ran msiexec.exe from a SYSTEM (full privileged) command prompt, and
msiexec.exe still downgrades its privileges. Is this something being done by
the OS or the binary itself? I'm hoping there is some way to force msiexec
to run with full privileges.

Thanks,

Jeff

On Mon, Feb 21, 2011 at 3:00 PM, Wilson, Phil wrote:

> The system account is irrelevant here. What matters is the list of rights
> that the msiexec process is running with, and it does not have all possible
> rights enabled all of the time. I think you've already discovered that, so I
> don't know what to advise. I forget where this is documented, but that code
> (and therefore your custom action) is running with a limited list of rights
> (something that started on MSI 4.0) that does not include the one required
> to terminate processes.
>
> Phil Wilson
>
> -Original Message-
> From: Jeff Wisgo [mailto:locksl...@gmail.com]
> Sent: Sunday, February 20, 2011 3:32 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Running a custom action with elevated privileges
>
> Umesh,
>
> Thanks for responding to my question.
>
> I am using OpenProcess(PROCESS_TERMINATE, ...). When I execute the same
> exact code from a system account with elevated privileges using PSEXEC, it
> works, so I know there is something wrong with the privileges when my code
> runs as a Custom Action. I also have verified this by looking at the
> privileges with Process Explorer.
>
> Any other ideas?
>
> Thanks,
>
> Jeff
>
> On Sat, Feb 19, 2011 at 12:56 AM, Umeshj 
> wrote:
>
> >
> >
> > What access level are you using for OpenProcess() ?
> >
> > A simple PROCESS_TERMINATE is sufficient. If you are using
> > PROCESS_ALL_ACCESS it will fail.
> > I had experienced the same problems and after changing the
> dwDesiredAccess
> > param it worked well.
> >
> > Umesh
> > --
> > View this message in context:
> >
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Running-a-custom-action-with-elevated-privileges-tp6041158p6042577.html
> > Sent from the wix-users mailing list archive at Nabble.com.
> >
> >
> >
> --
> > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> > Pinpoint memory and threading errors before they happen.
> > Find and fix more than 250 security defects in the development cycle.
> > Locate bottlenecks in serial and parallel code that limit performance.
> > http://p.sf.net/sfu/intel-dev2devfeb
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
>
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> *** Confidentiality Notice: This e-mail, including any associated or
> attached files, is intended solely for the individual or entity to which it
> is addressed. This e-mail is confidential and may well also be legally
> privileged. If you have received it in error, you are on notice of its
> status. Please notify the sender immediately by reply e-mail and then delete
> this message from your system. Please do not copy it or use it for any
> purposes, or disclose its contents to any other person. This email comes
> from a division of the Invensys Group, owned by Invensys plc, which is a
> company registered in England and Wales with its registered office at 3rd
> Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023). For
> a list of European legal entities within the Invensys Group, please go to
> http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_id=77
> .
>
> You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail
> recept...@invensys.com. This e-mail and any attachments thereto may be
> subject to the terms of any agreements between Invensys (and/or its
> subsidiaries and affiliates) and the recipient (and/or its subsidiaries and
> affiliates).
>
>
>
>
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and

Re: [WiX-users] write to IniFile

2011-02-22 Thread Rob Mensching

Ahh, my mistake. It's the IniSearch that is rooted only in SystemFolder. I'm
glad you pushed through and corrected me.

On Mon, Feb 21, 2011 at 7:26 AM, Michael Tissington <
michael_tissing...@ciqual.com> wrote:

> Actually I have got it to work just great. It was a spelling mistake on my
> part.
>
>
>  
>
>  
>  
>   Name="myfile.ini" Section="ConnectionObserver" Key="ServerAddress"
> Value="[SERVERADDRESS]" Action="addLine"/>
>   Name="ciquald.ini" Section="PopupQuestion" Key="GroupID" Value="[GROUPID]"
> Action="addLine"/>
>  
>
>
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: 21 February 2011 15:03
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] write to IniFile
>
> Yep, annoying, eh? The MSI SDK documents that behavior. Want to contribute
> a
> custom action that does better?
>
> On Mon, Feb 21, 2011 at 1:04 AM, Michael Tissington <
> michael_tissing...@ciqual.com> wrote:
>
> > I'm trying to write to an iniFile.
> >
> > How do I tell it which folder the file is in?
> > Currently it seems to insist that it is in the \Windows folder.
> >
> >
> >
> > --
> >  The ultimate all-in-one performance toolkit: Intel(R)
> > Parallel Studio XE:
> > Pinpoint memory and threading errors before they happen.
> > Find and fix more than 250 security defects in the development cycle.
> > Locate bottlenecks in serial and parallel code that limit performance.
> > http://p.sf.net/sfu/intel-dev2devfeb
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
>
>
> --
> virtually, Rob Mensching - http://RobMensching.com LLC
>
> 
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>


-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
Index, Search & Analyze Logs and other IT data in Real-Time with Splunk 
Collect, index and harness all the fast moving IT data generated by your 
applications, servers and devices whether physical, virtual or in the cloud.
Deliver compliance at lower cost and gain new business insights. 
Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Multiple-Package Installations ???

2011-02-22 Thread Lambert Pandian

Hi,

I am trying to write an exe to install multiple pancakes as described in
MSDN.  The
problem is I get “Invalid- Handle” as soon as the MsiJoinTransaction
function encounters.

I have given my code below.


static void Main(string[] args)
{
try
  {
IntPtr ptr = new IntPtr (0) ;
ptr = System.Runtime.InteropServices.Marshal.StringToCoTaskMemAuto(args[0]);
Transaction transaction = Transaction.FromHandle(ptr, true);
transaction.Join(TransactionAttributes.NoneInstaller.InstallProduct(@"C:\ITE_20110211\ChainExe\ChainExe\bin\Debug\fbda599.msi",
"");
transaction.Commit();
transaction.Close();

}
}

Could you please help?

Regards,
Lambert
--
Index, Search & Analyze Logs and other IT data in Real-Time with Splunk 
Collect, index and harness all the fast moving IT data generated by your 
applications, servers and devices whether physical, virtual or in the cloud.
Deliver compliance at lower cost and gain new business insights. 
Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Major Upgrade - MSI or Wix?

2011-02-22 Thread Michael Tissington

I'm wondering if or how this is possible.

The client already has an msi package installed, which need admin rights to
install

I'm wanting to push a Major upgrade to the client.

However I'd like the client to do a silent install with elevated privilages.

Is this possible?


--
Index, Search & Analyze Logs and other IT data in Real-Time with Splunk 
Collect, index and harness all the fast moving IT data generated by your 
applications, servers and devices whether physical, virtual or in the cloud.
Deliver compliance at lower cost and gain new business insights. 
Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] running uninstallation as administrator

Re: [WiX-users] Disallowing uninstallation of patch

Re: [WiX-users] Trigger custom action on NEWERFOUND

Re: [WiX-users] How to change the Windows Integrity level in Vista/Win7 when launching the application

Re: [WiX-users] Running a custom action with elevated privileges

[WiX-users] Trigger custom action on NEWERFOUND

Re: [WiX-users] State of WiX 3.6 - Burn?

Re: [WiX-users] Running a custom action with elevated privileges

Re: [WiX-users] Disallowing uninstallation of patch

[WiX-users] State of WiX 3.6 - Burn?

Re: [WiX-users] Disallowing uninstallation of patch

Re: [WiX-users] Disallowing uninstallation of patch

[WiX-users] Disallowing uninstallation of patch

Re: [WiX-users] Why is WiX UI executed after CostFinalize?

Re: [WiX-users] Running a custom action with elevated privileges

Re: [WiX-users] Problem with RemoveExistingProducts action

Re: [WiX-users] Running a custom action with elevated privileges

Re: [WiX-users] write to IniFile

[WiX-users] Multiple-Package Installations ???

[WiX-users] Major Upgrade - MSI or Wix?

20 matches

Site Navigation

Mail list logo

Footer information