Deploying your VSTO Add-In to All Users (Part II)

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

MSDN Blog Postings » Deploying your VSTO Add-In to All Users (Part II) — Thu, 06 Sep 2007 12:16:58 GMT

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

re: Deploying your VSTO Add-In to All Users (Part II)

Ken McCormack — Wed, 12 Sep 2007 10:09:21 GMT

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

re: Deploying your VSTO Add-In to All Users (Part II)

Misha Shneerson — Wed, 12 Sep 2007 20:39:47 GMT

Ken,

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

There is no particular reason besides my preference. I could have said "go and add this key and these values through the designer", but for some reason I just felt it might be simplier for everyone if I said "copy&past these values, modify them and import them into your project", this is especially true because copying from an existing script 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 under HKCU\...\Office\12.0\User Settings\<MyAddin>. The instructions will be carried out only if those values are different, then Office copies the new Count under HKCU\...\Office\12.0\User Settings\<MyAddin> as a form of optimization to avoid carrying the same copy/delete instruction on every boot. Hence, Count value needs to stay even after add-in is uninstalled. When a registry value is authored through MSI tables - it will be cleaned up during the uninstall and the only way to achieve the desired behavior is to write a 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 need to be added during installation/repair and removed during uninstall.

2. The registry keys managed by the Custom Actions are those that Windows 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.

re: Deploying your VSTO Add-In to All Users (Part II)

Jie — Sun, 16 Sep 2007 18:15:32 GMT

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

Xie Xie Misha! :)

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

re: Deploying your VSTO Add-In to All Users (Part II)

George — Thu, 20 Sep 2007 22:45:30 GMT

Hi Misha,

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

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

Thanks,

George.

re: Deploying your VSTO Add-In to All Users (Part II)

Misha Shneerson — Fri, 21 Sep 2007 08:59:30 GMT

Oh, I just meant the "Properties" Window - the one that shows and allows browsing properties of the currently selected object. In the Registry View, 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 modify is "DeleteOnUninstall". On my machine the window shows up in the right lower corner of the VS IDE.

re: Deploying your VSTO Add-In to All Users (Part II)

Ignacio — Fri, 28 Sep 2007 00:37:40 GMT

Hi Misha,

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

Thanks,

Ignacio.

re: Deploying your VSTO Add-In to All Users (Part II)

Misha Shneerson — Fri, 28 Sep 2007 01:06:49 GMT

Ignacio,

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

re: Deploying your VSTO Add-In to All Users (Part II)

Kulvinder — Tue, 02 Oct 2007 15:55:15 GMT

Hi Misha,

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

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

Thanks

re: Deploying your VSTO Add-In to All Users (Part II)

Shawn Mullen — Thu, 04 Oct 2007 19:38:37 GMT

Automatic updates are great. I wished it actually worked. Has anyone addressed the fact that most companies do not allow their users to download dlls over http. If there is a solution to this using VSTO 2005 SE, please let me know, but as far as I can see there isn't one. So, I now have to use a third party updater to make this work (I don't feel like writing my own).

re: Deploying your VSTO Add-In to All Users (Part II)

BJ Herrington — Tue, 16 Oct 2007 00:27:54 GMT

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

re: Deploying your VSTO Add-In to All Users (Part II)

Misha Shneerson — Tue, 16 Oct 2007 02:13:50 GMT

BJ,

You are correct - but only half way. Only pure managed add-ins have support for some of the Office 2007 features such as CustomTaskPanes and Ribbons. Once you start using these VSTO features you really need this "Manifest" reg value.

re: Deploying your VSTO Add-In to All Users (Part II)

Markus Jerneborg — Tue, 23 Oct 2007 19:06:53 GMT

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

re: Deploying your VSTO Add-In to All Users (Part II)

Jason — Mon, 12 Nov 2007 09:12:21 GMT

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

re: Deploying your VSTO Add-In to All Users (Part II)

Misha Shneerson — Mon, 12 Nov 2007 21:52:36 GMT

Jason,

I am sorry. I tried to understand your question but I could not figure out what you are trying to say. Can you rephrase what is the problem you are seeing?

VSTO 2005 SE Add-In Deployment / ALLUSERS

Tue, 27 Nov 2007 13:43:35 GMT

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

VSTO 2005 SE Add-In Deployment / ALLUSERS

Noticias externas — Tue, 27 Nov 2007 14:44:06 GMT

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

re: Deploying your VSTO Add-In to All Users (Part II)

Christopher Painter — Sun, 27 Jan 2008 01:29:30 GMT

I have the Create/Delete command pattern down. And on the surface everything works. But I notice several problems: ( this is a VSTO 2008 .vsto not VSTO 2005 .manifest )

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

2) When they click yes:

a) registry entries get created by vstoinstaller in HKCU\Software\Microsoft\VSTA and VSTO keys. They are guids and different 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 removes the addin the next time word is run but the VSTA, VSTO and Add/Remove resources linger on the machine.

4) I've not tested upgrade scenarios yet.

re: Deploying your VSTO Add-In to All Users (Part II)

Joe — Tue, 29 Jan 2008 17:52:08 GMT

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 troubles reading and writing to registry. I'm using pretty much straight forward commands 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

re: Deploying your VSTO Add-In to All Users (Part II)

Misha Shneerson — Wed, 30 Jan 2008 01:05:08 GMT

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

re: Deploying your VSTO Add-In to All Users (Part II)

Gábor Vas — Wed, 20 Feb 2008 04:56:52 GMT

Cristopher Painter:

When the manifests are signed with a certificate from the Trusted Publishers certificate store, and that certificate is certified directly or indirectly with a certificate from the Trusted Root Certificate Authorities certificate store, then ClickOnce won't ask the users for trust.

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

Aggregating blogs in a blog

Visual Studio 2008: Microsoft Visual Studio Tools for Office — Fri, 22 Feb 2008 19:19:21 GMT

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

re: Deploying your VSTO Add-In to All Users (Part II)

Mohan Kumar K — Wed, 27 Feb 2008 07:15:38 GMT

I have created an addin for Word 2007 using VSTO SE and I am trying to deploy it for All Users. I find your article very useful and it helped me 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 and need 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 into that "RegisterOffice2007AddIn.cs". (I mean where exactly we need to copy 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 with SetSecurity Custom Action you should be able to wrap this code into a Custom Action DLL, set CustomActionData properties as /addinName="MyCompany.MyAddIn" /application="Excel" (again choose the value that fit your particular case), and invoke the above methods on Install, Uninstall and Rollback. I will try to sum it all up in another post though.

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

Any help would be much appreciated.

Thanks,

Mohan

re: Deploying your VSTO Add-In to All Users (Part II)

Misha Shneerson — Wed, 27 Feb 2008 07:52:25 GMT

Mohan,

if you look carefully at the SetSecurity sample project you can notice that SetSecurity class actually derives from System.Configuration.Install.Installer class and overrides its Install, Rollback and Uninstall methods. These are the methods that Windows Installer is actually calling - they in turn extract the parameters and call the worker method - SetSecurity. You just need to follow the same pattern here. Hope this helps.

re: Deploying your VSTO Add-In to All Users (Part II)

Mohan Kumar K — Wed, 27 Feb 2008 10:05:35 GMT

Misha,

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

public void RegisterAddIn(string addInName)

public void UnRegisterAddIn(string applicationName, string addInName)

Thanks,

Mohan

re: Deploying your VSTO Add-In to All Users (Part II)

Ricky — Fri, 28 Mar 2008 19:55:19 GMT

Hi Misha,

I've processed every step of your tutorial and it works to deploy my PowerPoint-Add-In to every user on the target machine, but there is still a problem with some Code Access Security-Stuff I think. If I login as another user on the target machine and start PowerPoint I get a popup that says "Der angeforderte Registrierungszugriff ist unzulässig." (must be the message "Requested registry access not allowed" in english).

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

Thanks a lot and best wishes!

Ricky

re: Deploying your VSTO Add-In to All Users (Part II)

Misha Shneerson — Fri, 28 Mar 2008 20:17:40 GMT

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

re: Deploying your VSTO Add-In to All Users (Part II)

Ricky — Fri, 28 Mar 2008 20:34:04 GMT

It's a piece of my code in the add-in which tries to read a value from registry. I also have a version of that add-in-code for PPT2003 which is identically with it for 2007 except for the steps to install for all users. in PPT2003 all works fine.

re: Deploying your VSTO Add-In to All Users (Part II)

Ricky — Mon, 31 Mar 2008 18:46:05 GMT

Hi again!

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

RegistryPermission readPerm1 = new RegistryPermission(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

re: Deploying your VSTO Add-In to All Users (Part II)

Lily Collins — Tue, 08 Apr 2008 16:36:36 GMT

Dear Misha,

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

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

re: Deploying your VSTO Add-In to All Users (Part II)

Misha Shneerson — Tue, 08 Apr 2008 19:48:46 GMT

Lily,

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

re: Deploying your VSTO Add-In to All Users (Part II)

Inder — Wed, 16 Apr 2008 02:04:12 GMT

Hi Misha,

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

I tried this in office 2003 and created all registry entries under HKLM. My setup creates all required registry entries but the addin doesnt get loaded. And i am not talking about CAS yet, it doesnt even show 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.

re: Deploying your VSTO Add-In to All Users (Part II)

Misha Shneerson — Wed, 16 Apr 2008 02:58:36 GMT

Office 2003 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 HKLM add-ins did not load. Typically, to deploy to HKLM on Office 2003 - I would just move all the registry keys from HKCU to HKLM and modify the SetSecurity to run caspol for machine level policy.

What happens under the cover?

VSTO SE AddIn loader is implemented by AddinLoader.dll - this is a native DLL that knows how to handle instantiation of VSTO add-ins as if those were regular COM objects. Hint: to check whether Office 2003 picked up your addin you can check whether AddinLoader.dll has been loaded (use process explorer from sysinternals.com or just a regular native debugger to see which modules are loaded). When AddInLoader.dll is loaded into the process it has no idea whether it was registered from HKLM or HKCU. Instead, the only information it gets is the GUID of the COM Add-In. Given this information it always tries to find the .manifest file (which has information about assemblies that need to be loaded) by combinining the ManifestLocation and ManifestName registry values from HKCR\CLSID\{-- GUID ---}\InProcServer32. Note that HKCR is not a real registry hive - instead it is just a virtual merge of HKLM\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 result from incorrect registration and you really need to follow the entire chain to understand what might be going on in your case. Additional points of failure are: add-in might have been soft-disabled - LoadBehavior was reset to 2, add-in might have been killed and have been 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.

re: Deploying your VSTO Add-In to All Users (Part II)

Angledor — Thu, 24 Apr 2008 11:17:32 GMT

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

Deploying your VSTO 2008 Add-In to All Users (Part III)

Misha Shneerson — Fri, 25 Apr 2008 02:17:34 GMT

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

Correction!

See what I see. — Wed, 30 Apr 2008 04:18:28 GMT

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

re: Deploying your VSTO Add-In to All Users (Part II)

Phillip — Fri, 02 May 2008 17:11:50 GMT

Hi Misha, thanks for the article. I created the propagation keys under HKLM like in the article, and they appear to be creating the HKCU keys correctly. Despite this, my add in is still only appearing on the user account that I used while installing it. It doesn't show up on any other user accounts.

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

Thanks,

re: Deploying your VSTO Add-In to All Users (Part II)

Misha Shneerson — Fri, 02 May 2008 19:50:34 GMT

Hi Phillip,

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

re: Deploying your VSTO Add-In to All Users (Part II)

Phillip — Fri, 02 May 2008 21:18:05 GMT

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

thanks,

re: Deploying your VSTO Add-In to All Users (Part II)

Misha Shneerson — Fri, 02 May 2008 21:29:47 GMT

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

VSTO 3.0 Add-Ins für alle User installieren

Open XML, VSTO, Deployment, .NET und anderes — Fri, 09 May 2008 17:20:14 GMT

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

Deploying VSTO 3 solutions

Andrew Coates ::: MSFT — Fri, 16 May 2008 05:04:18 GMT

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

re: Deploying your VSTO Add-In to All Users (Part II)

Rajesh — Fri, 06 Jun 2008 16:12:36 GMT

This is for Outlook 2003 Addin developed using VSTO 2005.

I have similar but not the exact problem. I am trying to deploy an outlook addin in Citrix. My setup project applies custom security policies 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 installed it - no other users can see the toolbar button this addin provides. I checked to see if the addin was blocked - it is not listed in the COM Addin list.

Any suggestions

re: Deploying your VSTO Add-In to All Users (Part II)

Misha Shneerson — Fri, 06 Jun 2008 19:53:39 GMT

Rajesh,

If things are the way you say they are - then there should be no problem, Citrix or not, all users on the machine should be seeing this addin.

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

re: Deploying your VSTO Add-In to All Users (Part II)

Paul — Mon, 09 Jun 2008 04:27:33 GMT

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

re: Deploying your VSTO Add-In to All Users (Part II)

Misha Shneerson — Mon, 09 Jun 2008 09:29:58 GMT

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

re: Deploying your VSTO Add-In to All Users (Part II)

Paul — Mon, 09 Jun 2008 13:44:04 GMT

Thank you for your response. It is a shame that the article will not be written. 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 be written, 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 the resulting dll be associated with the install, uninstall, and rollback actions? Where do I find out more about the setsecurity custom action? I do not quite understand how your code fits in with the set security custom action. Thank you, Misha. I really appreciate it.

re: Deploying your VSTO Add-In to All Users (Part II)

Misha Shneerson — Tue, 10 Jun 2008 05:08:14 GMT

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 custom action. Basically, you need to write a simple DLL with a class deriving from System.Configuration.Install.Installer class.

Then you need to add this project to the deployment project. I believe there are lots of tutorials how to write Custom Actions - so you 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.

re: Deploying your VSTO Add-In to All Users (Part II)

Paul — Thu, 12 Jun 2008 18:46:24 GMT

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.

re: Deploying your VSTO Add-In to All Users (Part II)

karan — Wed, 25 Jun 2008 07:28:29 GMT

Misha,

Do VSTO SE addin developers for office 2003 need to worry about memory leaks of com objects used by addins especially outlook addins or is 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 used instead.

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

re: Deploying your VSTO Add-In to All Users (Part II)

Misha Shneerson — Wed, 25 Jun 2008 20:00:10 GMT

Hello karan,

VSTO takes care of COM references and users do not need to call Marshal.ReleaseComObject to cause Outlook to shutdown correctly. Actually the entire premise of us doing the special VSTO loader for Outlook was to provide an easy way around known Outlook 2003 bug when managed 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 we will unload the AppDomain which has an effect of releasing all Runtime Callable Wrappers (RCW) that live in this AppDomain.

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

But make sure to check Sue Mosher's website.

Hope this helps,

Misha

re: Deploying your VSTO Add-In to All Users (Part II)

karan — Thu, 26 Jun 2008 08:07:04 GMT

Thanks for quick response.

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

But what about while the addin is still running. As i keep on using my addin operations, the memory consumption keeps on inceasing for the application (word, excel etc) process hosting addin. Currently i am setting the objects to null once i am done with them. Is it better to use 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 event handlers invoke UI in a sepearte process. But when i see the memory consumption of application, it is more than double compared to when application is run w/o addin. This is another cause of concern.

I am still reading through the Sue mosher's website but didnt find anything that talks about the issues of memory management for VSTO addins.

In Nutshell is it better to release com objects usign marshal.releasecomobject wherever possible or should it be left upto addinloader? Please let me know if you know any best practices/guidelines for this.

I appreciate your help. Thanks Misha..

re: Deploying your VSTO Add-In to All Users (Part II)

Misha Shneerson — Thu, 26 Jun 2008 21:56:42 GMT

While running, VSTO does not help you managed the COM interop layer. The regular managed lifetime semantics apply here: when an RCW wrapping a COM object is GC'd - the reference to the underlying COM object will be removed. Usually, CLR is good to take care of memory and unreferenced RCWs are collected regularly.

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

The particular issue to be aware off is circular references that might prevent collection of objects - the most common case of creating such circular reference is when you have a class that stores a reference to a COM object and subscribes to an event from this COM object - this creates a circular reference and all involved objects will never get garbage collected untill you remove the event handlers or unload the AppDomain.

Marshal.ReleaseComObject is useful when you want to control precisely when to remove the reference to a COM object from managed code. Notice, that ReleaseComObject does not remove the RCW - it rather decrements 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). John Robbins has a very good book on debuggin which contains a good primer on SOS - but there are online references as well (e.g. you might want to look at Tess' blog http://blogs.msdn.com/tess). In particular, the SOS has '!dumpheap -type System.__ComObject' command which allows you to see all the RCWs, then you can pick any object and run !GCRoot command that will tell what causes this object to stay alive.

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

re: Deploying your VSTO Add-In to All Users (Part II)

lee_fuller — Mon, 07 Jul 2008 18:29:37 GMT

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 Tools for office and created the set-up package which installs the dlls, modifies the registry and updates the .NET security policy so the add-in can run.

The package doesn't seem to install fully when running on a non-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 are installed correctly but the registry isn't written to and the security policies

aren't updated.

If I run the install package logged in directly as an administrator then it all works fine. I would have thought using 'Run as:' when logged in without admin rights it would work as well but for some reason 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 as someone with Admin rights?

Many thanks in advance,

Lee.

re: Deploying your VSTO Add-In to All Users (Part II)

Misha Shneerson — Mon, 07 Jul 2008 20:54:37 GMT

Lee,

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

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

On the other hand, if your setup tries to install any registry keys into HKLM registry hive - the non-admins will not be able to install these 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.

re: Deploying your VSTO Add-In to All Users (Part II)

mathjcb — Mon, 14 Jul 2008 23:55:28 GMT

Hi Misha ,

I already have an MSI in the field and do not want to push a new MSI because of the sheer number of users , I want to just create a registry patch . 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

re: Deploying your VSTO Add-In to All Users (Part II)

Misha Shneerson — Tue, 15 Jul 2008 08:34:27 GMT

Mathjcb,

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

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

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

re: Deploying your VSTO Add-In to All Users (Part II)

mathjcb — Tue, 15 Jul 2008 20:08:21 GMT

I came to know about OCT(office customization tool ) from a microsoft engg on a tech support call . He helped me build the .msp file that creates registry entries in HKCU as he logs in and launches office, this was done to make a clipart organizer shared to all users who log into 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 to make 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]