How does Excel VSTO Work?

Question

Hi

How does Excel VSTO Work? If I create an Excel Workbook solution in Visual Studio 2005 then I can happily code away, access a full Excel object model and even treat the Excel sheet as a design surface. When I build the solution I get a .XLS file and a .DLL (containing my C# code).

I can now start up the Excel sheet just by double clicking on the .XLS and there is my sheet functioning with all my C# code and any controls I dropped on the sheet etc.

How is the sheet referencing the DLL? What part of the excel workbook/sheet tells it that it needs to fire up the CLR and host my assembly?

Thanks

Answer 1

Hiya,

This is all done in the Registry, you should be able to find the key in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Excel or your equivelant application. I've more experience with COM Addins which are registered somewhere else in the Registry as well. This key should have a LoadBehaviour item under it which is used to determine how the application is loaded (2 is load manually, 3 is load automatically on startup).

Do you have a Setup Project for your VSTO? Inside there you can see the Registry key that is set, but the Setup program will/should also Register the VSTO in GAC (though don't take my word for it as I'm a bit shakey with VSTO as I said).

Hope this helps, I shall try and find some more information for you.

Edit You should try reading the following http://msdn.microsoft.com/en-us/library/bb386298.aspx which will give you an explanation of what the addin is. It's really just a wrapper around a COM host which is loaded from the Registry and the VSTO talks to that using some Interoparability code.

Also useful are http://msdn.microsoft.com/en-us/library/23cw517s.aspx (Getting Started with Visual Studio Tools for Office, don't knock it because it says Getting Started in, there's a lot of useful info in there) and http://msdn.microsoft.com/en-us/library/hy7c6z9k.aspx (Which is linked from the first and is an overview of VSTO Addins).

Answer 2

According to this (thanks PintSizedCat) for Excel 2003 the following happens:

The Microsoft Office application checks the custom document properties to see whether there are managed code extensions associated with the document. For more information, see Custom Document Properties Overview.

If there are managed code extensions, the application loads AddinLoader.dll. This is an unmanaged DLL that is the loader component for the Visual Studio 2005 Tools for Office Second Edition runtime. For more information, see Visual Studio Tools for Office Runtime Overview.

AddinLoader.dll loads the .NET Framework and starts the managed portion of the Visual Studio Tools for Office runtime.

The Visual Studio Tools for Office runtime creates an application domain, sets policy for the application domain not to trust the My Computer Zone, and checks the code access security policy store to find a policy for the customization assembly.

The .NET Framework validates the evidence presented by the assembly against the policy. If it fails, an error is raised. If it passes, the process continues.

If the customization uses a deployment manifest, the Visual Studio Tools for Office runtime uses it to check for assembly updates. If any updates are necessary, they are performed now.

The Visual Studio Tools for Office runtime loads the assembly into the application domain.

The Visual Studio Tools for Office runtime calls the Startup event handler in your customization assembly. For more information, see Visual Studio Tools for Office Project Events.

In my test project's Excel workbook I have two custom properties:

_AssemblyName, value = * _AssemblyLocation, value = {533b2c13-a125-418a-bfff-9546b0762807}

I suppose these are the properties which direct the VSTO runtime to my assembly.