Deploying Redemption.ll in a Windows Installer correct way

[Jeff]

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

 

[Dmitry Streblechenko]

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/security.htm#regfreecom .

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

 

[Josh Einstein]

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

 

[Josh Einstein]

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]

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]

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]

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