Dmitry Streblechenko seems to indicate that his preferred method of
installing Redemption.dll is to have it self-register. However,
self-registering as a deployment method for dlls has fallen out of
favor.

I would like to create a Windows Installer correct merge module for the
custom Redemption dll that I'm about to make that my company will use.
I would like to get all of the registry values that Redemption creates
when it self-registers, and put those keys in the Registry table of my
merge module.

Will this work in all cases?

One concern I have is that Redemption.dll could have conditional code
in its implementation of DllRegisterServer such that the registry keys
it creates vary depending on the target system's setup. Can anyone
confirm or deny this?

Also, it would be most ideal if Dmitry would create a merge module for
his Redemption dll, so that users of it would have the one and only
correct merge module that they could then integrate into their
respective Windows Installer .msi packages. Are there any plans for
such a merge module?

Thanks!
Jeff

MS is sure trying to de-emphasize dll self-registration, but that is done
for one simple reasons: most dlls try to install themselves in the HKLM
registry hive. If the user is not an admin or a power user, they (obviously)
fail. The assumption is that installers know to install the dll in HKCU if
HKLM can only be accessed with the read-only priviledges.

Redemption is smart enough to do all that, plus is also includes a part that
installs the dll as an Exchange Client Extension (this is useful if your
code is in a COM add-in, but you can turn that option off in the latest
version when you customzie the dll). This is done dynamically since quite a
few pieces depend on the absolute paths of the various Outlook and Windows
directories; no installer can handle this statically.

Also note that as of Windows XP, COM libraries can be used without ever
being installed in the registry!!! All you need to do is to provide a
manifest file - see
http://www.dimastr.com/redemption/se...htm#regfreecom .

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Jeff" wrote in message
oups.com...
Dmitry Streblechenko seems to indicate that his preferred method of
installing Redemption.dll is to have it self-register. However,
self-registering as a deployment method for dlls has fallen out of
favor.

I would like to create a Windows Installer correct merge module for the
custom Redemption dll that I'm about to make that my company will use.
I would like to get all of the registry values that Redemption creates
when it self-registers, and put those keys in the Registry table of my
merge module.

Will this work in all cases?

One concern I have is that Redemption.dll could have conditional code
in its implementation of DllRegisterServer such that the registry keys
it creates vary depending on the target system's setup. Can anyone
confirm or deny this?

Also, it would be most ideal if Dmitry would create a merge module for
his Redemption dll, so that users of it would have the one and only
correct merge module that they could then integrate into their
respective Windows Installer .msi packages. Are there any plans for
such a merge module?

Thanks!
Jeff

Hey Dmitry, do you know if that reg-free com works on a per app domain basis
in .NET or only per process? Meaning, can I guarantee I won't mess with
other add ins that use Redemption if there are version differences and such?

--
Josh Einstein
Einstein Technologies
Microsoft Tablet PC MVP
Tablet Enhancements for Outlook 2.0 - Try it free for 14 days
www.tabletoutlook.com


"Dmitry Streblechenko" wrote in message
...
MS is sure trying to de-emphasize dll self-registration, but that is done
for one simple reasons: most dlls try to install themselves in the HKLM
registry hive. If the user is not an admin or a power user, they
(obviously) fail. The assumption is that installers know to install the
dll in HKCU if HKLM can only be accessed with the read-only priviledges.

Redemption is smart enough to do all that, plus is also includes a part
that installs the dll as an Exchange Client Extension (this is useful if
your code is in a COM add-in, but you can turn that option off in the
latest version when you customzie the dll). This is done dynamically since
quite a few pieces depend on the absolute paths of the various Outlook and
Windows directories; no installer can handle this statically.

Also note that as of Windows XP, COM libraries can be used without ever
being installed in the registry!!! All you need to do is to provide a
manifest file - see
http://www.dimastr.com/redemption/se...htm#regfreecom .

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Jeff" wrote in message
oups.com...
Dmitry Streblechenko seems to indicate that his preferred method of
installing Redemption.dll is to have it self-register. However,
self-registering as a deployment method for dlls has fallen out of
favor.

I would like to create a Windows Installer correct merge module for the
custom Redemption dll that I'm about to make that my company will use.
I would like to get all of the registry values that Redemption creates
when it self-registers, and put those keys in the Registry table of my
merge module.

Will this work in all cases?

One concern I have is that Redemption.dll could have conditional code
in its implementation of DllRegisterServer such that the registry keys
it creates vary depending on the target system's setup. Can anyone
confirm or deny this?

Also, it would be most ideal if Dmitry would create a merge module for
his Redemption dll, so that users of it would have the one and only
correct merge module that they could then integrate into their
respective Windows Installer .msi packages. Are there any plans for
such a merge module?

Thanks!
Jeff

Sorry nevemind I just realized you have a tool for changing the CLSID!
Brilliant!

--
Josh Einstein
Einstein Technologies
Microsoft Tablet PC MVP
Tablet Enhancements for Outlook 2.0 - Try it free for 14 days
www.tabletoutlook.com


"Dmitry Streblechenko" wrote in message
...
MS is sure trying to de-emphasize dll self-registration, but that is done
for one simple reasons: most dlls try to install themselves in the HKLM
registry hive. If the user is not an admin or a power user, they
(obviously) fail. The assumption is that installers know to install the
dll in HKCU if HKLM can only be accessed with the read-only priviledges.

Redemption is smart enough to do all that, plus is also includes a part
that installs the dll as an Exchange Client Extension (this is useful if
your code is in a COM add-in, but you can turn that option off in the
latest version when you customzie the dll). This is done dynamically since
quite a few pieces depend on the absolute paths of the various Outlook and
Windows directories; no installer can handle this statically.

Also note that as of Windows XP, COM libraries can be used without ever
being installed in the registry!!! All you need to do is to provide a
manifest file - see
http://www.dimastr.com/redemption/se...htm#regfreecom .

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Jeff" wrote in message
oups.com...
Dmitry Streblechenko seems to indicate that his preferred method of
installing Redemption.dll is to have it self-register. However,
self-registering as a deployment method for dlls has fallen out of
favor.

I would like to create a Windows Installer correct merge module for the
custom Redemption dll that I'm about to make that my company will use.
I would like to get all of the registry values that Redemption creates
when it self-registers, and put those keys in the Registry table of my
merge module.

Will this work in all cases?

One concern I have is that Redemption.dll could have conditional code
in its implementation of DllRegisterServer such that the registry keys
it creates vary depending on the target system's setup. Can anyone
confirm or deny this?

Also, it would be most ideal if Dmitry would create a merge module for
his Redemption dll, so that users of it would have the one and only
correct merge module that they could then integrate into their
respective Windows Installer .msi packages. Are there any plans for
such a merge module?

Thanks!
Jeff

And even if you don't modify the CLSIDs and class names, the manifest file
guarantess that your exe will only use the specified COM dll. No
interference.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Josh Einstein" wrote in message
...
Sorry nevemind I just realized you have a tool for changing the CLSID!
Brilliant!

--
Josh Einstein
Einstein Technologies
Microsoft Tablet PC MVP
Tablet Enhancements for Outlook 2.0 - Try it free for 14 days
www.tabletoutlook.com


"Dmitry Streblechenko" wrote in message
...
MS is sure trying to de-emphasize dll self-registration, but that is done
for one simple reasons: most dlls try to install themselves in the HKLM
registry hive. If the user is not an admin or a power user, they
(obviously) fail. The assumption is that installers know to install the
dll in HKCU if HKLM can only be accessed with the read-only priviledges.

Redemption is smart enough to do all that, plus is also includes a part
that installs the dll as an Exchange Client Extension (this is useful if
your code is in a COM add-in, but you can turn that option off in the
latest version when you customzie the dll). This is done dynamically
since quite a few pieces depend on the absolute paths of the various
Outlook and Windows directories; no installer can handle this statically.

Also note that as of Windows XP, COM libraries can be used without ever
being installed in the registry!!! All you need to do is to provide a
manifest file - see
http://www.dimastr.com/redemption/se...htm#regfreecom .

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Jeff" wrote in message
oups.com...
Dmitry Streblechenko seems to indicate that his preferred method of
installing Redemption.dll is to have it self-register. However,
self-registering as a deployment method for dlls has fallen out of
favor.

I would like to create a Windows Installer correct merge module for the
custom Redemption dll that I'm about to make that my company will use.
I would like to get all of the registry values that Redemption creates
when it self-registers, and put those keys in the Registry table of my
merge module.

Will this work in all cases?

One concern I have is that Redemption.dll could have conditional code
in its implementation of DllRegisterServer such that the registry keys
it creates vary depending on the target system's setup. Can anyone
confirm or deny this?

Also, it would be most ideal if Dmitry would create a merge module for
his Redemption dll, so that users of it would have the one and only
correct merge module that they could then integrate into their
respective Windows Installer .msi packages. Are there any plans for
such a merge module?

Thanks!
Jeff

Right but I was referring to an add in developed in .NET. The exe would be
Outlook. After more research it doesn't appear that the reg-free COM
scenario will work right on a per appdomain basis. Seems like it's just
per-process. But the custom CLSID's is a big help. I am probably gonna buy
your DLL soon.

--
Josh Einstein
Einstein Technologies
Microsoft Tablet PC MVP
Tablet Enhancements for Outlook 2.0 - Try it free for 14 days
www.tabletoutlook.com


"Dmitry Streblechenko" wrote in message
...
And even if you don't modify the CLSIDs and class names, the manifest file
guarantess that your exe will only use the specified COM dll. No
interference.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Josh Einstein" wrote in message
...
Sorry nevemind I just realized you have a tool for changing the CLSID!
Brilliant!

--
Josh Einstein
Einstein Technologies
Microsoft Tablet PC MVP
Tablet Enhancements for Outlook 2.0 - Try it free for 14 days
www.tabletoutlook.com


"Dmitry Streblechenko" wrote in message
...
MS is sure trying to de-emphasize dll self-registration, but that is
done for one simple reasons: most dlls try to install themselves in the
HKLM registry hive. If the user is not an admin or a power user, they
(obviously) fail. The assumption is that installers know to install the
dll in HKCU if HKLM can only be accessed with the read-only priviledges.

Redemption is smart enough to do all that, plus is also includes a part
that installs the dll as an Exchange Client Extension (this is useful if
your code is in a COM add-in, but you can turn that option off in the
latest version when you customzie the dll). This is done dynamically
since quite a few pieces depend on the absolute paths of the various
Outlook and Windows directories; no installer can handle this
statically.

Also note that as of Windows XP, COM libraries can be used without ever
being installed in the registry!!! All you need to do is to provide a
manifest file - see
http://www.dimastr.com/redemption/se...htm#regfreecom .

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Jeff" wrote in message
oups.com...
Dmitry Streblechenko seems to indicate that his preferred method of
installing Redemption.dll is to have it self-register. However,
self-registering as a deployment method for dlls has fallen out of
favor.

I would like to create a Windows Installer correct merge module for the
custom Redemption dll that I'm about to make that my company will use.
I would like to get all of the registry values that Redemption creates
when it self-registers, and put those keys in the Registry table of my
merge module.

Will this work in all cases?

One concern I have is that Redemption.dll could have conditional code
in its implementation of DllRegisterServer such that the registry keys
it creates vary depending on the target system's setup. Can anyone
confirm or deny this?

Also, it would be most ideal if Dmitry would create a merge module for
his Redemption dll, so that users of it would have the one and only
correct merge module that they could then integrate into their
respective Windows Installer .msi packages. Are there any plans for
such a merge module?

Thanks!
Jeff

Yes, Windows has no idea which dll a call to CoCreateInstance() comes from,
so it can only use the current process exe name (which is outlook.exe)

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Josh Einstein" wrote in message
...
Right but I was referring to an add in developed in .NET. The exe would be
Outlook. After more research it doesn't appear that the reg-free COM
scenario will work right on a per appdomain basis. Seems like it's just
per-process. But the custom CLSID's is a big help. I am probably gonna buy
your DLL soon.

--
Josh Einstein
Einstein Technologies
Microsoft Tablet PC MVP
Tablet Enhancements for Outlook 2.0 - Try it free for 14 days
www.tabletoutlook.com


"Dmitry Streblechenko" wrote in message
...
And even if you don't modify the CLSIDs and class names, the manifest
file guarantess that your exe will only use the specified COM dll. No
interference.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Josh Einstein" wrote in message
...
Sorry nevemind I just realized you have a tool for changing the CLSID!
Brilliant!

--
Josh Einstein
Einstein Technologies
Microsoft Tablet PC MVP
Tablet Enhancements for Outlook 2.0 - Try it free for 14 days
www.tabletoutlook.com


"Dmitry Streblechenko" wrote in message
...
MS is sure trying to de-emphasize dll self-registration, but that is
done for one simple reasons: most dlls try to install themselves in the
HKLM registry hive. If the user is not an admin or a power user, they
(obviously) fail. The assumption is that installers know to install the
dll in HKCU if HKLM can only be accessed with the read-only
priviledges.

Redemption is smart enough to do all that, plus is also includes a part
that installs the dll as an Exchange Client Extension (this is useful
if your code is in a COM add-in, but you can turn that option off in
the latest version when you customzie the dll). This is done
dynamically since quite a few pieces depend on the absolute paths of
the various Outlook and Windows directories; no installer can handle
this statically.

Also note that as of Windows XP, COM libraries can be used without ever
being installed in the registry!!! All you need to do is to provide a
manifest file - see
http://www.dimastr.com/redemption/se...htm#regfreecom .

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Jeff" wrote in message
oups.com...
Dmitry Streblechenko seems to indicate that his preferred method of
installing Redemption.dll is to have it self-register. However,
self-registering as a deployment method for dlls has fallen out of
favor.

I would like to create a Windows Installer correct merge module for
the
custom Redemption dll that I'm about to make that my company will use.
I would like to get all of the registry values that Redemption creates
when it self-registers, and put those keys in the Registry table of my
merge module.

Will this work in all cases?

One concern I have is that Redemption.dll could have conditional code
in its implementation of DllRegisterServer such that the registry keys
it creates vary depending on the target system's setup. Can anyone
confirm or deny this?

Also, it would be most ideal if Dmitry would create a merge module for
his Redemption dll, so that users of it would have the one and only
correct merge module that they could then integrate into their
respective Windows Installer .msi packages. Are there any plans for
such a merge module?

Thanks!
Jeff