插件获取宿主程序数据的接口设计及主动获取需求解决方案咨询

Great question—this is a common challenge when building host-plugin integrations, especially with tools like Visual Assist that need on-demand access to host data without constant push updates. Let's break down practical solutions tailored to your Visual Studio (VS) and Visual Assist (VA) example:

1. Add a Bidirectional "Data Request" Interface #

Your existing doSomething(string data, action callback) works well for host-initiated triggers (like right-click menu actions), but to let the plugin fetch data on its own schedule, add a complementary interface that lets the plugin actively request specific data from the host.

For example, VS could expose an interface like this:

// Host-provided interface for plugin-initiated data requests
void requestHostData(string dataType, Action<string> onDataReceived);

How VA would use this: #

When VA needs to run "Find References" outside a right-click trigger (say, via a keyboard shortcut), it can call this interface to fetch exactly what it needs:

// VA requesting the currently selected symbol data
host.requestHostData("currentSelectedSymbol", (jsonResponse) => {
    // Process the JSON data to run the Find References logic
    executeFindReferencesLogic(jsonResponse);
});

The host processes the request, returns the relevant data in JSON/XML format via the callback, and the plugin proceeds with its logic. This keeps data transfer on-demand, not continuous.

2. Implement an Opt-In Event Subscription System #

Instead of constant push updates, let the plugin subscribe only to the specific events it cares about, and unsubscribe when it no longer needs updates. This balances the plugin's need for timely data with avoiding unnecessary overhead.

VS could expose these interfaces:

// Subscribe to a specific host event (e.g., cursor movement, document switch)
void subscribeToEvent(string eventName, Action<string> eventCallback);

// Unsubscribe when the plugin no longer needs updates
void unsubscribeFromEvent(string eventName, Action<string> eventCallback);

VA use case: #

VA might subscribe to the cursorPositionChanged event only when the user opens the right-click menu, then unsubscribe once the action is complete:

// Cache the callback instance to unsubscribe later
Action<string> cursorCallback = (positionData) => {
    cachedCursorPos = positionData;
};

// Subscribe when the right-click menu is opened
host.subscribeToEvent("cursorPositionChanged", cursorCallback);

// After running "Find References", clean up the subscription
host.unsubscribeFromEvent("cursorPositionChanged", cursorCallback);

This way, VA only gets updates when it actually needs them, avoiding constant data pushes.

3. Combine Caching with Incremental Updates #

For scenarios where the plugin needs to maintain a consistent state (like VA's symbol database), have the host push a full initial dataset once, then only send incremental updates for changes (e.g., new symbols added, document edits). Add a way for the host to notify the plugin when the cache is invalid (e.g., a new document is opened).

Example interfaces to support this:

// Get initial full dataset (e.g., current document's symbol table)
void getInitialData(string dataType, Action<string> onInitialDataReceived);

// Host triggers this when incremental changes occur
event Action<string> onIncrementalDataUpdate;

// Host notifies plugin when cached data is no longer valid
event Action onCacheInvalidated;

VA can cache the initial symbol table, apply incremental updates as they come, and refresh the full dataset only when the cache is invalidated. This minimizes data transfer while keeping the plugin's state up-to-date.

How These Fit With Your Original doSomething Interface #

Your existing doSomething is perfect for host-initiated actions (like the right-click menu trigger), while the above solutions cover plugin-initiated data needs. Together, they create a flexible, efficient integration that works for both host and plugin workflows.

内容的提问来源于stack exchange，提问作者Lucavin