Working with VSTO 2005 SE Beta + Office 2007. Created a test application Add-in project for Excel. When I open a Word 2007 document with an linked Excel workbook (Excel isn't running at this point), I get the following error message in the Excel application space.
System.NullReferenceException: Object reference not set to an instance of an object. at XL2007_Test.ThisAddin_Startup(Object sender, EventArgs e) in D:\vsto\ThisAddin.cs:line 24
Apparently, Excel recognizes there is a workbook and is able to assign ActiveWorkbook to an object variable. But when the object variable is addressed, the error message occurs.
try
{
if (this.Application.Workbooks.Count > 0)
{
Excel.Workbook wb = (Excel.Workbook)this.Application.ActiveWorkbook;
MessageBox.Show(wb.Name); //error occurs here
}
I've discovered I can trap this by checking UserControl. Is this the best/correct way to determine whether the Add-in should "run"
ThisAddin_Startup triggering on OLE client startup
John Oliver (UK)MSP, VSIP
Cindy, thanks again for your considered feedback - I've updated the bug with this additional information.
Also, a whitepaper about the various add-in load scenarios is a good idea.
Finally, distinguishing nuances of automation startup is definitely something the Office host would have to do, so that would be a suggestion for a later release.
Dan Mikkelsen
Hi Cindy
There are probably other unexpected behaviors when and add-in runs as a result of the host app being started through automation, so this doesn't surprise me. As you've discovered, UserControl is a useful property to reliably determine whether or not the host app was started by a real user or through automation. One of the most important pieces of information this gives you is whether the host app will terminate when the last programmatic reference is released. There are some other interesting aspects to this, documented in this KB:
http://support.microsoft.com/default.aspx scid=kb;en-us;Q288902
Note also that traditional VBA add-ins won't load by default if the app is started through automation, which is peripherally relevant here:
http://support.microsoft.com/kb/213489/en-us
There are some obvious uses for the information that UserControl gives you, and certainly it would be reasonable to use it to determine some code path in your add-in.
I will open a bug for this issue, so that we can triage it in more depth - there might be something more useful we could do here rather than allowing the NullReferenceException to propagate out. Thank you for bringing this to our attention - and, just to get more feedback from you, what would you consider acceptable behavior here
Andrew
kampak1111
Hi Andrew
Yes, I believe that's why some "auto macros" in the Office apps are disabled when the file is "hosted". For example, an Auto_Open macro in an Excel workbook won't run when the workbook is an embedded object or (as I recall) hosted in a control such as DSOFramer or the WebBrowser control.
I wouldn't have been so surprised if I'd been explicitly starting Excel through automation. One tends to forget that Word automates (for example) Excel in the background when a document is opened and automatic update of links is enabled in order to update the embedded objects' contents.
Thanks for the URL, that's an interesting article that I hadn't happened across, before and answers a few "anomalies" I've encountered in the past. What it says about UserControl doesn't apply 100% to the Word application, however.
"If you want to configure an instance through Automation and then leave it open for the user to use, you need to set the UserControl property to TRUE and then release all your references. The server then stays running (because the UserControl property is TRUE) and shuts down appropriately when the user closes the application (because there are no outstanding references). "
For Word, this property is read-only, and...
"The UserControl property is a boolean property that indicates whether the server application automatically shuts down when its last reference is released (set to nothing). "
Word doesn't shut down when the last reference is released, but stays in memory.
Difficult to pin down :-) Certainly, one request from "devs" I see with some regularity is getting an Add-in to work properly when the user is editing "in-place", so disabling certainly isn't the answer.
At a minimum, it would be useful if the VSTO tool would perform the UserControl check when the NullReferenceException is thrown at startup and return a more targeted exception, saving the developer some time and frustration. I spent some three hours investigating this "bug" in order to write a BR before realizing what was actually happening.
An article about the different ways an application can be loaded (user / automation / embedded object / link updating), how Usercontrol can help, and what an Add-in can and cannot do in a particular app when UserControl = false would be very welcome. (I was able to get a reference to the application, but not to the workbook, for example). That would help guide the decisions each developer makes for his individual use case.
It would be very useful if we could distinguish at startup between "plain vanilla" automation / automation for the purpose of updating links / automation opening an embedded object (in-place). But I suppose that may be something that would have to come from the Office app