Outlook add-in is inactive


  • I have create an outlook 2007 add-in with VS2005 and vstor.  I followed the directions for deploying a vs2005 solution.  When I try the solution as a regular user the add-in is always inactive.  As an administrator it works find.  I tried using the

    environmental variable  VSTO_SUPPRESSDISPLAYALERTS, using both 0 and 1 but didn't get any message or log entries.  I believe the problem is with the trust but I am using the setsecurity project mentioned in the deployment instructions.  I have even created the trust using the stand alone utility caspol with the following options:

    C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\caspol -q -m -ag All_Code -url "C:\PROGRAM FILES\DSET\*" FullTrust but norhting works. Help


    Monday, June 23, 2008 9:01 PM


All replies


    Hello _enigma,


    VSTO solutions working on a per user installation base.

    So I have a few questions:


    What OS are you using?

    If Vista: is UAC turned on/off?

    Under what user account do you installed the AddIn?


    What are the registry entries under HKCU\Office12\OUtlook\AddIns\YourAddIn for the normal user account?


    Greets, Helmut

    Tuesday, June 24, 2008 5:04 AM
  • Right now I am testing with XP so UAC is not an issue.  My Outlook Addins key is:


    "Description"="DSET -- an addin created with VSTO technology"
    "Manifest"="CStick out tonguerogram Files\DSET\DSET.dll.manifest"


    Maybe I outsmarted myself but here is the rest of the story ad Hal Lindsey would say.  I install my Addin as an administrator for USER A. but other users may want to use the same machine so I created a program that runs when a user logs in to create the Registry keys the second user needs for the Addin.  If the second user is an admin everything works fine.  If the second user is a regular user the add becomes inactive and the LoadBehavior in the registry is changed to 2.  I checked the permissions on the Keys and the User has full comtrol.  If after the second user creates the HKCU keys I make him a regular user the addin goes inactive. 


    The other keys I create are:




    I can't figure out why the addin will not load.




    Tuesday, June 24, 2008 1:40 PM
  • You could try to follow Misha's blog entry which is an unsupported hack, but good enough to try. 



    He's written the instructions in 3 parts, and here is the latest link:




    Tuesday, June 24, 2008 11:19 PM
  • I tried Mish's blog entries 1 and 2 without success, It was what gave me my idea to create the keys myself.  Part3 looks like it is for VS 2008 which I don't have. 


    Wednesday, June 25, 2008 12:26 AM

    This morning I decided to try and install my add-in with group policy so I installed all the prerequisites and created a group policy to assign the MSI file at logon.  The results were the same:   If the user had admin privileges everything worked fine.  A regular user caused the add-in to go inactive and the LoadBehavior changed from 3 to 2.  How can I tell what is making the add-in go inactive and why it will not load as a regular user?

    Wednesday, June 25, 2008 1:22 PM
  • Are you installing the .NET Framework as admin via group policy, then later trying to install the addin as normal user?  The .NET Framework requires admin.  There's no way to get around the Framework requirement. 


    Wednesday, June 25, 2008 5:51 PM
  • No,   I installed all the prerequisites on the local machine and  only installed the MSI with group policy.
    Wednesday, June 25, 2008 6:50 PM
  • Hm, I'm trying to figure out what's going on.  You say you're using VSTO 2005 and Outlook 2007, so I'm thinking that you're actually using VSTO 2005 SE and the SE Runtime, correct?


    Next thing I want to confirm is that you set Full Trust on your solution using CASPOL, correct?


    Then I want to confirm that you're deploying to a different machine that the one you used to develop and debug the solution, correct?



    You install your MSI via Group Policy when the user is an Admin = the addin works, good.

    You install your MSI via Group Policy when the user is a normal user = the addin gets set to inactive.


    Do I understand the situation correctly?

    Wednesday, June 25, 2008 7:21 PM
  • Additionally are you using the SetSecurity custom action provided along with the whitepaper.

    If so what is the value for [AllUsers] that you are passing it?


    It should be per user instead of all users since you are going to be calling the msi for each user.




    Wednesday, June 25, 2008 7:36 PM
  • Yes you understand the situation correctly.  I would like to know how to  find  what the add-in doesn't like.  I am seeing no loging or error messages and the environmental variable VSTO_SUPPRESSDISPLAYALERTS didn't display or log anything.

    Wednesday, June 25, 2008 7:41 PM
  • I am using /allUsers=[ALLUSERS].


    Wednesday, June 25, 2008 7:45 PM
  • "

    A value that specifies whether the policy is created at the machine level (value = "1") or user level (value = ""). You can use the [ALLUSERS] installation macro defined at install time from the Windows Installer.



    What is the [allusers] macro set to while invoking the install? Would it be possible to try and set the value to nothing ""



    Wednesday, June 25, 2008 8:35 PM