Re: Visual Studio Installer 1.1 with COM Add-in?

Tech-Archive recommends: Fix windows errors by optimizing your registry


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]" <kenslovak@xxxxxxxx> wrote in message
news:Oye$rFnOHHA.2140@xxxxxxxxxxxxxxxxxxxxxxx
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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
Reminder Manager, Extended Reminders, Attachment Options
http://www.slovaktech.com/products.htm


"Brian McCullough" <nospammingme@xxxxxxxx> wrote in message
news:%23cjl13mOHHA.4604@xxxxxxxxxxxxxxxxxxxxxxx
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




.

Quantcast