Deploying your VSTO Add-In to All Users (Part II) 原版英文及问题解答

来源:互联网 发布:淘宝店铺网址怎么看 编辑:程序博客网 时间:2024/05/21 00:20

In this post I am going to discuss how the observations made in the previous postcan be incorporated into a setup project for Office 2007 Add-Ins. Aswith any setup we will need to address installation, un-installationand repair procedures.

  • Upon the installation of Add-In we will write registry keys thatare similar to what testpropagation_create.reg file from the previouspost contained. This installation will contain the Create instructiontelling Office propagation mechanism to copy the registry key into HKCUprofile.
  • During the uninstall, we will replace the Create instructionwith Delete instruction which will cause Office to delete thecorresponding registry key in HKCU hive. We will also bump up Countregistry value to tell Office that the instruction needs to be carriedout.
  • During the repair we will need to increase Count value. Thiswill cause Office to copy over the registry values from HKLM into HKCU.

Let’s first take care of the installation of the required registrykeys. The easiest way to achieve this is by slightly modifying thedefault setup project that is created alongside the regular VSTO 2005SE project. Let’s create a new Excel 2007 Add-In called “MyAddIn”. Youwill notice that in addition VSTO has also created a companionMyAddInSetup project. Let’s open the Registry view and clearout all the registry entries that have been created for you (i.e.completely clear the contents under HKEY_CURRENT_USER). Now we aregoing to import the registry information as presented below. To achievethis you will need to copy the below lines into a .reg file, thenright-click on “Registry on Target Machine” node, select “Import …” andimport the .reg file you have just created (notice that first you mightwant to adjust the highlighted strings for your particular situation).

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Office/12.0/User Settings/MyCompany.MyAddIn/Create/Software/Microsoft/Office/Excel/Addins/MyCompany.MyAddIn]

"Description"="MyAddIn -- an addin created with VSTO technology"
"Manifest"="[TARGETDIR]MyAddIn.dll.manifest"
"FriendlyName"="MyAddIn"
"LoadBehavior"=dword:00000003
"CommandLineSafe"=dword:00000001

After you complete this operation your Registry View should be very similar to this screenshot :  

image

By adding above entries into Registry View we ensure thatcorresponding keys will be removed when Add-In is uninstalled. I wouldalso suggest to set Create's key “DeleteOnUninstall” property in the Properties Window to True to make sure it is always deleted on uninstall .

Notice that now we need to add a Count value under the MyCompany.MyAddInkey. Using the Registry View to add this value would not work becauseany registry keys and values added through this view will be removed onuninstall. On opposite, we need Count value not just stay when Add-Inis uninstalled, but its value should be incremented.

To achieve the desired effect we will create a Custom Actionthat will add Count value or, in case it already exists, we will simplyincrement its value.

Similarly, Custom Action will create a "Delete" instruction when Add-In is uninstalled.

Below I am showing code that Darryn Lavery (who put tremendousamount of effort to design and validate all I am talking about rightnow) has already written for his future MSDN article on this (yeah,there will be an MSDN article with the full how-to instructions) and hekindly shared it with me and I shamelessly sharing it you, but creditsitll belongs with Darryn.

Now let's move close and see how the particular Custom Action code could look like. First, let's start defining a class RegisterOffice2007AddIn with a couple of private methods:

class RegisterOffice2007AddIn {

 

    #region private methods

 

    private const string userSettingsLocation = @"Software/Microsoft/Office/12.0/User Settings";

 

    public void IncrementCounter(RegistryKey instructionKey) {

        int count = 1;

        object value = instructionKey.GetValue("Count");

 

        if (value != null) {

            if ((int)value != Int32.MaxValue)

                count = (int)value + 1;

        }

 

        instructionKey.SetValue("Count", count);

    }

 

    private string GetApplicationPath(string applicationName) {

 

        switch (applicationName.ToLower()) {

            case "excel":

                return @"Software/Microsoft/Office/Excel/Addins/";

            case "infopath":

                return @"Software/Microsoft/Office/InfoPath/Addins/";

            case "outlook":

                return @"Software/Microsoft/Office/Outlook/Addins/";

            case "powerpoint":

                return @"Software/Microsoft/Office/PowerPoint/Addins/";

            case "word":

                return @"Software/Microsoft/Office/Word/Addins/";

            case "visio":

                return @"Software/Microsoft/Visio/Addins/";

            case "project":

                return @"Software/Microsoft/Office/MS Project/Addins/";

            default:

                throw new Exception(applicationName + " is not a supported application", null);

        }

    }

 

    # endregion

 

The code above contains helper method IncrementCounter that is responsible for correctly updating the Count registry value. GetApplicationPathhelper method returns application-specific path Add-Ins registrationkey. Now, we are ready to move to the top-level function that will becalled during Install and Repair:

 

public void RegisterAddIn(string addInName) {

    RegistryKey userSettingsKey = null;

    RegistryKey instructionKey = null;

 

    try {

        userSettingsKey = Registry.LocalMachine.OpenSubKey(userSettingsLocation, true);

 

        if (userSettingsKey == null) {

            throw new Exception("Internal error: Office User Settings key does not exist", null);

        }

 

        instructionKey = userSettingsKey.OpenSubKey(addInName, true);

 

        if (instructionKey == null) {

            instructionKey = userSettingsKey.CreateSubKey(addInName);

        } else {

            // Remove the Delete instruction

            try {

                instructionKey.DeleteSubKeyTree("DELETE");

            } catch (ArgumentException) { } // Delete instruction did not exist but that is ok.

        }

 

        IncrementCounter(instructionKey);

    } finally {

        if (instructionKey != null)

            instructionKey.Close();

        if (userSettingsKey != null)

            userSettingsKey.Close();

    }

}

In the above method, we first make sure the "Delete" instruction isgone and then we increment the Counter value. Notice that "Create"instruction is not explicitly installed by the Custom Action - this ishandled by the installer automatically because of our previous workwith the Register View.

And, finally, the function that will be called during uninstall:

public void UnRegisterAddIn(string applicationName, string addInName) {

    RegistryKey userSettingsKey = null;

    RegistryKey instructionKey = null;

    RegistryKey deleteKey = null;

 

    try {

        userSettingsKey = Registry.LocalMachine.OpenSubKey(userSettingsLocation, true);

 

        if (userSettingsKey == null) {

            throw new Exception("Internal error: Office User Settings key does not exist", null);

        }

 

        instructionKey = userSettingsKey.OpenSubKey(addInName, true);

 

        if (instructionKey == null) {

            instructionKey = userSettingsKey.CreateSubKey(addInName);

        } else {

            // Make sure there is no Create instruction

            try {

                instructionKey.DeleteSubKeyTree("CREATE");

            } catch (ArgumentException) { } // Create instruction did not exist but that is ok.

        }

 

        string instructionString =

                        @"DELETE/" +

                        GetApplicationPath(applicationName) +

                        @"/" +

                        addInName;

 

        deleteKey = instructionKey.CreateSubKey(instructionString);

 

        IncrementCounter(instructionKey);

    } finally {

        if (deleteKey != null)

            deleteKey.Close();

        if (instructionKey != null)

            instructionKey.Close();

        if (userSettingsKey != null)

            userSettingsKey.Close();

    }

}

This is pretty much it. Assuming you havealready experimented with SetSecurity Custom Action you should be ableto wrap this code into a Custom Action DLL, set CustomActionDataproperties as /addinName="MyCompany.MyAddIn" /application="Excel" (againchoose the value that fit your particular case), and invoke the abovemethods on Install, Uninstall and Rollback. I will try to sum it all upin another post though.

Posted: Wednesday, September 05, 2007 11:01 PMbyMisha Shneerson
Filed under: Deployment

Comments

MSDN Blog Postings » Deploying your VSTO Add-In to All Users (Part II) said:

PingBack from http://msdnrss.thecoderblogs.com/2007/09/06/deploying-your-vsto-add-in-to-all-users-part-ii/

# September 6, 2007 5:16 AM

Ken McCormack said:

Hi Misha

Can you recap on the reasoning behind the steps?

1. Create a reg file to add the master key

2. Add a custom action to increment / decrement the Count - this causes the already installed key to refresh on install / repair

Can I create the reg key within the setup program, rather than using a reg file?

Thanks

Ken

# September 12, 2007 3:09 AM

Misha Shneerson said:

Ken,

Re 1: Why "create a reg file to add the master key"

  There is no particular reason besides my preference. I could havesaid "go and add this key and these values through the designer", butfor some reason I just felt it might be simplier for everyone if I said"copy&past these values, modify them and import them into yourproject", this is especially true because copying from an existingscript make it much harder to miss things.

Re 2: Why "Add a custom action to increment / decrement the Count -this causes the already installed key to refresh on install / repair"

  Office compares HKLM's Count value against one stored underHKCU/.../Office/12.0/User Settings/<MyAddin>. The instructionswill be carried out only if those values are different, then Officecopies the new Count under HKCU/.../Office/12.0/UserSettings/<MyAddin> as a form of optimization to avoid carryingthe same copy/delete instruction on every boot. Hence, Count valueneeds to stay even after add-in is uninstalled. When a registry valueis authored through MSI tables - it will be cleaned up during theuninstall and the only way to achieve the desired behavior is to writea Custom Action that will managed the Count value.

Why some registry keys are added through Registry View and others are added/modified by Custom Action?

My approach has been:

1. The registry keys managed by the MSI tables are those that needto be added during installation/repair and removed during uninstall.

2. The registry keys managed by the Custom Actions are those thatWindows Installer rules install/uninstall rules can not be applied to.

You can do things differently, of course, and have your Custom Action managed all your registry keys instead.

# September 12, 2007 1:39 PM

Jie said:

A Simplified Chinese version of this aritcle: http://blog.joycode.com/vsto/archive/2007/09/16/108546.aspx

Xie Xie Misha! :)

感谢 Misha 允许我把此文翻译成中文。

# September 16, 2007 11:15 AM

George said:

Hi Misha,

Can you please explain what 'Properties Window' you meant in the following paragraph:

By adding above entries into Registry View we ensure thatcorresponding keys will be removed when Add-In is uninstalled. I wouldalso suggest to set Create's key “DeleteOnUninstall” property in theProperties Window to True to make sure it is always deleted onuninstall.

Thanks,

George.

# September 20, 2007 3:45 PM

Misha Shneerson said:

Oh,I just meant the "Properties" Window - the one that shows and allowsbrowsing properties of the currently selected object. In the RegistryView, you can right click on the reg key, select "Properties Window"and it will show a little window where one of the things you can modifyis "DeleteOnUninstall". On my machine the window shows up in the rightlower corner of the VS IDE.

# September 21, 2007 1:59 AM

Ignacio said:

Hi Misha,

I'am deploying my own vsto application and I'am trying to give theoption to choose the kind of installation for the current user or allthe user. Now Im trying to use a variable in the condition property ofthe key but it did't work. What can I do?

Thanks,

Ignacio.

# September 27, 2007 5:37 PM

Misha Shneerson said:

Ignacio,

First, you would need to undersand why it did not work. WindowsInstaller has some logging capabilities that might help you out - checkout the command line options for msiexec.

# September 27, 2007 6:06 PM

Kulvinder said:

Hi Misha,

For Windows Vista 64 bit (if elevated security i think), Outlook2007 doesnt load addins created having details under HKCU. The registryinformation (under Software) has to be under HKLM.

Can you write something on Vista 64 Bit and Outlook 2007 ?

Thanks

# October 2, 2007 8:55 AM

Shawn Mullen said:

Automaticupdates are great.  I wished it actually worked.  Has anyone addressedthe fact that most companies do not allow their users to download dllsover http.  If there is a solution to this using VSTO 2005 SE, pleaselet me know, but as far as I can see there isn't one.  So, I now haveto use a third party updater to make this work (I don't feel likewriting my own).  

# October 4, 2007 12:38 PM

BJ Herrington said:

Asimpler way to handle this, especially if your add-in is build for 2003and later, is to simply not include the "Manifest" key in the registry. This will cause Office to use the AddinLoader shim.  The downsidebeing that you no longer have the "native" support in 2007, but you dosimplify your installer and the maintenance there of.

# October 15, 2007 5:27 PM

Misha Shneerson said:

BJ,

You are correct - but only half way. Only pure managed add-ins havesupport for some of the Office 2007 features such as CustomTaskPanesand Ribbons. Once you start using these VSTO features you really needthis "Manifest" reg value.

# October 15, 2007 7:13 PM

Markus Jerneborg said:

Thank you for a good post Misha. It helped me tons.

# October 23, 2007 12:06 PM

Jason said:

There are one problem.

Regist Addin like that cause a question, when Office2003 started, it also load this addin.

How Can I Fix it?

Thanks

# November 12, 2007 1:12 AM

Misha Shneerson said:

Jason,

I am sorry. I tried to understand your question but I could notfigure out what you are trying to say. Can you rephrase what is theproblem you are seeing?

# November 12, 2007 1:52 PM

We did start the fire (sorry Billy)

said:

Eine wesentliche Limitierung von managed Office 2007 Add-Ins ist die Beschränkung auf eine per-User -

# November 27, 2007 5:43 AM

Noticias externas said:

Eine wesentliche Limitierung von managed Office 2007 Add-Ins ist die Beschränkung auf eine per-User

# November 27, 2007 6:44 AM

Christopher Painter said:

Ihave the Create/Delete command pattern down.  And on the surfaceeverything works.   But I notice several problems:  ( this is a VSTO2008 .vsto not VSTO 2005 .manifest )

1) The first time a user starts word it asks them if the want toinstall the add-in.  If they click yes everything is fine.  If theyclick no, they are never asked again.   The only way to get it to askthem again is tweak the HKLM Count value to cause it to be repropagatedto HKCU for Winword to see again.

2) When they click yes:

a)  registry entries get created by vstoinstaller inHKCU/Software/Microsoft/VSTA and VSTO keys.   They are guids anddifferent everything it runs.  I'm not sure what drives this.

b) an entry is added to add/remove programs for the user. ( undesired )

3) when I uninstall the application the delete key properly removesthe addin the next time word is run but the VSTA, VSTO and Add/Removeresources linger on the machine.

4) I've not tested upgrade scenarios yet.

# January 26, 2008 5:29 PM

Joe said:

Hey Misha,

That may look irrelevant, but I have a vista machine with OL2007,and I'm installing a VSTO setup for OL2007 and I have serious troublesreading and writing to registry. I'm using pretty much straight forwardcommands like:

Registry.SetValue() and Registry.GetValue()

I event tried Registry.LocalMachine.CreateSubKey() and none seems to be working so I realized that is an issue with vista.

Please let me know what do I have to do with vista machines that runs OL2007?

Thank you!

Joe

# January 29, 2008 9:52 AM

Misha Shneerson said:

Hi Joe, I think Chrispoher has covered it in his response here - http://blogs.msdn.com/mshneer/archive/2007/09/04/deploying-your-vsto-add-in-to-all-users-part-i.aspx#7308281

# January 29, 2008 5:05 PM

Gábor Vas said:

Cristopher Painter:

When the manifests are signed with a certificate from the TrustedPublishers certificate store, and that certificate is certifieddirectly or indirectly with a certificate from the Trusted RootCertificate Authorities certificate store, then ClickOnce won't ask theusers for trust.

Regarding your other problem, with Office 2007 and VSTO 3.0 you canprevent the installation into the ClickOnce cache by appending the|vstolocal suffix to the path of the deployment manifest (at theManifest registry key). This means that there won't be any entry in theadd/remove programs for the add-in. See the following forum thread fordetails: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2543533&SiteID=1

# February 19, 2008 8:56 PM

Visual Studio 2008: Microsoft Visual Studio Tools for Office said:

There are many resources to learn about Visual Studio Tools for Office, and they are scattered through

# February 22, 2008 11:19 AM

Mohan Kumar K said:

Ihave created an addin for Word 2007 using VSTO SE and I am trying todeploy it for All Users. I find your article very useful and it helpedme to know what exactly I am missing. But the problem is I am new to.Net & very new to C#.  I couldn't understand certain things andneed your help to figure out.

I have created a class named "RegisterOffice2007AddIn.cs" in SetSecurity Project and copied the code to that class.

class RegisterOffice2007AddIn

{

#region private methods

....

..

# endregion

}

I would like to know where the below mentioned function will go intothat "RegisterOffice2007AddIn.cs". (I mean where exactly we need tocopy this code, excuse me if this question is too naive).

public void RegisterAddIn(string addInName)

public void UnRegisterAddIn(string applicationName, string addInName)

==============================

This is pretty much it. Assuming you have already experimented withSetSecurity Custom Action you should be able to wrap this code into aCustom Action DLL, set CustomActionData properties as/addinName="MyCompany.MyAddIn" /application="Excel" (again choose thevalue that fit your particular case), and invoke the above methods onInstall, Uninstall and Rollback. I will try to sum it all up in anotherpost though.

Do we need to create new set of custom actions or can we replace theexisting one created for SetSecurity project. Is there any other postwhich will provide more elaborate details on this.

Any help would be much appreciated.

Thanks,

Mohan

# February 26, 2008 11:15 PM

Misha Shneerson said:

Mohan,

if you look carefully at the SetSecurity sample project you cannotice that SetSecurity class actually derives fromSystem.Configuration.Install.Installer class and overrides its Install,Rollback and Uninstall methods. These are the methods that WindowsInstaller is actually calling - they in turn extract the parameters andcall the worker method - SetSecurity. You just need to follow the samepattern here. Hope this helps.

# February 26, 2008 11:52 PM

Mohan Kumar K said:

Misha,

I would like to know where the below mentioned function will go intothat "RegisterOffice2007AddIn.cs". (I mean where exactly we need tocopy this code, excuse me if this question is too naive).

public void RegisterAddIn(string addInName)

public void UnRegisterAddIn(string applicationName, string addInName)

Thanks,

Mohan

# February 27, 2008 2:05 AM

Ricky said:

Hi Misha,

I've processed every step of your tutorial and it works to deploy myPowerPoint-Add-In to every user on the target machine, but there isstill a problem with some Code Access Security-Stuff I think. If Ilogin as another user on the target machine and start PowerPoint I geta popup that says "Der angeforderte Registrierungszugriff istunzulässig." (must be the message "Requested registry access notallowed" in english).

I also added the SetSecurity Project to my Add-In and added cutomdefined actions with correct parameters. After the installation of theadd-in, i have my code groups on machine-level which give the add-infull trust. What else could be wrong? Do you have any idea?

Thanks a lot and best wishes!

Ricky

# March 28, 2008 12:55 PM

Misha Shneerson said:

Idoubt the problem it registry CAS related - probably some piece of thesoftware tries to acces the registry and fails. I would suggest you torun regmon from www.sysinternals.com and check which registry entriesthe process tries to access. Probably this will give you some idea.

# March 28, 2008 1:17 PM

Ricky said:

It'sa piece of my code in the add-in which tries to read a value fromregistry. I also have a version of that add-in-code for PPT2003 whichis identically with it for 2007 except for the steps to install for allusers. in PPT2003 all works fine.

# March 28, 2008 1:34 PM

Ricky said:

Hi again!

I solved my problem now by using this code to grant access to the registry-entry:

                   RegistryPermission readPerm1 = newRegistryPermission(RegistryPermissionAccess.Read,@"HKEY_LOCAL_MACHINE/SOFTWARE/ProductName");

                   readPerm1.Assert();

                   RegistryKey OurKey = Registry.LocalMachine;

                   OurKey =OurKey.OpenSubKey(@"SOFTWARE/ProductName",RegistryKeyPermissionCheck.Default, RegistryRights.ReadKey);                   

                   pathtoexe = (OurKey.GetValue("Path2exe").ToString());

                   clientApplicationProcessName = "PPT2Go";

                   OurKey.Close();

                   OurKey = null;

Best wishes!

Ricky

# March 31, 2008 11:46 AM

Lily Collins said:

Dear Misha,

Is this the approach you would use if installing an VSTO SE Outlook2007 add-in to a Citrix server?  I have an Outlook 2007 add-in that Iam able to install without issue to individual users but the add-inwon't load with Citrix.

Any insight you have with Citrix would be really helpful.  I havebeen requested to update the HKLM registry but my understanding is thatany settings here are ignored for VSTO SE add-ins.

# April 8, 2008 9:36 AM

Misha Shneerson said:

Lily,

Unfortunately I have no idea what Citrix server is. If you want toprovide more details please contact me offline - use the email link atthe top of this page.

# April 8, 2008 12:48 PM

Inder said:

Hi Misha,

I read your post saying that " Office 2003 does not have a nativenotion of managed add-ins. So all COM add-ins (even VSTO add-ins forOffice 2003) can be registered under HKLM hive (e.g.HKLM/Software/Microsoft/Office/Excel/AddIns/MyAdd) which will work formachine-wide deployment - and this is how machine wide deployment ofadd-ins has been done in the past."

I tried this in office 2003 and created all registry entries underHKLM. My setup creates all required registry entries but the addindoesnt get loaded. And i am not talking about CAS yet, it doesnt evenshow in com addins list in word 2003.

Does VSTO SE Addin loader ignores HKLM? How do we do machine wide addin deployment on office 2003 for addins built with VSTO SE.

# April 15, 2008 7:04 PM

Misha Shneerson said:

Office2003 does not display HKLM registered add-ins in COM add-ins dialog.So, the fact that these do not show up does not indicate they HKLMadd-ins did not load. Typically, to deploy to HKLM on Office 2003 - Iwould just move all the registry keys from HKCU to HKLM and modify theSetSecurity to run caspol for machine level policy.

What happens under the cover?

VSTO SE AddIn loader is implemented by AddinLoader.dll - this is anative DLL that knows how to handle instantiation of VSTO add-ins as ifthose were regular COM objects. Hint: to check whether Office 2003picked up your addin you can check whether AddinLoader.dll has beenloaded (use process explorer from sysinternals.com or just a regularnative debugger to see which modules are loaded). When AddInLoader.dllis loaded into the process it has no idea whether it was registeredfrom HKLM or HKCU. Instead, the only information it gets is the GUID ofthe COM Add-In. Given this information it always tries to find the.manifest file (which has information about assemblies that need to beloaded) by combinining the ManifestLocation and ManifestName registryvalues from HKCR/CLSID/{-- GUID ---}/InProcServer32. Note that HKCR isnot a real registry hive - instead it is just a virtual merge ofHKLM/Software/Classes and HKCU/Software/Clases.

Once .manifest file is found - AddInloader would try and load the assemblies specified in the manifest.

From this point on the loading failures can be seen using VSTO_SUPPRESSDISPLAYALERTS environment variable.

As you can see there are multiple points of failure that can resultfrom incorrect registration and you really need to follow the entirechain to understand what might be going on in your case. Additionalpoints of failure are: add-in might have been soft-disabled -LoadBehavior was reset to 2, add-in might have been killed and havebeen hard-disabled - check the Help->About -> Disabled Items ....

If you have further questions to do hesitate to contact me using the email link at the top right corner of this page.

# April 15, 2008 7:58 PM

Angledor said:

Hi,

Thanks a lot for this article, it will be very useful for me.

But I have a problem with uninstallation:

The value 'Count' under my Key 'MyCompany.MyAddIn' is automatically removed after the uninstall!

So uninstall of User registry Key is not done.

- ONLY the Create's key is set to “DeleteOnUninstall” in msi

- In the CustomAction there is always 2 values  (Count and Order)

But when I play the same code after uninstall, there is no value anymore!!!

This is the code to test if the 2 values are always there:

       RegistryKey userSettingsKey = null;

       RegistryKey instructionKey = null;

       private const string userSettingsLocation = @"Software/Microsoft/Office/12.0/User Settings";

       private const string addInName = @"Firmenich Outlook Sender Addin";

           userSettingsKey = Registry.LocalMachine.OpenSubKey(userSettingsLocation, true);

           instructionKey = userSettingsKey.OpenSubKey(addInName, true);

           Console.WriteLine(string.Format("Value Count of/n/"{0}//{1}/" = {2}", userSettingsLocation, addInName,instructionKey.ValueCount));

Do you have an idea of what's happened to delete those Value in registry just after uninstall??

This is a mystery for me.

Thanks

# April 24, 2008 4:17 AM

Misha Shneerson said:

This post is both the continuation of part I and part II installments but it also addresses new product

# April 24, 2008 7:17 PM

See what I see. said:

I got ahead of myself and thought it was one week later than it really is (sort of good because I was

# April 29, 2008 9:18 PM

Phillip said:

HiMisha, thanks for the article. I created the propagation keys underHKLM like in the article, and they appear to be creating the HKCU keyscorrectly. Despite this, my add in is still only appearing on the useraccount that I used while installing it. It doesn't show up on anyother user accounts.

Is there something that lists everything that is needed for anadd-in to load in Outlook? I am looking for something that lists allregistry keys, file locations, etc. This will let me look and see whymy add in isn't loading for all users.

Thanks,

P

# May 2, 2008 10:11 AM

Misha Shneerson said:

Hi Phillip,

Most probably cause is that your SetSecurity Custom Action modifiesCAS policy at the user level - for all users deployment make sure theassemblies are trusted at the machine level.

# May 2, 2008 12:50 PM

Phillip said:

HiMisha, thanks for the quick response. I double-checked my CAS policycode and the actual CAS policy on this machine. Everything is set atthe machine level. The addin has its own code group at the machinelevel with full trust for everything under the addin's directory. Isthere something else that I can check?

thanks,

P

# May 2, 2008 2:18 PM

Misha Shneerson said:

Phillip, can you contact me offline about this - use email link at the top of this page

# May 2, 2008 2:29 PM

Open XML, VSTO, Deployment, .NET und anderes said:

Das Office 2007 Security Modell erlaubt es nicht, unter HKLM registrierte Managed Add-Ins zu verwenden.

# May 9, 2008 10:20 AM

Andrew Coates ::: MSFT said:

While the default mechanism for deploying VSTO v3 Add-Ins is ClickOnce, there there's now also a documented

# May 15, 2008 10:04 PM

Rajesh said:

This is for Outlook 2003 Addin developed using VSTO 2005.

I have similar but not the exact problem. I am trying to deploy anoutlook addin in Citrix. My setup project applies custom securitypolicies for all users and my registry entries are for HKLM. Even so,when I deploy my addin, it is only visible for the user who installedit - no other users can see the toolbar button this addin provides. Ichecked to see if the addin was blocked - it is not listed in the COMAddin list.

Any suggestions

# June 6, 2008 9:12 AM

Misha Shneerson said:

Rajesh,

If things are the way you say they are - then there should be noproblem, Citrix or not, all users on the machine should be seeing thisaddin.

Get it touch with me through email link at the top of this page andI can take a quick look at your setup to see whether there is anyproblem with it.

# June 6, 2008 12:53 PM

Paul said:

Has Darryn Lavery created his "MSDN article with the full how-to instructions" yet? Thank you.

# June 8, 2008 9:27 PM

Misha Shneerson said:

Paul, unfortunately MSDN article did not happen. Since then Darryn decided to move on and other things took precedence for him.

# June 9, 2008 2:29 AM

Paul said:

Thankyou for your response. It is a shame that the article will not bewritten. Oh well. I have very little experience writing custom actions,so I have a couple of questions regarding the steps you outlined above:Where exactly should the three blocks of code mentioned in this blog bewritten, in a class in the same project that includes the add-in class?Or should the code be written in a class library, and then theresulting dll be associated with the install, uninstall, and rollbackactions? Where do I find out more about the setsecurity custom action?I do not quite understand how your code fits in with the set securitycustom action. Thank you, Misha. I really appreciate it.

# June 9, 2008 6:44 AM

Misha Shneerson said:

Paul,

Take a look at Darryn's article on VSTO 2005 SE deployment at http://go.microsoft.com/fwlink/?LinkID=57779. It comes with a sample solution which has SetSecurity as its customaction. Basically, you need to write a simple DLL with a class derivingfrom System.Configuration.Install.Installer class.

Then you need to add this project to the deployment project. Ibelieve there are lots of tutorials how to write Custom Actions - soyou will be able to find lots.

Let me know if you are stuck and I will try to find time to respond with more detailed steps.

# June 9, 2008 10:08 PM

Paul said:

Is this the right approach?

1. Add an installer class to the add-in project

2  In the "Public Overrides Sub Install..." procedure, call RegisterAddIn

3. In the "Public Overrides Sub Uninstall..." procedure,call UnRegisterAddIn

Here is how the vb.net code in the installer class looks thus far:

Imports Microsoft.Win32

Imports System.ComponentModel

Imports System.Configuration.Install

Public Class gseWrdAsgnUserInfoInst

   Private Const userSettingsLocation As String = "Software/Microsoft/Office/12.0/User Settings"

   Public Sub New()

       MyBase.New()

       'This call is required by the Component Designer.

       InitializeComponent()

       'Add initialization code after the call to InitializeComponent

   End Sub

   Public Overrides Sub Install(ByVal stateSaver As System.Collections.IDictionary)

       MyBase.Install(stateSaver)

       Call RegisterAddIn(Me.Context.Parameters("addinName"))

   End Sub

   Public Overrides Sub Uninstall(ByVal savedState As System.Collections.IDictionary)

       MyBase.Uninstall(savedState)

       Call UnRegisterAddIn(Me.Context.Parameters("applicationName"), Me.Context.Parameters("addinName"))

   End Sub

...

These procedures are then followed by your procedures

Do I need to call the UnRegisterAddIn procedure in "Public Overrides Sub Rollback..." as well?

Thank you, Misha. You don't know how much I appreciate this.

# June 12, 2008 11:46 AM

karan said:

Misha,

Do VSTO SE addin developers for office 2003 need to worry aboutmemory leaks of com objects used by addins especially outlook addins oris it taken care by addinloader/VSTOSE internals.

If yes, then what is the best practice for releasing com objects?Does setting them to null suffice or marshal.releasecomobject be usedinstead.

How is COM objects handled in memory by VSTO SE addins. I know thataddinloader disposes all com objects held by addin(outlook, word etc)once the last instance of application is closed. But what in case theapplication instance is running. Does it keep on adding more and morecom object refernce

# June 25, 2008 12:28 AM

Misha Shneerson said:

Hello karan,

VSTO takes care of COM references and users do not need to callMarshal.ReleaseComObject to cause Outlook to shutdown correctly.Actually the entire premise of us doing the special VSTO loader forOutlook was to provide an easy way around known Outlook 2003 bug whenmanaged add-ins would keep Outlook alive (see http://blogs.officezealot.com/whitechapel/archive/2005/07/10/6747.aspx).

Sue Mosher cover VSTO-enabled add-ins quite extensively here - http://www.outlookcode.com/article.aspx?ID=42

As to how VSTO deals with shutting down references to COM objects -we load add-ins into separate AppDomains. When add-in is closing wewill unload the AppDomain which has an effect of releasing all RuntimeCallable Wrappers (RCW) that live in this AppDomain.

This is all, of course, not to say that you should never useMarshal.ReleaseComObject in your add-in. There are other issues besidesshutdown that might need a call to Marshal.ReleaseComObject(unfortunately I do not do a lot of Outlook-specific development so Ido not have an exact list of issues).

But make sure to check Sue Mosher's website.

Hope this helps,

Misha

# June 25, 2008 1:00 PM

karan said:

Thanks for quick response.

I read thru the articles you provided and they are great. Iunderstand that addinLoader in vstose releases all com held by addinwhen last app instance is closed.

But what about while the addin is still running. As i keep on usingmy addin operations, the memory consumption keeps on inceasing for theapplication (word, excel etc) process hosting addin. Currently i amsetting the objects to null once i am done with them. Is it better touse marshal.releaseCComObject instead.

I tried it though but didnt see much improvement.

Also in my addin i am adding not more than 8 menus and their eventhandlers invoke UI in a sepearte process. But when i see the memoryconsumption of application, it is more than double compared to whenapplication is run w/o addin. This is another cause of concern.

I am still reading through the Sue mosher's website but didnt findanything that talks about the issues of memory management for VSTOaddins.

In Nutshell is it better to release com objects usignmarshal.releasecomobject wherever possible or should it be left uptoaddinloader? Please let me know if you know any bestpractices/guidelines for this.

I appreciate your help. Thanks Misha..

# June 26, 2008 1:07 AM

Misha Shneerson said:

Whilerunning, VSTO does not help you managed the COM interop layer. Theregular managed lifetime semantics apply here: when an RCW wrapping aCOM object is GC'd - the reference to the underlying COM object will beremoved. Usually, CLR is good to take care of memory and unreferencedRCWs are collected regularly.

Said that, when you are dealing COM the references management is abit more complicated. When managed objects are exposed to COM consumers(e.g. as event sinks) - these objects become 'rooted' objects that arenot eligible for GC unless COM consumers do not reference those objects.

The particular issue to be aware off is circular references thatmight prevent collection of objects - the most common case of creatingsuch circular reference is when you have a class that stores areference to a COM object and subscribes to an event from this COMobject - this creates a circular reference and all involved objectswill never get garbage collected untill you remove the event handlersor unload the AppDomain.

Marshal.ReleaseComObject is useful when you want to controlprecisely when to remove the reference to a COM object from managedcode. Notice, that ReleaseComObject does not remove the RCW - it ratherdecrements RCW's internal reference counter and when it drops to 0 -then when RCW will release the COM object.

Sometimes, in well controlled cases, using RCO is useful, but overdoing it might lead to bugs like NullReferenceException.

The most useful tool to troubleshoot memory links is SOS extension(you can use it in WinDbg or in VS while debugging native code). JohnRobbins has a very good book on debuggin which contains a good primeron SOS - but there are online references as well (e.g. you might wantto look at Tess' blog http://blogs.msdn.com/tess).In particular, the SOS has '!dumpheap -type System.__ComObject' commandwhich allows you to see all the RCWs, then you can pick any object andrun !GCRoot command that will tell what causes this object to stayalive.

This is probably a lot of information. So I am ready to take follow up questions :)

# June 26, 2008 2:56 PM

lee_fuller said:

Good morning,

Apologies if this posting is in the incorrect area but I'm completely stumped on this problem.

I've recently created a new Excel add-in using Visual Studio Toolsfor office and created the set-up package which installs the dlls,modifies the registry and updates the .NET security policy so theadd-in can run.

The package doesn't seem to install fully when running on anon-admin account machine.  Even if we run the install package using'Run as:' and using a admin account it still doesn't work quite right(though there are no error messages on the install).  The dlls areinstalled correctly but the registry isn't written to and the securitypolicies

aren't updated.

If I run the install package logged in directly as an administratorthen it all works fine.  I would have thought using 'Run as:' whenlogged in without admin rights it would work as well but for somereason it doesn't.

Does you know what's going on?  Is there some restiction on using'Run as:' that doesn't quite replicate being logged in directly assomeone with Admin rights?

Many thanks in advance,

Lee.

# July 7, 2008 11:29 AM

Misha Shneerson said:

Lee,

for these kinds of questions it would be helpful to know theoperating system you are using, version of VSTO you are using, versionof Excel you are targeting and so on.

But here are some things to keep in mind: if your setup installsregistry keys under HKCU hive - keep in mind that when you use 'runas:' this will install the registry keys into the HKCU hive of the useryou are 'run as'ing. Similar "redirection" happens if your setupmodifies security policy at the user-level.

On the other hand, if your setup tries to install any registry keysinto HKLM registry hive - the non-admins will not be able to installthese registry keys since they do not have the access.

Also keep in mind that some pre-reqs for the setup i.e. VSTO runtime have to be installed with admin priviliges.

# July 7, 2008 1:54 PM

mathjcb said:

Hi Misha ,

I already have an MSI in the field and do not want to push a new MSIbecause of the sheer number of users , I want to just create a registrypatch . Is it possible to create an MSP file using OCT to do this job ?

I was able to do that to propagate shared clip art registry entries to all users in the local machine .

Thanks

# July 14, 2008 4:55 PM

Misha Shneerson said:

Mathjcb,

I know what an MSP is but no idea what an OCT is though.

Unfortunately my depth of knowledge for building patches is notthere to make a possible/impossible  or right/wrong sorts of calls.

My gut says that if you created per-user installation package itmight be very hard to create a per-machine patch. But again, I might bewrong.

# July 15, 2008 1:34 AM

mathjcb said:

Icame to know about OCT(office customization tool ) from a microsoftengg on a tech support call . He helped me build the .msp file thatcreates registry entries in HKCU as he logs in and launches office,this was done to make a clipart organizer shared to all users who loginto the machine . (I do not know the underlying principle behind it ,but doesn't look like its the same as in your blog).

Also after installing the per user installer package I was able tomake it work for all users by running the below mentioned registry .

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Office/12.0/User Settings/MyAddin]

"Count"=dword:00000001

[HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Office/12.0/User Settings/Ameriprise.AdviceEditor.Word2007.EditorAddIn/Create]

[HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Office/12.0/User

Settings/Ameriprise.AdviceEditor.Word2007.EditorAddIn/Create/Software]

[HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Office/12.0/User

Settings/Ameriprise.AdviceEditor.Word2007.EditorAddIn/Create/Software/Microsoft]

[HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Office/12.0/User

Settings/Ameriprise.AdviceEditor.Word2007.EditorAddIn/Create/Software/Microsoft/Office]

[HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Office/12.0/User

Settings/Ameriprise.AdviceEditor.Word2007.EditorAddIn/Create/Software/Microsoft/Office/Word]

[HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Office/12.0/User

Settings/Ameriprise.AdviceEditor.Word2007.EditorAddIn/Create/Software/Microsoft/Office/Word/Addins]

[HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Office/12.0/User

Settings/Ameriprise.AdviceEditor.Word2007.EditorAddIn/Create/Software/Microsoft/Office/Word/Addins/MyAddin]

"Description"="MyAddin  -- an addin created with VSTO technology"

"FriendlyName"="MyAddin"

"LoadBehavior"=dword:00000003

"CommandLineSafe"=dword:00000001

"TestingModeEnable"="false"

"Manifest"="C://Program Files//Amp//Ampf//MyAddin.dll.manifest"

I already had the CASPOL policy run at machine level , all I needed to do was propagate the registry to HKCU ,

I was thinking of packaging this .reg as an MSP file using OCT , so my question .

Appreciate your reply .

Thanks ,

Mathew

# July 15, 2008 1:08 PM

Steffen said:

Hi Misha,

first let me say how much I appreciate your work on this issue!

Would you please clarify for me some questions regarding the Custom Action?

What I have so far is my AddIn project with a working SetSecurityproject included. I’ve added your code the same way like SetSecurity.What I do not understand is, how are the functions in your code arebeing called during install, uninstall and rollback (btw, what’s aboutcommit?) What do I have to fill in as CustomDataAction properties oninstall/uninstall/rollback/commit?

BTW, you’ve wrote that all the automatically registry entries fromthe registry view should be cleared. What’s about the “Classes”section? Should they be cleared as well?

Do you have a sample project available which is demonstrating the above topics?

Kind regards,

Steffen

# July 25, 2008 5:11 PM

Andrew Coates ::: MSFT said:

I had a great time over the last couple of days hanging out with Christen Boyd and some of the other

# July 26, 2008 10:54 AM

Thomas said:

Hi Misha,

I have installed my add-in for Office 2003 using the method you descibed above. It works perfect. The add-in works.

But as you mentioned also above Office 2003 does not display HKLM registered add-ins in COM add-ins dialog.

Is there any possibility to show the add-ins in the dialog?

# August 15, 2008 11:37 AM

Misha Shneerson said:

Hi Thomas,

> Office 2003 does not display HKLM registered add-ins in COMadd-ins dialog. Is there any possibility to show the add-ins in thedialog?

I wish I knew how to work around this.

# August 15, 2008 2:57 PM

rocky said:

hello,Misha

I have read the article,but all is about office2007.Now I havecreated an addin for office2003 ,and deployed it use administrators.itdoes work.but when with common Users account,it doesn't work.How can Ideploy the add-in for office2003 to all user?

kind regards

rocky cheng

# August 25, 2008 4:40 AM

Priya said:

Hi Misha,

When I uninstall my add-in, I am creating a Delete key. But I am notable to increment/decrement the counter while uninstalling since thecounter property/value itself is not available for my add-in inregistry.

Once my add-in is uninstalled, the local machine/user settings entryfor my add-in has only one property/value called default. Any idea onthis behaviour?

Thanks,

Priya

# August 29, 2008 5:14 AM

alan glover said:

Does this article apply to Outlook 2003 if the add-in was created using VSTO 2005 SE?  It is a managed code add-in?

# September 8, 2008 9:33 AM

smclewin said:

Misha,

Your series of articles were exceedingly helpful.  I started inwriting my first Office add-in using VS2008, VSTO 3.0 and Office 2007in January, at a time when no books were yet released for VS2008/VSTO3,most blogs talked about VSTO 2005 SE and VS2005 and I had this littleproblem of doing a multi-user installation of an add-in.  Thank you forthat.

I have a question about handling upgrades.

The add-in I've written uses several assemblies from our in-housecode library to connect to our back end system.  The add-in itself is afront for a document store product we create and allows user to editdocuments and spreadsheets in Office apps.

We install those assemblies to the GAC in the setup program - wesimply could not get the add-in to find the assemblies unless they werein the GAC.

I'm running into problems with testing upgrades to the system.

Our deployment is such that an administrator installs the add-ins onworkstations that are mult-tenant through shifts throughout the day. On the initial install, keys properly propagate from the HKLM hiveinto the HKCU hive for each user.  As each user starts Word/Excel, theclickonce vsto install process happens per user.

On uninstallation, the DELETE command is placed into HKLM, buttypically we are uninstalling and then immediately installing a newversion.  There is simply no guarantee that each user will log in tohave the DELETE command executed.

What I'm finding is that when the administrative account logs in,uninstalls the vsto add-in from the Add/remove Programs list,uninstalls the setup program the Add/remove programs list and thenreinstalls that we have a problem.

The add-ins work fine under the administrative account.  They won'tstart for the regular users after the upgrade process.  VSTO_LOGALERTSmessages cite missing assemblies as the reason.

Are there special considerations I need to make for upgrading fromone version of an add-in with satellite assemblies to the next for allusers using the techniques you described here?

Thanks for your time.  You've really helped with this series.

Scott

# September 30, 2008 11:21 AM

Akash Blogging...... said:

Why do we need to alter the &quot;SetSecurity&quot; and the &quot;Setup&quot; project? I sincerely suggest

# October 17, 2008 4:19 PM

Len said:

Hello there!

I just have a question about addin deployment. With regards to theway the solution depends on the "Count" value being incremented beforekeys will be propagated from HKLM..."Create" to HKCU:

- does this mean that if the user who installs an addin originally(admin) then starts an Office Application (causing the keys to becopied to their own HKCU), no other user will see the HKCU keys until anew install or repair is done?

From what I can see, Count only gets incremented at install orrepair time- does this mean that the keys will only be copied once?I.e: for the next user that starts an Offce application?

# November 5, 2008 7:46 AM

Misha Shneerson said:

Len,

On initial installation the Count value does not need to beincremented because there is nothing to increment - it did not existbefore :)

# November 5, 2008 12:55 PM

Aarun Awasthi said:

Hey Nice approach !!!!!

Thanks

Aarun

# November 19, 2008 7:48 AM

Mike Hatfield said:

Hi Misha,

Many thanks for these two articles. The processes seem to be workingok, apart from one final stumbling block I can't seem to shiftregarding common settings for both Word 2003 and 2007. (I'm usingVisual Studio 2005 and VSTO 2005 SE, all on XP.)

I understand that Word 2003 will happily load an add-ins registeredat HKLM/Software/Microsoft/Office/Word/Addins whereas 2007 wants themin HKCU. No problem and I've got a SetRegistry project copying the keysas described in this article.

But, Word 2007 absolutely refuses to load my add-in if the HKLM keyexists at all. Using RegMon, I can see it looking in HKLM, then HKCU,then setting LoadBehavior to "0" in HKLM. Unfortunately, this must beoverwriting the valid HKCU value too (in some internal structure)because the add-in doesn't load. If I remove the HKLM key, all is well.

I notice other people seem to have this working - so presume I've missed a step somewhere? I'd appreciate any pointers on this.

Many thanks again,

Mike

# December 12, 2008 9:16 AM

Larry said:

Isure wish you would answer the questions regarding custom actions,Misha.  I program in VB and I'm trying to understand how to use thethree C# code segments, but I'm struggling.

Why not just give us a complete walkthrough for C# or VB and be done with it?  That way we can take our pick.

# December 14, 2008 5:54 PM

Nikhil Sharma said:

Hi,

Thanks alot Misha.

This article solved my lots of problems.

Thanks and Best Regards,

Nikhil sharma

# March 3, 2009 4:51 AM

mailtorakib said:

Hello Misha,

Thank you for this nice article.

I am trying to build an add-in for Outlook 2003 and Outlook 2007. Ihave applied this method as you described for installing the add-in forall user. It is working for Outlook 2003 and Registry entriespropagates as they should for Outlook 2007.

My add-in loads in Outlook 2003 and works fine but it doesn't loadin Outlook 2007. After checking in the Tools --> Trust Center -->Addins, I found out that my Addin is listed as Inactive addin. I triedthe approach for activating inactive addins, but it still doesn't load.I have tried to grant full trust manually using Caspol.exe again andagain, but it doesn't help.

The "LoadBehavior" entry in the registry remains 3 even after the addin fails to load.

Can you please give me any idea on this issue?

Thanks

Rakib Hasan

# March 26, 2009 3:25 PM

Mike Hatfield said:

Hi Rakib

You're seeing exactly the same problem as in my comment: http://blogs.msdn.com/mshneer/archive/2007/09/05/deploying-your-vsto-add-in-to-all-users-part-ii.aspx#9202273

What's happening is Office 2007 sees the HKLM entries andimmediately flags your Addin with LoadBehavior=3. There's nothing I'vefound to workaround this.

Mike

# March 27, 2009 7:26 AM

Misha Shneerson said:

All, with the help of one of the readers we have confirmed the source of the killbit problem.

It turns out that some international installations of Windows XP SP2do install the killbit (I did suspect one of the security updates - butturned out this was way simpler than that). We have confirmed thatinstalling Windows XP SP2 Czech OS do cause killbit to appear, but thatis not the case with either US or German editions.Such inconsistency isthe source of major problems for out developers where solutionsmysteriouly do not work at customers sites.

We did work with folks in Windows to get this issue addressed bypublishing a global update removing this reg key but due to relativelyeasy workaround, the relatively old age of the OS itself and thuslimited support scope - the update did not get approved.

Instead, Microsoft we are planning to publish a KB articleconfirming the problem and also recommending to either remove theregistry key during the setup or, if no custom setup of the solution isdone e.g. when doc-level solution are deployed onto a server, thensolution code can detect the presence of this registry key and informthe user that this key needs to be removed for the solution to workproperly.

Thanks a lot to Ernst for helping to troubleshoot this.

Misha

# March 27, 2009 1:07 PM

mailtorakib said:

Hi Mike,

Thanks a lot. Mine is the same problem as yours. After removing the HKLM entries it is working fine.

So, what I understood that, I can't make the registry entries forboth outlook simultaneously. So we must re-install the add-in each timethe user switches from one version(2003/2007) of outlook(or any officecomponent) to another.

Is it right?

Thanks

Rakib Hasan

# March 28, 2009 9:03 PM

Manpreet said:

ReallyBokus article. NO proper explaination, I went through both part. Insecond part, When Author is writing about custom action. Not a singleproper step given about how and what we have to do.

I went through from first and came to custom registry action. Istuck because Author is busy to give the credit to his friend, Heforgot , he is explaining this article, Even there is no other urlgiven through Which developer can go through and understand how toimplement the require step.

No worth, to get half knowledge. I appriciate if Author share either one sample project code or explain proper step.

I feel First time , I saw very unprofessional article in this site.

manpreetsinghbhatia@gmail.com

# May 15, 2009 10:41 AM

Manpreet Singh Bhatia said:

Hi Everyone,

See more better and more relaible example has given by Microsoft.Url is

http://msdn.microsoft.com/en-us/library/cc136646.aspx

# May 15, 2009 10:59 AM

Manpreet said:

See this article to understand this article

http: // msdn.microsoft.com/en-us/library/cc136646.aspx

# May 15, 2009 11:07 AM

Wasabi said:

Thank's a lot.

This explains a lot why my LoadBehavior get sets to 0 in HKLM

Wasabi

# August 28, 2009 12:49 AM

Dennise said:

How can i deploy an outlook add-in to all users using Terminal Server and Citrix.

Any help would be much appreciated.

Thanks.

# September 16, 2009 1:31 AM

sri.net said:

Hello Misha

I am a beginner at this vsto addin

i just created a combined setup project for individual addins for word, excel and power point

i also added the setsecurity project for making the assemblies FullTrust

all the installation, usage and and unistallation is working perfectly

one problem is that the Security Code group created for the addinsis not getting overwritten when i am re-installing or deleting when iam uninstalling

What should i do???

thank you again for this post

# September 17, 2009 3:36 AM

William Wegerson said:

What do you mean when you state, about 2003 addin not showing up in Outlook COM-Addins list when you say:

<blockquote>From this point on the loading failures can be seen using

VSTO_DISPLAYALERTS environment variable.</blockquote>

I cannot find any information about VSTO_DISPLAYALERTS. Where is this environment variable set and where does one view it?

advTHANKSance

# September 22, 2009 7:30 PM

Misha Shneerson said:

Oh, it should be VSTO_SUPPRESSDISPLAYALERTS. I will update the post.

# September 22, 2009 8:39 PM

Dennise said:

Hi,

I hope someone can help me. this is my problem, we have an add-increated in 2003. And then I upgraded it using vb 2005. upgrade theversion label. When I upgrade the previous add-in version 1.0 installedon the clients machine to 1.2, it worked fine.

Now, I have created another upgrade on the add-in. so now I haveversion 1.3. The problem now is when I upgrade the add-in on client'smachinen from 1.2 to 1.3, the add-in is not being loaded on outlook. Itis returning an error, failed to grant permission thing.... And thenwhen i repaired 1.3, it is now working fine.

Here is another wierd thing, when i try to upgrade the add-in from 1.0 to 1.3 (skipping 1.2), everything is working fine.

So I am really not sure what is happening when i upgrading the add-in from 1.2 to 1.3 that's causing the permission issue.

Can someone please help me. I am kind a desperate in here.

THanks a lot

Dennise

# October 6, 2009 8:19 PM

Jason Drawmer said:

Hi,

I'm just wondering - are those 3 pieces of code (with obviouslydifferent content) required in order for this to work - or do theysimply clean up the registry at dfferent points in time?

I've been struggling to get the InstallAllUsers to work with Office2007, and require it for my Outlook add-in and am going to attempt toadopt this approach but first wanted to make sure.

Also - if they are required, can they simply be added to my Installer class which i've used to handle CAS policies?