Re: [WiX-users] Installed: Local; Request: Absent; Action: Null ?
Brian Patton wrote: > If I'm installing a file to the system32 directory, the > SharedDllRefCount='no' attribute on my component seems to be ignored, > and the refcount on the file is set to TWO after installation, which > means the file never gets removed (It gets set to ONE after > uninstallation). Is this a backward-compatibility issue where system32 > files are meant never to be deleted? See the Component Table MSI SDK topic: The installer keeps track of shared DLLs independently of the shared DLL reference count in the registry. If a reference count for a shared DLL exists in the registry, the installer always increments the count when it is installing the file and decrements it when it is uninstalling. If msidbComponentAttributesSharedDllRefCount, is not set, and the reference count does not already exist, the installer will not create one. Note that the SharedDLLs reference count in the registry is incremented for any files installed to the System folder (System32 on Windows NT/Windows 2000). -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installed: Local; Request: Absent; Action: Null ?
If I'm installing a file to the system32 directory, the SharedDllRefCount='no' attribute on my component seems to be ignored, and the refcount on the file is set to TWO after installation, which means the file never gets removed (It gets set to ONE after uninstallation). Is this a backward-compatibility issue where system32 files are meant never to be deleted? Has anyone else had this problem? -Brian On 12/21/06, Arnette, Bill <[EMAIL PROTECTED]> wrote: > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > André Pönitz > Sent: Thursday, December 21, 2006 3:20 AM > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Installed: Local; Request: Absent; > Action: Null ? > > Arnette, Bill wrote: > > Non-Windows Installer installers use the SharedDlls registry > > key to refcount the usage of common/shared dlls. By default > > Windows Installer will only increment that refcount if it > > already exists so that the other installer will track the > > refcount properly if a WI installer installs the same file. > > Windows Installer also maintains its own refcount for > > components it tracks elsewhere. You can force Windows > > Installer to create a SharedDLLs entry if it doesn't already > > exist with the msidbComponentAttributesSharedDllRefCount > > attribute on a component. > > So this is what the SharedDllRefCount='yes' attribute means... > > Let me try to get the consequences for me straight: if I have > an old installer using the SharedDll mechanism and new installers > are msi based (and will stay so for the forseeable future) I > would not have to explicitly use SharedDllRefCount='yes' and > it'd still work if I install my newer version in parallel (yes, > we do that...) to the older version and I could deinstall > in arbitrary order. As I understand it, yes; theoretically :) > > It would not work, however, if I installed the new version first > and than the older one in parallel. But as that's not a > scenario I need to support, I'd be ok without using the > SharedDllRefCount='yes' attribute. > > Did I get that right? Right, because unless you explicitly tell MSI to use SharedDllRefCount, the other/older installer is unaware that the MSI-installed product/version is sharing that file. > > > So what that log indicates is that a non-WI installer > > installed that file before your product was installed and > > that since the SharedDlls refcount will not go to 0 after > > your product is uninstalled, the file will not be removed so > > that the other product is not broken. > > Ok, that's probably exactly what happens as I have an > older version installed (or at least not fully uninstalled) > > Thanks for the explanation, > Andre' Glad I could help. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- === Brian Patton http://people.bu.edu/bjp/ http://people.bu.edu/reallife/ourstories.html - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installed: Local; Request: Absent; Action: Null ?
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > André Pönitz > Sent: Thursday, December 21, 2006 3:20 AM > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Installed: Local; Request: Absent; > Action: Null ? > > Arnette, Bill wrote: > > Non-Windows Installer installers use the SharedDlls registry > > key to refcount the usage of common/shared dlls. By default > > Windows Installer will only increment that refcount if it > > already exists so that the other installer will track the > > refcount properly if a WI installer installs the same file. > > Windows Installer also maintains its own refcount for > > components it tracks elsewhere. You can force Windows > > Installer to create a SharedDLLs entry if it doesn't already > > exist with the msidbComponentAttributesSharedDllRefCount > > attribute on a component. > > So this is what the SharedDllRefCount='yes' attribute means... > > Let me try to get the consequences for me straight: if I have > an old installer using the SharedDll mechanism and new installers > are msi based (and will stay so for the forseeable future) I > would not have to explicitly use SharedDllRefCount='yes' and > it'd still work if I install my newer version in parallel (yes, > we do that...) to the older version and I could deinstall > in arbitrary order. As I understand it, yes; theoretically :) > > It would not work, however, if I installed the new version first > and than the older one in parallel. But as that's not a > scenario I need to support, I'd be ok without using the > SharedDllRefCount='yes' attribute. > > Did I get that right? Right, because unless you explicitly tell MSI to use SharedDllRefCount, the other/older installer is unaware that the MSI-installed product/version is sharing that file. > > > So what that log indicates is that a non-WI installer > > installed that file before your product was installed and > > that since the SharedDlls refcount will not go to 0 after > > your product is uninstalled, the file will not be removed so > > that the other product is not broken. > > Ok, that's probably exactly what happens as I have an > older version installed (or at least not fully uninstalled) > > Thanks for the explanation, > Andre' Glad I could help. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installed: Local; Request: Absent; Action: Null ?
Arnette, Bill wrote: > Non-Windows Installer installers use the SharedDlls registry > key to refcount the usage of common/shared dlls. By default > Windows Installer will only increment that refcount if it > already exists so that the other installer will track the > refcount properly if a WI installer installs the same file. > Windows Installer also maintains its own refcount for > components it tracks elsewhere. You can force Windows > Installer to create a SharedDLLs entry if it doesn't already > exist with the msidbComponentAttributesSharedDllRefCount > attribute on a component. So this is what the SharedDllRefCount='yes' attribute means... Let me try to get the consequences for me straight: if I have an old installer using the SharedDll mechanism and new installers are msi based (and will stay so for the forseeable future) I would not have to explicitly use SharedDllRefCount='yes' and it'd still work if I install my newer version in parallel (yes, we do that...) to the older version and I could deinstall in arbitrary order. It would not work, however, if I installed the new version first and than the older one in parallel. But as that's not a scenario I need to support, I'd be ok without using the SharedDllRefCount='yes' attribute. Did I get that right? > So what that log indicates is that a non-WI installer > installed that file before your product was installed and > that since the SharedDlls refcount will not go to 0 after > your product is uninstalled, the file will not be removed so > that the other product is not broken. Ok, that's probably exactly what happens as I have an older version installed (or at least not fully uninstalled) Thanks for the explanation, Andre' - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installed: Local; Request: Absent; Action: Null ?
Non-Windows Installer installers use the SharedDlls registry key to refcount
the usage of common/shared dlls. By default Windows Installer will only
increment that refcount if it already exists so that the other installer will
track the refcount properly if a WI installer installs the same file. Windows
Installer also maintains its own refcount for components it tracks elsewhere.
You can force Windows Installer to create a SharedDLLs entry if it doesn't
already exist with the msidbComponentAttributesSharedDllRefCount attribute on a
component.
So what that log indicates is that a non-WI installer installed that file
before your product was installed and that since the SharedDlls refcount will
not go to 0 after your product is uninstalled, the file will not be removed so
that the other product is not broken.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> André Pönitz
> Sent: Wednesday, December 20, 2006 6:50 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Installed: Local; Request: Absent;
> Action: Null ?
>
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of
> > André Pönitz
> > Sent: Wednesday, December 20, 2006 12:34 PM
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] Installed: Local; Request: Absent;
> Action: Null ?
> >
> >
> >
> > Can anybody explain me why I get the 'Action: Null'
> > "decision" in some cases, but not in all?
> >
> > MSI (s) (68:C0) [12:28:49:678]: Component: Hasp_52;
> > Installed: Local; Request: Absent; Action: Absent
> > MSI (s) (68:C0) [12:28:49:678]: Component: NetlmProgramMenu;
> > Installed: Local; Request: Absent; Action: Absent
> > MSI (s) (68:C0) [12:28:49:678]: Component:
> > NetlmProgramMenuWasyTools; Installed: Local; Request:
> > Absent; Action: Absent
> > MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClient32_1;
> > Installed: Local; Request: Absent; Action: Null
> > MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClient32_2;
> > Installed: Local; Request: Absent; Action: Null
> > MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClient32_3;
> > Installed: Local; Request: Absent; Action: Null
> > MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClientHelp;
> > Installed: Local; Request: Absent; Action: Null
> > MSI (s) (68:C0) [12:28:49:678]: Component:
> > NetlmClientProgramMenu; Installed: Local; Request: Absent;
> > Action: Absent
> >
> > A difference is that the 'Client' is in an Fragment, the rest
> > is in the main body of the installer.
>
>
> Some more information from the log:
>
> MSI (s) (68:E4) [12:40:17:485]: Executing op:
> ComponentUnregister(ComponentId={E88B9844-688B-40FA-8BD3-E137E
> AABD18C},,BinaryType=0,)
> 1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2:
> {E88B9844-688B-40FA-8BD3-E137EAABD18C}
> MSI (s) (68:E4) [12:40:17:501]: Executing op:
> ComponentUnregister(ComponentId={E88B9844-688B-40FA-8BD3-E137E
> AABD1DA},,BinaryType=0,)
> 1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2:
> {E88B9844-688B-40FA-8BD3-E137EAABD1DA}
> MSI (s) (68:E4) [12:40:17:501]: Executing op:
> ComponentUnregister(ComponentId={F0A3B0D2-F9C6-C00F-8817-DAAC3
> 131390C},,BinaryType=0,PreviouslyPinned=1)
> 1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2:
> {F0A3B0D2-F9C6-C00F-8817-DAAC3131390C}
> MSI (s) (68:E4) [12:40:17:501]: Executing op:
> ComponentUnregister(ComponentId={F0A3B0D2-F9C6-C00F-8817-DAAC3
> 231390C},,BinaryType=0,PreviouslyPinned=1)
> 1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2:
> {F0A3B0D2-F9C6-C00F-8817-DAAC3231390C}
> MSI (s) (68:E4) [12:40:17:501]: Executing op:
> ComponentUnregister(ComponentId={F0A3B0D2-F9C6-C00F-8817-DAAC3
> 331390C},,BinaryType=0,PreviouslyPinned=1)
> 1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2:
> {F0A3B0D2-F9C6-C00F-8817-DAAC3331390C}
> MSI (s) (68:E4) [12:40:17:501]: Executing op:
> ComponentUnregister(ComponentId={F0A3B0D2-F9C6-C00F-8817-DAAC3
> 1313AAA},,BinaryType=0,PreviouslyPinned=1)
> 1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2:
> {f0a3B0D2-F9C6-C00F-8817-DAAC31313AAA}
> MSI (s) (68:E4) [12:40:17:501]: Executing op:
> ComponentUnregister(ComponentId={E88B9844-688B-C00F-8BD3-E137E
> AA1D18C},,BinaryType=0,)
> 1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2:
> {E88B9844-688B-C00F-8BD3-E137EAA1D18C}
>
> The not-removed componets are the ones that have the
> 'PreviouslyPinned=1' part which a Google Search turns into
> entries in:
>
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\S
> h
Re: [WiX-users] Installed: Local; Request: Absent; Action: Null ?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> André Pönitz
> Sent: Wednesday, December 20, 2006 12:34 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Installed: Local; Request: Absent; Action: Null ?
>
>
>
> Can anybody explain me why I get the 'Action: Null'
> "decision" in some cases, but not in all?
>
> MSI (s) (68:C0) [12:28:49:678]: Component: Hasp_52;
> Installed: Local; Request: Absent; Action: Absent
> MSI (s) (68:C0) [12:28:49:678]: Component: NetlmProgramMenu;
> Installed: Local; Request: Absent; Action: Absent
> MSI (s) (68:C0) [12:28:49:678]: Component:
> NetlmProgramMenuWasyTools; Installed: Local; Request:
> Absent; Action: Absent
> MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClient32_1;
> Installed: Local; Request: Absent; Action: Null
> MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClient32_2;
> Installed: Local; Request: Absent; Action: Null
> MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClient32_3;
> Installed: Local; Request: Absent; Action: Null
> MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClientHelp;
> Installed: Local; Request: Absent; Action: Null
> MSI (s) (68:C0) [12:28:49:678]: Component:
> NetlmClientProgramMenu; Installed: Local; Request: Absent;
> Action: Absent
>
> A difference is that the 'Client' is in an Fragment, the rest
> is in the main body of the installer.
Some more information from the log:
MSI (s) (68:E4) [12:40:17:485]: Executing op:
ComponentUnregister(ComponentId={E88B9844-688B-40FA-8BD3-E137EAABD18C},,BinaryType=0,)
1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2:
{E88B9844-688B-40FA-8BD3-E137EAABD18C}
MSI (s) (68:E4) [12:40:17:501]: Executing op:
ComponentUnregister(ComponentId={E88B9844-688B-40FA-8BD3-E137EAABD1DA},,BinaryType=0,)
1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2:
{E88B9844-688B-40FA-8BD3-E137EAABD1DA}
MSI (s) (68:E4) [12:40:17:501]: Executing op:
ComponentUnregister(ComponentId={F0A3B0D2-F9C6-C00F-8817-DAAC3131390C},,BinaryType=0,PreviouslyPinned=1)
1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2:
{F0A3B0D2-F9C6-C00F-8817-DAAC3131390C}
MSI (s) (68:E4) [12:40:17:501]: Executing op:
ComponentUnregister(ComponentId={F0A3B0D2-F9C6-C00F-8817-DAAC3231390C},,BinaryType=0,PreviouslyPinned=1)
1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2:
{F0A3B0D2-F9C6-C00F-8817-DAAC3231390C}
MSI (s) (68:E4) [12:40:17:501]: Executing op:
ComponentUnregister(ComponentId={F0A3B0D2-F9C6-C00F-8817-DAAC3331390C},,BinaryType=0,PreviouslyPinned=1)
1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2:
{F0A3B0D2-F9C6-C00F-8817-DAAC3331390C}
MSI (s) (68:E4) [12:40:17:501]: Executing op:
ComponentUnregister(ComponentId={F0A3B0D2-F9C6-C00F-8817-DAAC31313AAA},,BinaryType=0,PreviouslyPinned=1)
1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2:
{f0a3B0D2-F9C6-C00F-8817-DAAC31313AAA}
MSI (s) (68:E4) [12:40:17:501]: Executing op:
ComponentUnregister(ComponentId={E88B9844-688B-C00F-8BD3-E137EAA1D18C},,BinaryType=0,)
1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2:
{E88B9844-688B-C00F-8BD3-E137EAA1D18C}
The not-removed componets are the ones that have the
'PreviouslyPinned=1' part which a Google Search turns into
entries in:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls
Now the question: By what installer mechanism do entries turn up in this
location and under which circumstances are they useful?
Andre'
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Installed: Local; Request: Absent; Action: Null ?
Can anybody explain me why I get the 'Action: Null' "decision" in some cases, but not in all? MSI (s) (68:C0) [12:28:49:678]: Component: Hasp_52; Installed: Local; Request: Absent; Action: Absent MSI (s) (68:C0) [12:28:49:678]: Component: NetlmProgramMenu; Installed: Local; Request: Absent; Action: Absent MSI (s) (68:C0) [12:28:49:678]: Component: NetlmProgramMenuWasyTools; Installed: Local; Request: Absent; Action: Absent MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClient32_1; Installed: Local; Request: Absent; Action: Null MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClient32_2; Installed: Local; Request: Absent; Action: Null MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClient32_3; Installed: Local; Request: Absent; Action: Null MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClientHelp; Installed: Local; Request: Absent; Action: Null MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClientProgramMenu; Installed: Local; Request: Absent; Action: Absent A difference is that the 'Client' is in an Fragment, the rest is in the main body of the installer. Andre' - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
