Using Visual Studio Installer, create an Outlook COM component that can only be installed by an admi

  • Thread starter Thread starter TC
  • Start date Start date
T

TC

Hello,

I am building a COM component that is to be used with MS Outlook on Windows
2000 and later using Office 2000 and later.

I want the installation to only work when an administrator runs the
installer and, once successfully run by the administrator, makes the
component available to all users of that machine.

Can anybody point me in the right direction?

Thanks & Regards,

TC
 
Script the installer to check the credentials of the user running the
installer.
Design the add-in to be installed to the users copy by the user from the
Add-Ins folder in programs.

The COM add-in will not be able to write to any restricted locations unless
it is Impersonating a user with rights and the launching user has the
authority to excercise those rights. Add-ins are generally restricted.

Actually - the installer should already be restricted for "Users" if it is
trying to register a COM object. You will also probably need to set the
launch rights on the COM object during install. The Office Developer
documentation describes this better than I can.
 
Jim Vierra said:
Script the installer to check the credentials of the user running the
installer.
Click to expand...

How do I script the installer from within the Visual Studio Installer? I
have not been able to find any documentation or examples of any scripting
that is available (i.e. Wise has a scripting language).
Design the add-in to be installed to the users copy by the user from the
Add-Ins folder in programs.
Click to expand...

What do you mean by "to the users copy by the user"?

I also do not see any "Add-Ins" folder except that under Outlook in the
registry.
The COM add-in will not be able to write to any restricted locations
unless it is Impersonating a user with rights and the launching user has
the authority to excercise those rights. Add-ins are generally
restricted.

Actually - the installer should already be restricted for "Users" if it is
trying to register a COM object. You will also probably need to set the
launch rights on the COM object during install. The Office Developer
documentation describes this better than I can.
Click to expand...

I have looked at the online Office Developer documentation and I have found
nothing pertaining to corporate environment distribution with exception of
digitally signing templates and add-ins.

The documentation that I was able to locate mainly focused on how to
register the object (i.e. regsvr32, etc.), how to set the loadbehavior, etc.

Where can I locate "launch rights" as it pertains to using the Visual Studio
Installer.
 
If you are using the VS installer then use the documentation for
distributing an add-in in combination with the VS Installer wizard
documentation. If you need to modify the installer "MSI" there is an MS
website with good info and the installer SDK has more.
 
Please do not post to so many groups, pick one or two.

Addins registered in the HKCU hive of the registry are "user" installations
and will only be available to that user. They also show up in the COM
Add-Ins dialog.

Addins registered in HKLM are "administrative" installations and are
available to all users. They don't show up in the COM Add-Ins dialog.

If you use a Designer and allow the COM addin DLL to self-register or allow
the installer to extract COM registration information then your addin will
end up registered in HKCU, even if you explicitly create the necessary
registry entries in HKLM in your installer. That can cause problems.

What I do when I want to create an administrative installation is to use a
class module instead of using a Designer. That way there is no
self-registration information in the DLL that points it to HKCU. I add the
Implements IDTExtensibility2 statement that usually would be in the Designer
to the class module. Then I enter the registry information for registering
the addin myself to the HKLM hive in my installation package (that's the
method you have to use for VB 5 addins of both types, VB 5 doesn't have
Designers).
 
Hey Ken,

Thanks for the detailed and elegant solution.

Sorry about posting to so many groups. They all appeared to have some
relevancy to the particular issue (i.e. Outlook vs. COM vs. AddIn vs.
Installation). I will heed your advice moving forward.

Best Regards,

Todd
 
I can provide you with a REG file that "extends" the VB6 Add-In Designer so
it allows options for registering your add-in under HKLM. What the heck, I
just include it right now: This adds entries for Word and Outlook to be
registered under HKLM. You should be able to do the same for other Office
apps. After adding these reg entries, the next time you start VB6, other
entries will show up in the drop down menus in the Add-In Designer.
---
Tom Winter
(e-mail address removed)
----------------
REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\AddIn Designer]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\AddIn Designer\Microsoft
Outlook (All Users On Local Machine)]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\AddIn Designer\Microsoft
Outlook (All Users On Local Machine)\Microsoft Outlook 9.0]
@="HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Office\\Outlook"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\AddIn Designer\Microsoft
Outlook (All Users On Local Machine)\Microsoft Outlook 9.0\LoadBehaviors]
"Load at next startup only"=dword:00000010
"Load on demand"=dword:00000009
"Startup"=dword:00000003
"None"=dword:00000000


[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\AddIn Designer\Microsoft
Word (All Users On Local Machine)]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\AddIn Designer\Microsoft
Word (All Users On Local Machine)\Microsoft Word 9.0]
@="HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Office\\Word"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\AddIn Designer\Microsoft
Word (All Users On Local Machine)\Microsoft Word 9.0\LoadBehaviors]
"Load at next startup only"=dword:00000010
"Startup"=dword:00000003
"Load on demand"=dword:00000009
"None"=dword:00000000
 
Hi, you can use the "ORCA" Tool from Plattform SDK, and after your Setup
Project from VS has created your MSI file, edit that file with orca.

Add the following Property: ALLUSERS value 1
So you have a Setup that only runs with Administrator Rights.

Regards, Helmut Obertanner
 
Back
Top