Re: [WiX-users] WixUtilExtension not updating Sources value when registering a new EventLog source?

[Joergen Bech]

 

Update/To answer my own question:

 

I decompiled the .NET framework function
System.Diagnostic.EventLog.CreateEventSource and looked at the source code
for the WiX extension and confirmed that there was a discrepancy.

 

I then created a test project with .NET framework debugging turned on, so I
could step into the framework and read Microsoft's own source comments (if
any).

 

Found this:

 

---snip---

// NOTE: We shouldn't set "Sources" explicitly, the OS will
automatically set it.

// The EventLog service doesn't use it for anything it is just an
helping hand for event viewer filters.

// Writing this value explicitly might confuse the service as it might
perceive it as a change and 

// start initializing again

---snip---

 

and in another branch:

 

---snip---

  // We have a race with OS EventLog here.

  // OS might update Sources as well. We should avoid writing the 

  // source name if OS beats us.

---snip---

 

Funny how the notes say that something should not be done, yet in the next
line of code, they go ahead and do it anyway.

 

So I guess the WiX way is fine and I should not care about the Sources value
not being updated explicitly by WiXUtilExtension.

 

/Joergen Bech

 

 

 

  _  

From: Joergen Bech [mailto:joergenb...@hotmail.com] 
Sent: 11. februar 2010 12:31
To: 'wix-users@lists.sourceforge.net'
Subject: WixUtilExtension not updating Sources value when registering a new
EventLog source?

 

I am using the WixUtilExtension to register two EventLog sources:

 



  

  



 

The Registry keys are correctly created, i.e.

 

HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\Application\MyApp1

HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\Application\MyApp2

 

However: If I were to create these sources using the .NET Framework class
System.Diagnostics.EventLogInstaller, it would also update the REG_MULTI_SZ
value named "Sources", which (provided we are using the Application log) can
be found at

 

hklm\system\currentcontrolset\services\eventlog\applicat...@sources

 

This value contains a list of event log sources and is pretty much
consistent with the list of subkeys, although some broken installers
sometimes fail to update the value at uninstall time or whatever.

 

If we look in the latest WiX source in
src\ext\UtilExtension\wixext\UtilCompiler.cs:ParseEventSourceElement, we
find

 

string eventSourceKey =
String.Format(@"SYSTEM\CurrentControlSet\Services\EventLog\{0}\{1}",
logName, sourceName);

 

which is where the key is registered, but I see no code updating the Sources
value.

 

My questions are:

 

-  Why is WiX not updating the Sources value?

-  Is this something I should be concerned about?

 

Links to official guidelines about how event logs should be registered (at
the Registry level) would be much appreciated.

 

/Joergen Bech

 

 

 

--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Installer hanging while doing FileCost, not frequently though.

[Neil Sleightholm]

I have raised a bug for this and attached logs and source:
https://sourceforge.net/tracker/?func=detail&aid=2951181&group_id=105970
&atid=642714

Neil

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com] 
Sent: 10 February 2010 22:07
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Installer hanging while doing FileCost, not
frequently though.

I think I have finally caught this and got a log. I ran a very simple
install that uses WixUI_Advanced, I created a batch file to install and
uninstall this again and again. After about 20 iterations the install
hung displaying the dialog "Please wait while the installer finishes
determining your disk space requirements". You can click on the "Return"
button and it goes back to the license dialog. If you click "Install" it
displays the "Please wait..." dialog again and the only option is to
cancel the install.

 

Looking at the log (shown below) I am not sure the subject title of this
email reflects what is actually happening but it does match the link the
was originally in this question
(http://n2.nabble.com/Installer-hanging-while-doing-FileCost-not-frequen
tly-though-td2116872.html#a4519081) and is something I have seen quite a
lot.

 

I have this in a snapshot of a VM if anyone can think of any questions
to ask to help diagnose this.

 

Regards

 

Neil

 

Neil Sleightholm
X2 Systems Limited
n...@x2systems.com  

 

 

 

=== Verbose logging started: 10/02/2010  21:49:45  Build type: SHIP
UNICODE 4.05.6001.00  Calling process: C:\WINDOWS\system32\msiexec.exe
===

MSI (c) (F8:D0) [21:49:45:343]: Resetting cached policy values

MSI (c) (F8:D0) [21:49:45:343]: Machine policy value 'Debug' is 0

MSI (c) (F8:D0) [21:49:45:343]: *** RunEngine:

   *** Product: Setup.msi

   *** Action: 

   *** CommandLine: **

MSI (c) (F8:D0) [21:49:45:343]: Machine policy value
'DisableUserInstalls' is 0

MSI (c) (F8:D0) [21:49:45:343]: SOFTWARE RESTRICTION POLICY: Verifying
package --> 'C:\Documents and Settings\Administrator\Desktop\Setup.msi'
against software restriction policy

MSI (c) (F8:D0) [21:49:45:343]: Note: 1: 2262 2: DigitalSignature 3:
-2147287038 

MSI (c) (F8:D0) [21:49:45:343]: SOFTWARE RESTRICTION POLICY:
C:\Documents and Settings\Administrator\Desktop\Setup.msi is not
digitally signed

MSI (c) (F8:D0) [21:49:45:343]: SOFTWARE RESTRICTION POLICY:
C:\Documents and Settings\Administrator\Desktop\Setup.msi is permitted
to run at the 'unrestricted' authorization level.

MSI (c) (F8:D0) [21:49:45:358]: Cloaking enabled.

MSI (c) (F8:D0) [21:49:45:358]: Attempting to enable all disabled
privileges before calling Install on Server

MSI (c) (F8:D0) [21:49:45:358]: End dialog not enabled

MSI (c) (F8:D0) [21:49:45:358]: Original package ==> C:\Documents and
Settings\Administrator\Desktop\Setup.msi

MSI (c) (F8:D0) [21:49:45:358]: Package we're running from ==>
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\20ce31.msi

MSI (c) (F8:D0) [21:49:45:358]: APPCOMPAT: looking for appcompat
database entry with ProductCode
'{6DB85887-FFBD-41C7-9E86-B3844572E6CB}'.

MSI (c) (F8:D0) [21:49:45:358]: APPCOMPAT: no matching ProductCode found
in database.

MSI (c) (F8:D0) [21:49:45:358]: MSCOREE not loaded loading copy from
system32

MSI (c) (F8:D0) [21:49:45:374]: Machine policy value 'TransformsSecure'
is 0

MSI (c) (F8:D0) [21:49:45:374]: User policy value 'TransformsAtSource'
is 0

MSI (c) (F8:D0) [21:49:45:374]: Note: 1: 2205 2:  3: MsiFileHash 

MSI (c) (F8:D0) [21:49:45:374]: Machine policy value 'DisablePatch' is 0

MSI (c) (F8:D0) [21:49:45:374]: Machine policy value
'AllowLockdownPatch' is 0

MSI (c) (F8:D0) [21:49:45:374]: Machine policy value
'DisableLUAPatching' is 0

MSI (c) (F8:D0) [21:49:45:374]: Machine policy value
'DisableFlyWeightPatching' is 0

MSI (c) (F8:D0) [21:49:45:374]: APPCOMPAT: looking for appcompat
database entry with ProductCode
'{6DB85887-FFBD-41C7-9E86-B3844572E6CB}'.

MSI (c) (F8:D0) [21:49:45:374]: APPCOMPAT: no matching ProductCode found
in database.

MSI (c) (F8:D0) [21:49:45:374]: Transforms are not secure.

MSI (c) (F8:D0) [21:49:45:374]: PROPERTY CHANGE: Adding
MsiLogFileLocation property. Its value is 'C:\Documents and
Settings\Administrator\Desktop\Setup.log'.

MSI (c) (F8:D0) [21:49:45:374]: Command Line:
CURRENTDIRECTORY=C:\Documents and Settings\Administrator\Desktop
CLIENTUILEVEL=0 CLIENTPROCESSID=3320 

MSI (c) (F8:D0) [21:49:45:374]: PROPERTY CHANGE: Adding PackageCode
property. Its value is '{FA568AEC-31C1-482A-BC9E-38333FCAC44A}'.

MSI (c) (F8:D0) [21:49:45:374]: Product Code passed to
Engine.Initialize:   ''

MSI (c) (F8:D0) [21:49:45:374]: Product Code from property table before
transforms: '{6DB85887-FFBD-41C7-9E86-B3844572E6CB}'

MSI (c) (F8:D0) [21:49:45:374]: Product Code from property table after
transforms:  '{6DB85887-FFBD-41C7-9E86-B3844572E6CB}'

MSI (c) (F8:D0) [21:49:45:374]: Product not regist

Re: [WiX-users] Selectively uninstalling components during major upgrade

[Sebastiaan Deckers]

Hi Blair,

Thanks again for your advice. Sadly the late scheduling causes too
many other problems like updated files being removed. So I'll just
give up on the idea of cleaning up the registry. Not too important.

I really wish Windows Installer provided some kind of procedural
mechanism. I can appreciate the core concept of declarative
installation. But there are so many edge cases which could easily be
handled by small scripted sequences. The declarative syntax is
incredibly frustrating and unintuitive to handle the long tail of
installation quirks. Even NSIS's assembler madness makes it possible
to handle just about any edge case. Just my 0.02.

Sebastiaan


On Sat, Feb 13, 2010 at 2:11 AM, Blair  wrote:
> I looked it up really fast: RemoveRegistryKey/removeOnUninstall creates an
> entry in the Registry table with the Name column being set to "-", which
> causes the key to be removed when the component is removed without creating
> the key when the component is installed.
>
> The condition isn't part of the Registry table, it is a part of the
> Component table, and component conditions are not used when the feature
> containing the component is removed.
>
> Uninstallation of a component during upgrade is controlled the combination
> of two factors: the presence of the same Component-GUID in the upgrading
> package, and the sequence of the RemoveExistingProducts. If
> RemoveExistingProducts is sequenced early, the component will be removed
> every upgrade. If the same GUID isn't in the new package, the component will
> be removed every upgrade. You have to place RemoveExistingProducts "late"
> (either right before or after InstallFinalize).
>
> Note that using the "late" placement of RemoveExistingProducts requires a
> more strict observance of the component rules.
>
> -Original Message-
> From: Sebastiaan Deckers [mailto:c...@pandion.im]
> Sent: Friday, February 12, 2010 2:11 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Selectively uninstalling components during major
> upgrade
>
> Thanks for the tip. Unfortunately the registry keys still seem to get
> deleted during the upgrade. I'm using a
> RemoveRegistryKey/removeOnUninstall with the "NOT
> UPGRADINGPRODUCTCODE" Condition. My guess is that the Condition gets
> evaluated at installation time instead of during the upgrade. Is that
> how it works? Then how can I delete these registry keys only during a
> manual uninstall, while leaving them intact during an upgrade?
>
> Thanks again,
>
> Sebastiaan
>
>
> On Fri, Feb 12, 2010 at 3:55 AM, Blair  wrote:
>> The registry removal is probably occurring in the package being removed.
> The
>> upgrading package's properties are not all passed to the packages being
>> removed.
>>
>> The package being removed is given a property "UPGRADINGPRODUCTCODE" which
>> is the product code of the upgrading package. If you add "AND NOT
>> UPGRADINGPRODUCTCODE" to your "REMOVE"-related condition you should
> achieve
>> what you are trying to do (not that it won't help with packages already
>> released, you will just have to recreate those entries when upgrading
>> already released packages).
>>
>> http://msdn.microsoft.com/library/aa372380.aspx
>>
>> -Original Message-
>> From: Sebastiaan Deckers [mailto:c...@pandion.im]
>> Sent: Thursday, February 11, 2010 8:59 AM
>> To: General discussion for Windows Installer XML toolset.
>> Subject: [WiX-users] Selectively uninstalling components during major
>> upgrade
>>
>> Hi all,
>>
>> Is there a way to prevent removal of specific components when removal
>> is part of a major upgrade, as opposed to just an uninstallation?
>>
>> My app creates certain registry entries at runtime (not the installer
>> but the actual software). I would like to keep these during an upgrade
>> while still cleaning them up during installation.
>>
>> I created a Component with RemoveRegistryKey tags and gave it a
>> Condition that checks for a variable "AUTOUPDATE" which gets passed
>> via command line in case of a major upgrade. This doesn't seem to work
>> as the registry keys are always removed, regardless of the AUTOUPDATE
>> variable.
>>
>> Source code:
>>
> http://github.com/pandion/pandion/blob/master/Installer/WiX/product.wxs#L259
>>
>> Any suggestions?
>>
>> Sebastiaan
>>
>>
> 
>> --
>> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
>> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
>> http://p.sf.net/sfu/solaris-dev2dev
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>>
>>
> 
> --
>> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
>> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NO

Re: [WiX-users] DTF ExternalUI free of System.Windows.Forms

[Bob Arnson]

On 2/9/2010 2:47 PM, Tony Juricic wrote:
> Since my external UI is WPF I am really bothered, both by having to 
> disambiguate several classes and by having to reference forms Dll just for a 
> few enums, when calling Installer.SetExternalUI. Hopefully these enums will 
> become UI-system-agnostic in the future.
>

It won't happen by magic. Please file a feature request.

-- 
sig://boB
http://joyofsetup.com/


--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WinSxS - best prcatices?

[Bob Arnson]

On 2/9/2010 12:04 PM, Jakub Gwóźdź wrote:
> But the more I think of them (and read on the web) the more scared I am.
> Since the only dlls installed in WinSxS comes from Microsoft (on a few
> computers I've checked so far) I'm starting to wonder why it isn't a
> popular solution.
>

Note that even Microsoft is moving away from WinSxS: The VC2010 runtime 
DLLs are no longer installed to WinSxS.

-- 
sig://boB
http://joyofsetup.com/


--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Change the error dialog upon a known error code?

[Bob Arnson]

On 2/10/2010 11:50 AM, Tabmow wrote:
>  Is it possible to change the error dialogs for some of the known types?
> Ie.  If i know a certain Windows installer error code, can i override the
> default error dialog with my own dialog from my wix code?
>

No but you can use control conditions to show different messages based 
on conditions.

> Basically i am now using "Platforms=x64" in wix so we only want our MSI to
> run on 64-bit platforms, which it now does.  But when you run the msi on a
> 32-bit platform, the msg that pops up is "This installation package is not
> supported by this processor type.  Contact your product vendor" (i think
> error code 1633).So how do i create my own dialog that will get spawned
> when error code 1633 is hit instead of the default?  Is this possible?
>

No. In that case, MSI won't even open your package; the error is shown 
before anything in your package could change it.

-- 
sig://boB
http://joyofsetup.com/


--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WixUtilExtension not updating Sources value when registering a new EventLog source?

[Bob Arnson]

On 2/13/2010 4:02 AM, Joergen Bech wrote:
> So I guess the WiX way is fine and I should not care about the Sources value
> not being updated explicitly by WiXUtilExtension.
>

Right. When I wrote EventSource, I went by the Windows documentation.

-- 
sig://boB
http://joyofsetup.com/


--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiXNetFxExtension conditions

[Bob Arnson]

On 2/12/2010 6:19 AM, John Aldridge wrote:
> If I use WiXNetFxExtension to test for NETFRAMEWORK35, does this mean
> "3.5 itself is installed" or "3.5 or any later version is installed"?
>

The former but it's not practical to make generalizations for future CLR 
versions since they can be side-by-side or upgrades or Russian-doll 
models (like 2.0+3.0+3.5).

-- 
sig://boB
http://joyofsetup.com/


--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Change the error dialog upon a known error code?

[Tabmow]

Okay, thanks very much Bob.
-- 
View this message in context: 
http://n2.nabble.com/Change-the-error-dialog-upon-a-known-error-code-tp4549153p4567236.html
Sent from the wix-users mailing list archive at Nabble.com.

--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Admin check in Win 2008?

[Tabmow]

saschabeaumont wrote:
> 
> As you shouldn't be modifying the system outside of the
> InstallExecuteSequence anyway I can't see how this would be a problem?
> 
> 

It's not a problem, so much as we prompt a few screens of required info
before the "Install" button is hit.   Why have a user fill in these few
screens only to find out they have wrong permissions?  In the past, we could
prevent this from happening by the code i quoted.  So all i was trying was
to do the same behaviour in Windows 2008 R2 if possible.


saschabeaumont wrote:
> 
> Here's the code I'm using below, as the condition all looks OK I've
> included the Package element - I don't know if the settings there
> would have any effect on the behaviour?
> 
> Comments="!(loc.Package_Comments)"
>  Manufacturer="!(loc.ManufacturerName)"
>  InstallerVersion="301"
>  Compressed="yes"
>  InstallPrivileges="elevated"
>  InstallScope="perMachine"
>  Platform="$(var.ProcessorArchitecture)" />
> 
>   
>   
>   
> 


I tried the exact "InstallPrivileges" and "Condition Message" line (with my
own msg of course), and now non-admin users cannot run the MSI and get my
warning message, which is great.   Running the MSI as Administrator works
fine.   But if i run the MSI as a user who is part of "Administrators"
group, shouldn't that user still be allowed to run the MSI?   That user
still gets denied like a regular user.   Again, this is Windows 2008 R2 if
that makes a difference.   Or am I missing something? 

Thanks!
-- 
View this message in context: 
http://n2.nabble.com/Admin-check-in-Win-2008-tp4557002p4567385.html
Sent from the wix-users mailing list archive at Nabble.com.

--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Admin check in Win 2008?

[Tabmow]

Igor Paniushkin wrote:
> 
> Does it fail on installation?
> And as Sascha said that after pressing of the install button user will be
> prompted to enter a username and password, but you should be sure that you
> specified Impersonate="no" property on deferred custom actions which
> require admin rights.
> 
> 

Ok.   No, i had wanted it to fail prior to installation (ie. upon running
the MSI, not just preventing them when they hit "Install").

Thanks.

-- 
View this message in context: 
http://n2.nabble.com/Admin-check-in-Win-2008-tp4557002p4567388.html
Sent from the wix-users mailing list archive at Nabble.com.

--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Selectively uninstalling components during major upgrade

[Blair]

That's why there are custom actions.

Updated files shouldn't be removed if the component rules are followed with
late scheduling (in fact, updated files being removed is a sign that the
component rules are not being followed).

-Original Message-
From: Sebastiaan Deckers [mailto:c...@pandion.im] 
Sent: Saturday, February 13, 2010 4:11 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Selectively uninstalling components during major
upgrade

Hi Blair,

Thanks again for your advice. Sadly the late scheduling causes too
many other problems like updated files being removed. So I'll just
give up on the idea of cleaning up the registry. Not too important.

I really wish Windows Installer provided some kind of procedural
mechanism. I can appreciate the core concept of declarative
installation. But there are so many edge cases which could easily be
handled by small scripted sequences. The declarative syntax is
incredibly frustrating and unintuitive to handle the long tail of
installation quirks. Even NSIS's assembler madness makes it possible
to handle just about any edge case. Just my 0.02.

Sebastiaan


On Sat, Feb 13, 2010 at 2:11 AM, Blair  wrote:
> I looked it up really fast: RemoveRegistryKey/removeOnUninstall creates an
> entry in the Registry table with the Name column being set to "-", which
> causes the key to be removed when the component is removed without
creating
> the key when the component is installed.
>
> The condition isn't part of the Registry table, it is a part of the
> Component table, and component conditions are not used when the feature
> containing the component is removed.
>
> Uninstallation of a component during upgrade is controlled the combination
> of two factors: the presence of the same Component-GUID in the upgrading
> package, and the sequence of the RemoveExistingProducts. If
> RemoveExistingProducts is sequenced early, the component will be removed
> every upgrade. If the same GUID isn't in the new package, the component
will
> be removed every upgrade. You have to place RemoveExistingProducts "late"
> (either right before or after InstallFinalize).
>
> Note that using the "late" placement of RemoveExistingProducts requires a
> more strict observance of the component rules.
>
> -Original Message-
> From: Sebastiaan Deckers [mailto:c...@pandion.im]
> Sent: Friday, February 12, 2010 2:11 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Selectively uninstalling components during major
> upgrade
>
> Thanks for the tip. Unfortunately the registry keys still seem to get
> deleted during the upgrade. I'm using a
> RemoveRegistryKey/removeOnUninstall with the "NOT
> UPGRADINGPRODUCTCODE" Condition. My guess is that the Condition gets
> evaluated at installation time instead of during the upgrade. Is that
> how it works? Then how can I delete these registry keys only during a
> manual uninstall, while leaving them intact during an upgrade?
>
> Thanks again,
>
> Sebastiaan
>
>
> On Fri, Feb 12, 2010 at 3:55 AM, Blair  wrote:
>> The registry removal is probably occurring in the package being removed.
> The
>> upgrading package's properties are not all passed to the packages being
>> removed.
>>
>> The package being removed is given a property "UPGRADINGPRODUCTCODE"
which
>> is the product code of the upgrading package. If you add "AND NOT
>> UPGRADINGPRODUCTCODE" to your "REMOVE"-related condition you should
> achieve
>> what you are trying to do (not that it won't help with packages already
>> released, you will just have to recreate those entries when upgrading
>> already released packages).
>>
>> http://msdn.microsoft.com/library/aa372380.aspx
>>
>> -Original Message-
>> From: Sebastiaan Deckers [mailto:c...@pandion.im]
>> Sent: Thursday, February 11, 2010 8:59 AM
>> To: General discussion for Windows Installer XML toolset.
>> Subject: [WiX-users] Selectively uninstalling components during major
>> upgrade
>>
>> Hi all,
>>
>> Is there a way to prevent removal of specific components when removal
>> is part of a major upgrade, as opposed to just an uninstallation?
>>
>> My app creates certain registry entries at runtime (not the installer
>> but the actual software). I would like to keep these during an upgrade
>> while still cleaning them up during installation.
>>
>> I created a Component with RemoveRegistryKey tags and gave it a
>> Condition that checks for a variable "AUTOUPDATE" which gets passed
>> via command line in case of a major upgrade. This doesn't seem to work
>> as the registry keys are always removed, regardless of the AUTOUPDATE
>> variable.
>>
>> Source code:
>>
>
http://github.com/pandion/pandion/blob/master/Installer/WiX/product.wxs#L259
>>
>> Any suggestions?
>>
>> Sebastiaan
>>
>>
>

>> --
>> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
>> Predictive Self Healin

Re: [WiX-users] Admin check in Win 2008?

[Blair]

-Original Message-
From: Tabmow [mailto:tabmo...@gmail.com] 

> It's not a problem, so much as we prompt a few screens of required info
> before the "Install" button is hit.   Why have a user fill in these few
> screens only to find out they have wrong permissions?  In the past, we
could
> prevent this from happening by the code i quoted.  So all i was trying was
> to do the same behaviour in Windows 2008 R2 if possible.

If UAC is turned on, instead of failure they get an "over-the-shoulder"
prompt, which allows anyone who is in the Administrators group to provide
credentials that will allow the installation to proceed. Because of that,
not being an administrator isn't exactly a "you can't install" situation any
more.

> I tried the exact "InstallPrivileges" and "Condition Message" line (with
my
> own msg of course), and now non-admin users cannot run the MSI and get my
> warning message, which is great.   Running the MSI as Administrator works
> fine.   But if i run the MSI as a user who is part of "Administrators"
> group, shouldn't that user still be allowed to run the MSI?   That user
> still gets denied like a regular user.   Again, this is Windows 2008 R2 if
> that makes a difference.   Or am I missing something? 

If UAC is turned on, members of the Adminstrators group that are not the
built-in Administrator account run with non-privileged credentials. Only
when they click "continue" do they use the "admin-enabled" credentials you
are testing for.

The pre-Vista/Server 2008 experience you are seeking requires turning UAC
off. UAC enables non-admin users to run privileged operations with the
consent of an admin without requiring a separate login, while also helping
protect the system from unexpected system changes when running code as an
"admin" user.


--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users