OLE Conflicts with VSTO-Based Classification Plugin (FDC-Agent)

Overview

Our Classification plugin is built using VSTO (Visual Studio Tools for Office) and deeply integrates into the Microsoft Office application lifecycle (Word, Excel, etc.).

When Office is started via OLE (Object Linking and Embedding) automation (for example, another system programmatically opening Excel or Word), a technical limitation occurs due to how VSTO add-ins attach to Office processes.

This article explains:

  • Why the issue happens
  • Current behaviour
  • Known limitations
  • Workaround
  • Important edge cases

What Is Happening?

VSTO Behaviour

VSTO add-ins:

  • Attach to the Office process during startup
  • Subscribe to application events (Open, Save, Activate, etc.)
  • Rely on standard Office initialization flow

OLE Behaviour

OLE automation:

  • Starts Office in a special automation context
  • May initialize Office differently
  • Does not always behave like a normal interactive session

Because our plugin relies heavily on VSTO event subscriptions and lifecycle hooks, it cannot reliably operate inside OLE-initialized processes.

This is a technical limitation of VSTO + OLE interaction, not a defect in the plugin logic itself.

Root Cause

  • VSTO add-ins load per Office process
  • OLE automation alters initialization flow
  • VSTO does not provide a reliable built-in mechanism to distinguish and isolate OLE automation contexts cleanly
  • Once the plugin suppresses itself for OLE safety, subsequent process behaviour becomes inconsistent

Why This Cannot Be Fully Fixed

Microsoft does not provide:

  • Official support for fully isolating VSTO add-ins from OLE automation contexts
  • A guaranteed way to distinguish OLE automation startup from interactive startup
  • A safe mechanism to dynamically attach/detach VSTO behaviour after process initialization

Because of this, the limitation is architectural.

Terms

  1. OLE application - embedded application started from another Office application (for example insert Excel table into to the Word application).
  2. Normal application - Office application started by clicking on the application icon (for example user double clicks to Excel.exe).

Workaround

If OLE automation must be used:

  • Ensure NO Normal Office apps sessions are running
  • Start OLE first
  • Accept that the Classification functionality will be disabled in that session

If Classification is required:

  • Ensure NO OLE apps sessions are running
  • Start Normal Office app session
  • Accept that the OLE functionality will be throwing errors in that session.

Use cases for workaround

Use case (Normal):

Normal Excel → Then OLE Excel

  1. User starts Excel normally.

    → Plugin loads and works correctly.

  2. OLE then starts Excel (without closing the first instance).

Result:

  • OLE Excel process throws errors.
  • Plugin attempts to attach in a context that is not OLE-compatible.

Use case (OLE)

OLE Excel → Then Normal Excel

  1. OLE starts Excel first.

    → Plugin detects OLE and disables itself

  2. User then starts Excel normally (without closing OLE Excel)

Result:

  • Classification plugin does not work.
  • Plugin remains disabled because the first process was OLE.

Conclusion

  • This is a known technical limitation from Microsoft.
  • No full fix is currently possible due to VSTO/OLE architecture constraints.
  • Workaround implemented to prevent OLE runtime failures.