[WiX-users] Looking for Simple COM Component Install Info

[Jamison Wilde]

I've tried reading the info here, but it all seems
incomplete, or assumes lots of knowledge of Windows
Installer already. There is no basic info for people
coming to this for this first time in my opinion,
besides the excellent tutorial at
http://www.tramontana.co.hu/wix/.

I have never written an installer before, and will
probably only do it a couple more times in my life, so
I'm approaching this from a purely utilitarian point
of view. I don't care how it works, as long as it
does, and I have no philisophical attachment to the
various methods that can be used.

I have a COM DLL Windows Explorer Shell Extension,
which itself uses COM to talk to a Proxy Stub DLL.
This p/s is for talking to an EXE COM Server. The
purpose of this com exe server is to dynamically
generate the right click context menu in explorer
based on the file information, passing back the (wire
marshalled) modified HMENU, which works just fine.
Additonal info on this application (ExQueues Shell
Queue) can be found here:
http://sourceforge.net/projects/shellqueue

I have the installer already set up to copy the
relevant files to their destinations, which works just
fine. Now normally, for testing, all I have to do is
type 'regsvr32.exe [mypath]' to 'self-register' the
DLLs. And then run the executable to self-register it
too.

I very simply need the WiX generated MSI to register
these DLLS. I have been unable to find a simple
example which shows this in action.

I understand that I may need to create a Custom Action
to register my EXE-based Components, since this is not
supported by WiX, ala :
<CustomAction Id="Register"
FileKey="SelfRegistering_exe"
ExeCommand="/RegServer"
Execute="immediate"
Return="check"/>

<CustomAction Id="Unregister"
FileKey="SelfRegistering_exe"
ExeCommand="/UnregServer"
Execute="immediate"
Return="check"/>

<InstallExecuteSequence>
<Custom Action="Register"

After="InstallFinalize">(ADDLOCAL="Feature_Default")</Custom>
<Custom Action="Unregister"
Before="RemoveFiles">(REMOVE="ALL")</Custom>
</InstallExecuteSequence>

If this is still true, please verify this information.
If anyone has a more complete example, please post as
well (for example with the parent tags as well).
Where does this Custom Action go in the WiX source
file (in which or after which tags)? My wxs files is
based on Sample 4 from http://www.tramontana.co.hu/wix
(and can be seen directly in CVS at my project page).

I understand that there is some divisivness over using
'SelfReg', but if it works for a simple project, do I
really want to generate another set of tasks to do at
build time? (Not asking rhetorically.)

How do I register my 2 COM DLLs? 'tallow' does
nothing but fall over (invalid format) for my DLLs)and
exe obviously). How would I use self-reg for these,
since it seems to work just fine using regsrv32? Do I
need to use the <COmponent><Class> child tag? If so,
are there some examples of
this(web/mailarchive/personal), including which guids
need to be used where?

Thanks for your time, and hope others may find the
answers(?) useful as well. I apologize if the answers
are already on this list, but the basic search
functions suck at sf, and google has fits with things
like 'com' 'server' 'register'.

S. Jamison Wilde







__________________________________
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
http://birthday.yahoo.com/netrospective/

[Jamison Wilde]

Okay, so of course right after sending my email, I
realized that I was searching for 'regsrv32' instead
of 'regsvr32' which was more helpful.

I get that using SelfReg may not be the best thing,
but what is the alternative given that tallow just
doesn't work most of the time? Is it just a matter of
copying all of this stuff by hand? How would I do it
differntly on a per use basis (meaning I dont want the
shell extension to register for all users)?

Given that I am more of a financial datacenter
transaction processing programmer in background, and
this is my first com/windows/gui/wtl/wix project in 6
years, and seeing a uuid makes me cringe, please be
kind. ;-) I'm just trying to get my tool released,
lol.






__________________________________
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
http://birthday.yahoo.com/netrospective/

[Subbu Balakrishnan]

Hi Jamison

You may want to use the (VS 2003.NET installed) utility RegCap.exe which (in
my experience atleast) does a decent job of COM self-registration capture
and works with .EXE/.TLB files as well. Parse the resultant output manually
into WiX format or (better) use Orion Edwards' Reg2Wxi utility (you'll need
to email him at orion<at>coke.net.nz for this) to convert the .reg format
that RegCap.exe uses into a WiX Fragment.

HTH
Regards
Subbu

COM self-registration in MSIs is evil!

-----Original Message-----
From: Jamison Wilde [mailto:***@yahoo.com]
Sent: Tuesday, 8 March 2005 9:03 AM
To: wix-***@lists.sf.net
Subject: [WiX-users] Looking for Simple COM Component Install Info


I've tried reading the info here, but it all seems
incomplete, or assumes lots of knowledge of Windows
Installer already. There is no basic info for people
coming to this for this first time in my opinion,
besides the excellent tutorial at
http://www.tramontana.co.hu/wix/.

I have never written an installer before, and will
probably only do it a couple more times in my life, so
I'm approaching this from a purely utilitarian point
of view. I don't care how it works, as long as it
does, and I have no philisophical attachment to the
various methods that can be used.

I have a COM DLL Windows Explorer Shell Extension,
which itself uses COM to talk to a Proxy Stub DLL.
This p/s is for talking to an EXE COM Server. The
purpose of this com exe server is to dynamically
generate the right click context menu in explorer
based on the file information, passing back the (wire
marshalled) modified HMENU, which works just fine.
Additonal info on this application (ExQueues Shell
Queue) can be found here:
http://sourceforge.net/projects/shellqueue

I have the installer already set up to copy the
relevant files to their destinations, which works just
fine. Now normally, for testing, all I have to do is
type 'regsvr32.exe [mypath]' to 'self-register' the
DLLs. And then run the executable to self-register it
too.

I very simply need the WiX generated MSI to register
these DLLS. I have been unable to find a simple
example which shows this in action.

I understand that I may need to create a Custom Action
to register my EXE-based Components, since this is not
supported by WiX, ala :
<CustomAction Id="Register"
FileKey="SelfRegistering_exe"
ExeCommand="/RegServer"
Execute="immediate"
Return="check"/>

<CustomAction Id="Unregister"
FileKey="SelfRegistering_exe"
ExeCommand="/UnregServer"
Execute="immediate"
Return="check"/>

<InstallExecuteSequence>
<Custom Action="Register"

After="InstallFinalize">(ADDLOCAL="Feature_Default")</Custom>
<Custom Action="Unregister"
Before="RemoveFiles">(REMOVE="ALL")</Custom>
</InstallExecuteSequence>

If this is still true, please verify this information.
If anyone has a more complete example, please post as
well (for example with the parent tags as well).
Where does this Custom Action go in the WiX source
file (in which or after which tags)? My wxs files is
based on Sample 4 from http://www.tramontana.co.hu/wix
(and can be seen directly in CVS at my project page).

I understand that there is some divisivness over using
'SelfReg', but if it works for a simple project, do I
really want to generate another set of tasks to do at
build time? (Not asking rhetorically.)

How do I register my 2 COM DLLs? 'tallow' does
nothing but fall over (invalid format) for my DLLs)and
exe obviously). How would I use self-reg for these,
since it seems to work just fine using regsrv32? Do I
need to use the <COmponent><Class> child tag? If so,
are there some examples of
this(web/mailarchive/personal), including which guids
need to be used where?

Thanks for your time, and hope others may find the
answers(?) useful as well. I apologize if the answers
are already on this list, but the basic search
functions suck at sf, and google has fits with things
like 'com' 'server' 'register'.

S. Jamison Wilde







__________________________________
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
http://birthday.yahoo.com/netrospective/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

[Orion Edwards]

tallow in later builds will also convert a .reg file to a wix fragment, so
that's probably easier and more reliable :-)

Post by Subbu Balakrishnan
Hi Jamison
You may want to use the (VS 2003.NET installed) utility RegCap.exe which (in
my experience atleast) does a decent job of COM self-registration capture
and works with .EXE/.TLB files as well. Parse the resultant output manually
into WiX format or (better) use Orion Edwards' Reg2Wxi utility (you'll need
to email him at orion<at>coke.net.nz for this) to convert the .reg format
that RegCap.exe uses into a WiX Fragment.
HTH
Regards
Subbu
COM self-registration in MSIs is evil!
-----Original Message-----
Sent: Tuesday, 8 March 2005 9:03 AM
Subject: [WiX-users] Looking for Simple COM Component Install Info
I've tried reading the info here, but it all seems
incomplete, or assumes lots of knowledge of Windows
Installer already. There is no basic info for people
coming to this for this first time in my opinion,
besides the excellent tutorial at
http://www.tramontana.co.hu/wix/.
I have never written an installer before, and will
probably only do it a couple more times in my life, so
I'm approaching this from a purely utilitarian point
of view. I don't care how it works, as long as it
does, and I have no philisophical attachment to the
various methods that can be used.
I have a COM DLL Windows Explorer Shell Extension,
which itself uses COM to talk to a Proxy Stub DLL.
This p/s is for talking to an EXE COM Server. The
purpose of this com exe server is to dynamically
generate the right click context menu in explorer
based on the file information, passing back the (wire
marshalled) modified HMENU, which works just fine.
Additonal info on this application (ExQueues Shell
http://sourceforge.net/projects/shellqueue
I have the installer already set up to copy the
relevant files to their destinations, which works just
fine. Now normally, for testing, all I have to do is
type 'regsvr32.exe [mypath]' to 'self-register' the
DLLs. And then run the executable to self-register it
too.
I very simply need the WiX generated MSI to register
these DLLS. I have been unable to find a simple
example which shows this in action.
I understand that I may need to create a Custom Action
to register my EXE-based Components, since this is not
<CustomAction Id="Register"
FileKey="SelfRegistering_exe"
ExeCommand="/RegServer"
Execute="immediate"
Return="check"/>
<CustomAction Id="Unregister"
FileKey="SelfRegistering_exe"
ExeCommand="/UnregServer"
Execute="immediate"
Return="check"/>
<InstallExecuteSequence>
<Custom Action="Register"
After="InstallFinalize">(ADDLOCAL="Feature_Default")</Custom>
<Custom Action="Unregister"
Before="RemoveFiles">(REMOVE="ALL")</Custom>
</InstallExecuteSequence>
If this is still true, please verify this information.
If anyone has a more complete example, please post as
well (for example with the parent tags as well).
Where does this Custom Action go in the WiX source
file (in which or after which tags)? My wxs files is
based on Sample 4 from http://www.tramontana.co.hu/wix
(and can be seen directly in CVS at my project page).
I understand that there is some divisivness over using
'SelfReg', but if it works for a simple project, do I
really want to generate another set of tasks to do at
build time? (Not asking rhetorically.)
How do I register my 2 COM DLLs? 'tallow' does
nothing but fall over (invalid format) for my DLLs)and
exe obviously). How would I use self-reg for these,
since it seems to work just fine using regsrv32? Do I
need to use the <COmponent><Class> child tag? If so,
are there some examples of
this(web/mailarchive/personal), including which guids
need to be used where?
Thanks for your time, and hope others may find the
answers(?) useful as well. I apologize if the answers
are already on this list, but the basic search
functions suck at sf, and google has fits with things
like 'com' 'server' 'register'.
S. Jamison Wilde
__________________________________
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
http://birthday.yahoo.com/netrospective/
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users

[Roel Vanhout]

Post by Subbu Balakrishnan
COM self-registration in MSIs is evil!

This has probably been discussed before, so sorry if I ask a stupid
question, but why is that?


cheers,

roel

[Orion Edwards]

Someone's probably mentioned this but here's what happened to me.

User installs product, all is fine
User decided to 'uninstall' product manually, that is just delete all it's
files. (The customer is always right you know).
User then tries to install later version of product which triggers upgrade.
Upgrade calls RemoveExistingProducts which then goes and uninstalls old
version. Old version calls regsvr32 /u on a file which isn't there, uninstall
FAILS. upgrade FAILS. Cannot repair as they've lost the old install CD. MSIZap
is the only way to fix it.

Another problem is the sequencing of RemoveExistingProducts on major upgrades.
Typically RemoveExistingProducts is done sometime after the new product has
been installed. It's very easy to get the conditions wrong on your 'unregister'
CA, and hence have the user upgrade your product which causes your COM objects
to no longer be registered... neat aye.

Oh, and what happens when you call regsvr on a file and you're not an
administrative user? The answer is that it fails and you lose. If you handle
the registry entries yourself then MSI will put then in HKCU and have the COM
object registered per-user (regsvr can't do this no matter how much you want it
to)

While self register does work and in itself is fine, basically you're opening
yourself up to literally hundreds of other follow-on-effect type bugs which can
all be easily avoided you just use RegCap and write some registry entries :P

If you do pay any attention to this, remember to use RegCap /I otherwise you'll
have fun as it doesn't catch COM Interfaces by default, but basically the gist
of what you're doing is shifting your COM registration failure point from
user-install time to your-build time, which is much much much MUCH better
practice.

Post by Roel Vanhout

Post by Subbu Balakrishnan
COM self-registration in MSIs is evil!

This has probably been discussed before, so sorry if I ask a stupid
question, but why is that?
cheers,
roel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users

[Subbu Balakrishnan]

Thanks for the reminder Orion - I did notice tallow sporting a new switch!
Old habits eh?

There you go Jamieson, you'll still need regcap.exe though.

-----Original Message-----
From: Orion Edwards [mailto:***@coke.net.nz]
Sent: Tuesday, 8 March 2005 2:16 PM
To: Subbu Balakrishnan
Cc: 'Jamison Wilde'; wix-***@lists.sf.net
Subject: RE: [WiX-users] Looking for Simple COM Component Install Info


tallow in later builds will also convert a .reg file to a wix fragment, so
that's probably easier and more reliable :-)

Post by Subbu Balakrishnan
Hi Jamison
You may want to use the (VS 2003.NET installed) utility RegCap.exe which

(in

Post by Subbu Balakrishnan
my experience atleast) does a decent job of COM self-registration capture
and works with .EXE/.TLB files as well. Parse the resultant output

manually

Post by Subbu Balakrishnan
into WiX format or (better) use Orion Edwards' Reg2Wxi utility (you'll

need

Post by Subbu Balakrishnan
to email him at orion<at>coke.net.nz for this) to convert the .reg format
that RegCap.exe uses into a WiX Fragment.
HTH
Regards
Subbu
COM self-registration in MSIs is evil!
-----Original Message-----
Sent: Tuesday, 8 March 2005 9:03 AM
Subject: [WiX-users] Looking for Simple COM Component Install Info
I've tried reading the info here, but it all seems
incomplete, or assumes lots of knowledge of Windows
Installer already. There is no basic info for people
coming to this for this first time in my opinion,
besides the excellent tutorial at
http://www.tramontana.co.hu/wix/.
I have never written an installer before, and will
probably only do it a couple more times in my life, so
I'm approaching this from a purely utilitarian point
of view. I don't care how it works, as long as it
does, and I have no philisophical attachment to the
various methods that can be used.
I have a COM DLL Windows Explorer Shell Extension,
which itself uses COM to talk to a Proxy Stub DLL.
This p/s is for talking to an EXE COM Server. The
purpose of this com exe server is to dynamically
generate the right click context menu in explorer
based on the file information, passing back the (wire
marshalled) modified HMENU, which works just fine.
Additonal info on this application (ExQueues Shell
http://sourceforge.net/projects/shellqueue
I have the installer already set up to copy the
relevant files to their destinations, which works just
fine. Now normally, for testing, all I have to do is
type 'regsvr32.exe [mypath]' to 'self-register' the
DLLs. And then run the executable to self-register it
too.
I very simply need the WiX generated MSI to register
these DLLS. I have been unable to find a simple
example which shows this in action.
I understand that I may need to create a Custom Action
to register my EXE-based Components, since this is not
<CustomAction Id="Register"
FileKey="SelfRegistering_exe"
ExeCommand="/RegServer"
Execute="immediate"
Return="check"/>
<CustomAction Id="Unregister"
FileKey="SelfRegistering_exe"
ExeCommand="/UnregServer"
Execute="immediate"
Return="check"/>
<InstallExecuteSequence>
<Custom Action="Register"
After="InstallFinalize">(ADDLOCAL="Feature_Default")</Custom>
<Custom Action="Unregister"
Before="RemoveFiles">(REMOVE="ALL")</Custom>
</InstallExecuteSequence>
If this is still true, please verify this information.
If anyone has a more complete example, please post as
well (for example with the parent tags as well).
Where does this Custom Action go in the WiX source
file (in which or after which tags)? My wxs files is
based on Sample 4 from http://www.tramontana.co.hu/wix
(and can be seen directly in CVS at my project page).
I understand that there is some divisivness over using
'SelfReg', but if it works for a simple project, do I
really want to generate another set of tasks to do at
build time? (Not asking rhetorically.)
How do I register my 2 COM DLLs? 'tallow' does
nothing but fall over (invalid format) for my DLLs)and
exe obviously). How would I use self-reg for these,
since it seems to work just fine using regsrv32? Do I
need to use the <COmponent><Class> child tag? If so,
are there some examples of
this(web/mailarchive/personal), including which guids
need to be used where?
Thanks for your time, and hope others may find the
answers(?) useful as well. I apologize if the answers
are already on this list, but the basic search
functions suck at sf, and google has fits with things
like 'com' 'server' 'register'.
S. Jamison Wilde
__________________________________
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
http://birthday.yahoo.com/netrospective/
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users

[Stefan Zschocke]

To have a DLL registered by the Installer using the DllRegisterServer
entry point (same as what RegSvr32.exe does) add
SelfRegCost="0" to the <File ... /> tag of your component.
This will generate a record in the SelfReg-table of the MSI-file. You
can verify this with Orca.exe.
Make sure that the file has KeyPath="yes", too.
Instead of "0", you can also give it a value > 0, this value will be
used by cost-estimation.
Also, give the Component a Guid, then the file will be unregistered and
removed upon uninstall.
I personally don't share the opinion, that self-registering should be
avoided by all means.
BTW, I recommend using Orca to have a look at the generated MSI.
One problem with WIX is: The XML-format invites one to use it, because
one means to understand it. But the underlying MSI is a hell of a beast
and after a while one ends up trying to understand the
MSI-documentation. And here it becomes necessary to understand, how WIX
maps to MSI. This mostly is straight-forward, but not always. Orca comes
into play here, as one can see how WIX maps the wxs input to the
MSI-tables.
Stefan

-----Ursprüngliche Nachricht-----
Von: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] Im Auftrag von Jamison
Wilde
Gesendet: Montag, 7. März 2005 23:03
An: wix-***@lists.sf.net
Betreff: [WiX-users] Looking for Simple COM Component Install Info


I've tried reading the info here, but it all seems
incomplete, or assumes lots of knowledge of Windows
Installer already. There is no basic info for people
coming to this for this first time in my opinion,
besides the excellent tutorial at http://www.tramontana.co.hu/wix/.

I have never written an installer before, and will
probably only do it a couple more times in my life, so
I'm approaching this from a purely utilitarian point
of view. I don't care how it works, as long as it
does, and I have no philisophical attachment to the
various methods that can be used.

I have a COM DLL Windows Explorer Shell Extension,
which itself uses COM to talk to a Proxy Stub DLL.
This p/s is for talking to an EXE COM Server. The
purpose of this com exe server is to dynamically
generate the right click context menu in explorer
based on the file information, passing back the (wire
marshalled) modified HMENU, which works just fine.
Additonal info on this application (ExQueues Shell
Queue) can be found here:
http://sourceforge.net/projects/shellqueue

I have the installer already set up to copy the
relevant files to their destinations, which works just
fine. Now normally, for testing, all I have to do is
type 'regsvr32.exe [mypath]' to 'self-register' the
DLLs. And then run the executable to self-register it
too.

I very simply need the WiX generated MSI to register
these DLLS. I have been unable to find a simple
example which shows this in action.

I understand that I may need to create a Custom Action
to register my EXE-based Components, since this is not supported by WiX,
ala : <CustomAction Id="Register"
FileKey="SelfRegistering_exe"
ExeCommand="/RegServer"
Execute="immediate"
Return="check"/>

<CustomAction Id="Unregister"
FileKey="SelfRegistering_exe"
ExeCommand="/UnregServer"
Execute="immediate"
Return="check"/>

<InstallExecuteSequence>
<Custom Action="Register"

After="InstallFinalize">(ADDLOCAL="Feature_Default")</Custom>
<Custom Action="Unregister"
Before="RemoveFiles">(REMOVE="ALL")</Custom>
</InstallExecuteSequence>

If this is still true, please verify this information.
If anyone has a more complete example, please post as
well (for example with the parent tags as well).
Where does this Custom Action go in the WiX source
file (in which or after which tags)? My wxs files is
based on Sample 4 from http://www.tramontana.co.hu/wix
(and can be seen directly in CVS at my project page).

I understand that there is some divisivness over using 'SelfReg', but if
it works for a simple project, do I really want to generate another set
of tasks to do at build time? (Not asking rhetorically.)

How do I register my 2 COM DLLs? 'tallow' does
nothing but fall over (invalid format) for my DLLs)and
exe obviously). How would I use self-reg for these,
since it seems to work just fine using regsrv32? Do I
need to use the <COmponent><Class> child tag? If so,
are there some examples of
this(web/mailarchive/personal), including which guids
need to be used where?

Thanks for your time, and hope others may find the
answers(?) useful as well. I apologize if the answers
are already on this list, but the basic search
functions suck at sf, and google has fits with things
like 'com' 'server' 'register'.

S. Jamison Wilde

[m***@agfa.com]

It has indeed been a lively discussion in the past.
One of the issues I remember is deinstallation and upgrades:
Rob can tell explain this far better than I do, but it comes down to this
one:
If you do not have registry entries explictely installed in you installer,
MSI cannot track them.

Marc




|---------+------------------------------------->
| | Roel Vanhout |
| | <***@riks.nl> |
| | Sent by: |
| | wix-users-***@lists.sour|
| | ceforge.net |
| | |
| | |
| | 08/03/2005 10:57 |
| | |
|---------+------------------------------------->

------------------------------------------------------------------------------------------------------------------------------|

| |
| To: Subbu Balakrishnan <***@au.integra-t.com> |
| cc: "'Jamison Wilde'" <***@yahoo.com>, wix-***@lists.sourceforge.net, (bcc: Marc |
| Borgers/AMNTU/MOR/AGFA/BE/BAYER) |
| Subject: Re: [WiX-users] Looking for Simple COM Component Install Info |

------------------------------------------------------------------------------------------------------------------------------|
COM self-registration in MSIs is evil!

This has probably been discussed before, so sorry if I ask a stupid
question, but why is that?


cheers,

roel



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

[Leon Zandman]

Post by Subbu Balakrishnan
COM self-registration in MSIs is evil!

I think this is because in the case of self-registration the installer
doesn't "know" anything about what is happening when the component
registers itself. So it has to rely on the COM component do install (and
uninstall) itself in the proper way.

When the installer manually installs a COM component every registry key
that is needed is known by the installer, so all those keys will be
removed when deinstalling.

I personally always use self-registration, because sometimes a COM
component does other things besides changing the registry. It could also
create directories etc. while registering. To monitor and catch
everything a COM-component does isn't always that easy (I think Mallow
only watches registry changes). If a COM component doesn't clean itself
completely then it's not my problem :-)

Greetz,

Leon

[Stefan Zschocke]

Agreed!!!
For me it is a matter of encapsulation, too.
As long as there is no automatism, which guarantees that the
registry-keys etc of the wix-script stay in synch with the actual
registry-info written by the com-server, the danger, that my install
script is out of synch outweighs the benefits of having MSI taking care
of the registration process.
BTW. Good place to thank you, Leon, for this ALT-G trick with
VStudio.Net (The GUID-creation thing), very handy, don't know how I did
get along without it.
Stefan

-----Ursprüngliche Nachricht-----
Von: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] Im Auftrag von Leon
Zandman
Gesendet: Dienstag, 8. März 2005 11:18
An: Roel Vanhout
Cc: wix-***@lists.sourceforge.net
Betreff: RE: [WiX-users] Looking for Simple COM Component Install Info

Post by Subbu Balakrishnan
COM self-registration in MSIs is evil!

I think this is because in the case of self-registration the installer
doesn't "know" anything about what is happening when the component
registers itself. So it has to rely on the COM component do install (and
uninstall) itself in the proper way.

When the installer manually installs a COM component every registry key
that is needed is known by the installer, so all those keys will be
removed when deinstalling.

I personally always use self-registration, because sometimes a COM
component does other things besides changing the registry. It could also
create directories etc. while registering. To monitor and catch
everything a COM-component does isn't always that easy (I think Mallow
only watches registry changes). If a COM component doesn't clean itself
completely then it's not my problem :-)

Greetz,

Leon

[Leon Zandman]

Post by Stefan Zschocke
As long as there is no automatism, which guarantees that the
registry-keys etc of the wix-script stay in synch with the
actual registry-info written by the com-server, the danger,
that my install script is out of synch outweighs the benefits
of having MSI taking care of the registration process.

Well, same here. The same thing applies to merge modules. You have to
trust the creator of the merge module that they handle install/uninstall
correctly, e.g. if you use a merge module that contains custom actions
that don't rollback/uninstall correctly your installation as a whole
will still leave traces after it is completely uninstalled. And it's not
your fault!

You can provide many workarounds, but in the end you just have to trust
the component to handle its own installation/uninstallation correctly.

Post by Stefan Zschocke
BTW. Good place to thank you, Leon, for this ALT-G trick with
VStudio.Net

Yeah, once you're used to it you'll never want to go back...

Greetz,

Leon

[Bill Arnette]

Post by Leon Zandman
I personally always use self-registration, because sometimes a COM
component does other things besides changing the registry. It
could also
create directories etc. while registering. To monitor and catch
everything a COM-component does isn't always that easy (I think Mallow
only watches registry changes). If a COM component doesn't
clean itself
completely then it's not my problem :-)

True. But, if the COM server depends on other dlls (atl.dll, a new version
of MSVCRT) then you can't be sure that the dependent dlls have been
installed before the self-registration runs.

[Bob Arnson]

Post by Leon Zandman
I personally always use self-registration, because sometimes a COM
component does other things besides changing the registry. It

And that's exactly why (one of the reasons, anyway), self-registration is a
bad thing. If SelfReg did nothing other than write registry entries, then
it's easy enough to bring that functionality into the installer. But SelfReg
means that you're calling arbitrary code that can do anything. MSI can't
(reasonably) detect what the code does and maintain system state, which
means that (at best) an uninstall might leave all sorts of crud behind.

Post by Leon Zandman
only watches registry changes). If a COM component doesn't
clean itself
completely then it's not my problem :-)

It is your problem, if you're the one who has to support the product.

When I get a new piece of software, I look to see how it's installed. If it
uses MSI, it gets a bonus point. If the MSI is full of custom actions, it
loses a point. If there aren't rollback custom actions, it loses more
points. If the MSI uses SelfReg, it loses more points. And so on. I look at
installation quality as an indicator of the quality of the product as a
whole; if the vendor/developer didn't care to make a high-quality installer,
why should I believe the other parts of the product are high quality?

sig://boB
http://bobs.org

[Leon Zandman]

Post by Bob Arnson

Post by Leon Zandman
If a COM component doesn't clean itself
completely then it's not my problem :-)

It is your problem, if you're the one who has to support the product.

Okay, but I might relay the problem to the one responsible for the
faulty component.

If you don't want these kind of problems you shouldn't use components
created by others, but create everything yourself. It's all a matter of
trust. If we use a component in our software we trust it to
register/unregister itself correctly, just as our customers trust our
software to install/uninstall correctly.

What I meant was that everybody here seems to assume that a component's
self-registration process only involves creating registry entries. But
I've come across cases where there are more things going on, like
creating files/directories etc. Since there isn't an easy way to monitor
all of this, there isn't an easy way to translate all those actions into
MSI/WiX actions. So you're basically left at a crossroads:

1) You perform the registration process yourself, taking the risk that
you may have overlooked something that the component needs.

2) Let the component do its own registration, taking all the risks that
were posted to this mailing list by several people.

What's wise?

Greetings,

Leon Zandman

[Rob Mensching]

I'm glad Bob picked this thread up before I did. I'm tired of sounding like
the crazy setup guy that keeps trying to get people from making bad
technology decisions and messing up customers' machines.

The SelfReg Table
(http://msdn.microsoft.com/library/en-us/msi/setup/selfreg_table.asp) uses
just about the strongest text that they can for discouraging the use of a
feature left in for legacy reasons "authors are strongly advised against
using self registration". I've asked my times to get that text changed to
"Don't use this!" but the doc writers tell me that's not politically correct
(or something like that).

That topic in the MSI SDK also provides several reasons why SelfReg is evil
and one of these days (when I'm done writing all these other documents and
presentations on my TODO list) I'll finally get around to posting a blog
entry (that I expect will take me several days to write) that will try to
capture all of the other reasons why SelfReg is evil.

However, I can assure you any one that works near the Windows Installer will
tell you: "SelfReg is bad for your customers. Using SelfReg puts
customers' machines in jeopardy because you as a developer cannot control
all of the potential failure cases and SelfReg will not properly handle
failure cases and actually injects several more of its own. Things that
hurt your customers are evil, don't use self registration."

If it isn't obvious, I'm a huge proponent of doing the right thing for the
customer. If that means more work is required of the developer then I see
that as a small price to pay. Unless your development work is used by only
one person, yourself, then the cost of failure on the customers' side far
out weighs a few extra lines of code on your side.

Have you looked at how little .wxs code it takes to create a COM server (the
most popular thing to SelfReg)? I have an out-of-proc COM server in a
Windows Service that took me four lines of XML (one of each element: File,
ServiceInstall, AppId, Class) plus one line of XML for each interface I type
into my .midl file (element: Interface). I have no SelfReg code anywhere.
I maintain my .cpp and my .wxs files together... by hand and my build
process spits out an MSI that installs and configures my COM server after
each build.

Okay, I've ranted enough and I apologize if I offended anyone. But please,
don't use SelfReg. It isn't a good thing.

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Roel Vanhout
Sent: Tuesday, March 08, 2005 1:57 AM
To: Subbu Balakrishnan
Cc: 'Jamison Wilde'; wix-***@lists.sf.net
Subject: Re: [WiX-users] Looking for Simple COM Component Install Info

Post by Subbu Balakrishnan
COM self-registration in MSIs is evil!

This has probably been discussed before, so sorry if I ask a stupid
question, but why is that?


cheers,

roel



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

[Rob Mensching]

If you don't own the "thing" that requires SelfReg and the producer
documents that the only way to configure their "thing" is to call SelfReg
then you have only two options:

1. Call SelfReg and know that your customers are going to pay the price for
it.

2. Fire that producer and buy your "things" from somewhere else.

I was stuck in position #1 for a long time because a team in Microsoft
refused to provide a Component that did not require SelfReg. You know what?
Our product support team learned how to spot the install failures from that
team's SelfReg thing that user's hit pretty quickly. I left that setup team
before the data was all collected but based on the cost of a support call to
Microsoft, I expect the producer team got a quick education what their
decision cost the company.

SelfReg is evil. Feel free to spread the word. <smile/>

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Leon Zandman
Sent: Tuesday, March 08, 2005 2:21 PM
To: Bob Arnson; WiX Users
Subject: Re: [WiX-users] Looking for Simple COM Component Install Info

Post by Bob Arnson

Post by Leon Zandman
If a COM component doesn't clean itself
completely then it's not my problem :-)

It is your problem, if you're the one who has to support the product.

Okay, but I might relay the problem to the one responsible for the
faulty component.

If you don't want these kind of problems you shouldn't use components
created by others, but create everything yourself. It's all a matter of
trust. If we use a component in our software we trust it to
register/unregister itself correctly, just as our customers trust our
software to install/uninstall correctly.

What I meant was that everybody here seems to assume that a component's
self-registration process only involves creating registry entries. But
I've come across cases where there are more things going on, like
creating files/directories etc. Since there isn't an easy way to monitor
all of this, there isn't an easy way to translate all those actions into
MSI/WiX actions. So you're basically left at a crossroads:

1) You perform the registration process yourself, taking the risk that
you may have overlooked something that the component needs.

2) Let the component do its own registration, taking all the risks that
were posted to this mailing list by several people.

What's wise?

Greetings,

Leon Zandman


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

[Bob Arnson]

Post by Leon Zandman
Okay, but I might relay the problem to the one responsible for the
faulty component.

Sure, and how long does your user stick around waiting for you to wait on
the faulty component provider to debug the problem and provide a fix?

Post by Leon Zandman
If you don't want these kind of problems you shouldn't use components
created by others, but create everything yourself. It's all a

That isn't the only possible conclusion.<g> Your users don't care about the
components you use; they care about the application they paid good money
for. (Assuming, for the moment, that we're talking about proprietary
software.)

Post by Leon Zandman
trust. If we use a component in our software we trust it to
register/unregister itself correctly, just as our customers trust our
software to install/uninstall correctly.

So what happens when (not if) there's a registration problem? If you treat
the component as a black box, you have no recourse for failure. You also
have no control over how it works; your only flexibility is whether to call.

Trust isn't absolute.

Post by Leon Zandman
What I meant was that everybody here seems to assume that a
component's
self-registration process only involves creating registry
entries. But
I've come across cases where there are more things going on, like
creating files/directories etc.

But that's a Bad Thing(tm), not a Good Thing(tm)! That's not even properly
called "self-registration" any more; it's "do whatever the hell it wants to
do-ation." If it creates files or directories at install time, what does it
do at uninstall time? Unconditionally delete them? What if user data is
stored there? Again, you lose flexibility and choice.

Post by Leon Zandman
1) You perform the registration process yourself, taking the
risk that
you may have overlooked something that the component needs.

No, you ask your component provider to give you the information you need to
do your job as a setup developer. Better yet, get a merge module (or WiX
fragment!) from them. If they say no, say goodbye. If you're paying for the
component, demand it as a customer; point them to
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/s
elfreg_table.asp and http://blogs.msdn.com/robmen/. If it's an in-house
component, get your friendly source-control system administrator to disable
the developer's account until s/he provides a spec.<g>

Post by Leon Zandman
2) Let the component do its own registration, taking all the
risks that
were posted to this mailing list by several people.

As Rob points out, the risks aren't just on you -- they're also on your
users. And your testers. And your support engineers. Setup failures cost
money, from wasted dev and tester time, support costs, and lost business.
Remember, setup if your users' first experience with your software; if it
fails, most users won't take a second look.

Post by Leon Zandman
What's wise?

Follow the advice of the MSI team. If they don't know the right thing to do,
we're all in trouble.<g> MSI isn't easy -- look at what it takes to follow
the component rules. If you're not going to take advantage of the
technology, you're going to a lot of extra trouble without getting the
benefits of a fully declarative setup, compared to using something like Inno
Setup.

sig://boB
http://bobs.org