Visual Studio Installer 1.1 with COM Add-in?

[Brian McCullough]

Hello,

I am using Visual Studio Installer 1.1
(http://msdn2.microsoft.com/en-us/vstudio/aa718352.aspx) to create the .msi
for my a COM Add-in I created in VB6. Specifically this add-in is for
Outlook XP and makes use of the Outlook Redemption
(http://www.dimastr.com/redemption/) to bypass the security dialogs. The
component is built for a client and is for internal use only. It will not
be distributed as a "product". I am trying to create a msi so that it is
easily deployed/installed on user's machines within the organization.

This is my first COM Add-in and my first time using Visual Studio Installer.
A few questions...

1. In addition to the standard VB6 references (i.e. VB Runtime, OLE
Automation, etc) in my add-in VB6 project, I have references specified for
the following:
* Microsoft Add-In Designer
* Microsoft Oultook 10.0 Object library
* Microsoft Office 10.0 Object library
* Redemption Outlook Library

When I go to create my installer package with Visual Studio Installer (VSI),
it includes the following files as dependencies:
* fm20.dll (Forms Library 2.0 - needed for Add-In Designer functionality???)
* mso.dll (MicroSoft Office Libarary???)
* msoutl.olb (Outlook Type Library????)
* redemption.dll (Redemption Outlook Library)

In additon to these there are also some dependencies on some Merge Modules
(i.e. COMCAT, MSVBVM60, and OLEAUT32).

Do I want to keep all these dependencies as part of my installer? I would
think that I would want to get rid of the Office dependencies, since if my
component is to be installed, the machine will already have Office\Outlook
on it and I would not want to replace the Office\Outlook type libraries or
binaries (not to mention there are probably legal issues regarding the
inclusion of these files in an installer). Would it make sense to get rid
of the References in my VB6 project and use late binding?

2. Also, is there a way to check that Outlook XP is installed and fail the
installation if it is not? In addition a way to inform the user that the
component is only usable in Outlook XP?

3. Also, can someone please explain Merge Modules for me. I assume that
these will only execute and install if not already installed on the target
machine?

4. How would\should the fm20.dll be handled? Again, I assume I would want
to check if this is installed and only install if it isn't already
installed. Where is the appropriate location for installation? Windows
directory? or System directory? not the application directory, correct?

5. Where is the most appropriate location for the Redemption.dll? Windows
directory? System directory? Application directory? I was thinking either
Windows or System directory so that other applications/addins could use it
if they wanted, but currently, my COM Add-in is the only thing using it.
Again, just to be sure, is there a way to check that it isn't installed
somewhere before I perform installation with my msi? Want to avoid DLL
He11!!!

6. Because I made use of the designer in my COM add-in, the registry
settings needed for the add-in are only applied under HKCU, not HKLM. If I
left this as is, if multiple users used the same machine, each person would
have to run the installer, correct? What sort of effects would this have on
the existing installations for other users of the machine? Would it be
better to add additional registry keys in the installer project to add the
appropriate registry settings under HKLM for the add-in?

TIA

-Brian

 

[Ken Slovak - [MVP - Outlook]]

I'd only keep Redemption of what you mentioned. All the other things are
there if the user has Office 2000 or later installed and Window 98SE or
later. If you use any controls such as tabctl.ocx or things like that you
might need to install them too.

I usually place Redemption in c:\program files\common files\slovaktech\. I
also use a customized version of Redemption, both for security and for
avoiding DLL hell.

You can add the HKLM keys to the designer. Use the Advanced tab of the
designer and add the key and values there.

Use the references, late binding is slower and doesn't let you handle
events. Just don't include those dependencies. Merge modules are MSM files,
specially prepared to be installed by Windows Installer as part of a
package.

The Forms 2.0 package will be there if Outlook is installed.

You would have to write a custom installer action to check the registry for
Outlook being installed and its installation path. Then you can use that to
check the version of Outlook. I'm not sure if that rather basic installer
lets you write custom actions.

 

[Brian McCullough]

Hey Ken!

Didn't post to our other thread since we strayed a bunch from the original
topic and also because I remember you saying you normally use InstallShield
for your setups.

Is there a standard or "best practice" location for installing Add-Ins? I
was thinking "<Program Files>\Office Add-ins\Outlook\MyAddinName". In
addition I was thinking of putting the redemption.dll into a "<Program
Files>\Office Add-ins\Shared" folder. Thoughts?

Also, if I use the Advanced tab in the designer to add it to HKLM, will it
also create the settings for HKCU? Are there ramifications\issues of having
the keys in both locations? Is there a way in the designer to only get it
to put the settings in HKLM?

In reference to the Merge Modules, was I correct in stating that they "will
only execute and install if not already installed on the target
machine"??

Thanks once again!!

-Brian

 

[Brian McCullough]

I tried setting the properties on the Advanced tab of the designer, but I
got an error when I built my project informing me that the DLL couldn't be
loaded. Here is what I did:

In the "Registry Key for Additional Addin Data" field I used the value
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Outlook\Addins\MyAddinName.Connect"

Then I entered the four required items under the "Addin Specific Data" area
as follows:

CommandLineSafe, DWORD, 0
Description, String, "My description here."
Description, String, "Name Here"
LoadBehavior, DWORD, 3

I checked my registry using regedit and found that only the first three
entries got written to the registry. I also noticed that the
CommandLineSafe key has a value of "d" rather than 0 as I specified.

Do I need to enter a hex value or something in the value for both the DWORD
items (i.e. CommandLineSafe and LoadBehavior)? Are there tricks to this?
Where is the LoadBehavior key??

Thanks!!

Brian

 

[Brian McCullough]

For the Redemption setup, I plan on keeping everything as it is when it is
downloaded, for now anyway

What is the "best practice" for setting up the installation of Redemption
assuming I am not going to change the dll name or anything (using Visual
Studio Installer)? Should I set it's Register property to "1 -
vsifrSelfReg"? Should I set the redemption component to be "Isolated" by
setting it's Isolate To property?

Is there any documentation available for Visual Studio Installer 1.1? I
cannot find any, and all I have to work with are a few online articles and
an old VB6 book.

TIA

 

[Ken Slovak - [MVP - Outlook]]

Some of the stuff listed as dependencies should not be distributed for
licensing and legal reasons. The Outlook and Office libraries and Forms 2.0
all fit that. I think the addin designer also does. In addition to
licensing, they bloat your deployment. Things such as the VB runtime are
there, again that just bloats your installation.

Redemption should be marked as self-registering.

You really should customize Redemption. The distributable package includes a
Customize.exe app that's used for that. Customizing it allows you to set up
an AuthKey that limits access to Redemption and provides security against it
being hijacked by viruses and scripts. You should never use AuthKey without
customizing, that would break any other app that used a non-customized
Redemption. When you customize you give your own names to the restricted
methods and objects and generate new CLSID's for those objects. That makes
for excellent security.

I have no idea what Isolate To is.

I've never seen much documentation about that free installer, but the last
time I looked for any was before 2001, so that's a long time ago.
Information about Orca is at http://support.microsoft.com/kb/255905. The
MSDN November 2001 Library might be the last one that has information on
that installer. After that MSDN went mostly .NET in its information.

You might have some luck with information in one of the Windows installer
newsgroups, possibly. Again, I use InstallShield myself, so I never pursued
working with the free software very much.

 

[Ken Slovak - [MVP - Outlook]]

In my experience most installations use a company name subfolder under
Program Files and then create anything under that they need.

I'm not all that familiar with what controls whether or not an MSM installs,
so I can't answer that.

In general it's best not to have an addin registered in both HKLM and HKCU.
Designers are designed to register in HKCU. If you add HKLM keys to it you
get both AFAIK. In those cases I use a public class module instead of a
designer, implement IDTExtensibility2 in the class and rely on registry
settings I create in InstallShield to register in HKLM. I don't know if you
can do that using the installer you're using.

I did see some things in a google search about problems with designers and
HKLM, some suggestions were to modify the public registration interfaces of
the addin DLL, you can find that information if you want to play with that.

 

[Ken Slovak - [MVP - Outlook]]

When you enter a value you set it as a String or DWORD value, 0 and 3 are
the same in hex or decimal. I have no idea why a 0 is becoming a "d".