The Problem (Q-score 8, ranked #156th of 303 in the Excel VBA archive)
The scenario as originally posted in 2009
How does Excel VSTO Work? If I create an Excel Workbook solution in Visual Studio 2005 I can then happily code away with full access to the 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?
Why this Range / Worksheet targeting trips people up
The question centers on reaching a specific cell, range, or workbook object. In Excel VBA, this is the #1 source of failures after activation events: every property (.Value, .Formula, .Address) behaves differently depending on whether the parent Workbook is explicit or implicit.
The Verified Solution — niche answer (below median) (+7)
Advisory answer — community consensus with reference links
Note: the verified answer below is a reference / advisory response rather than a copy-ready snippet.
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.
When to Use It — vintage (14+ years old, pre-2013)
Ranked #156th in its category — specialized fit
This pattern sits in the 98% tail relative to the top answer. Reach for it when your scenario closely matches the question title; otherwise browse the Excel VBA archive for a higher-consensus alternative.
What changed between 2009 and 2026
The answer is 17 years old. The Excel VBA object model has been stable across Office 2013, 2016, 2019, 2021, 365, and 2024/2026 LTSC, so the pattern still compiles. Changes that might affect you: 64-bit API declarations (use PtrSafe), blocked macros in downloaded files (Mark-of-the-Web), and the shift toward Office Scripts for web-first workflows.