Add-in Management Options

There are many different ways to manage add-ins.  Below are some common add-in management styles which can be used alone, combined, or used side by side. 

1)      Basic:  all interactions between the host and add-ins are executed in the Startup and Shutdown methods of the add-in.  This is demonstrated in the ShapeAppBasicCSharp SDK sample.

         Pros:  Easy.

         Cons:  Not very flexible.  Repeatedly loading and unloading add-in can cause increase in memory usage.

2)      On Demand:  interactions between the host and add-ins occur when the host calls into methods in the add-ins.

         Pros:  Code executed only when needed.

         Cons:  Requires more management code and invoke calls to execute a method in the add-in are time consuming.  Repeatedly loading and unloading add-in can cause increase in memory usage.

3)      Macro:  a single add-in project is loaded and displayed in the DTE and methods may be created during execution of the host either by the end user adding code or through macro recording with the host.  Host then calls into “macro” methods within the add-in project to be run or debugged into.

         Pros:  Can create, debug, and run code on the fly.  Allows for macro recording and offers a VBA like experience.

         Cons:  Requires more management code, a design time integration, and macro recording code.  Invoke calls to execute a method in the add-in are time consuming.  Repeatedly loading and unloading add-in can cause increase in memory usage.

4)      Event Oriented:  add-ins hook into host events and execute code when a host event is fired.

         Pros:  Easy.  Responding to events in the host is less time consuming than invoke calls.

         Cons:  Must unhook all events prior to unloading the add-in.    Repeatedly loading and unloading add-in can cause increase in memory usage.

5)      Service Oriented:  add-ins register services with a host which can be used by other add-ins.  This is based off a blog by Sandeep Bhatia.

         Pros:  Very flexible. 

         Cons:  Requires some management code and shifts some of the complexity from the host to the add-ins and separate assemblies.

6)      Super Add-in:  a single add-in contains multiple units of functionality (where each unit could be isolated in an individual add-in).  The host makes calls into the add-in to hookup or unhook individual units of functionality.

         Pros:  No increase in memory usage due to repeatedly loading and unloading add-ins because only one add-in is loaded.

         Cons:  Requires more management code and invoke calls are time consuming.

 

With any of the above styles the add-ins can be loaded and unloaded different ways:

1)      Host Centric:  The add-ins are loaded at the beginning of host application execution and are unloaded when the host terminates.  This is demonstrated in the ShapeAppBasicCSharp SDK sample.

2)      Document Centric:  The add-ins are loaded when a specific document is opened, and unloaded when the document closes.  This is demonstrated in the ShapeAppDynamicProgrammingModelCSharp SDK sample.  Note that non-DPM add-ins can also be used in document centric ways as was shown in the VSTA v 1 SDK samples with the drawing  entry point.

3)      On Demand:  Add-ins are loaded and unloaded during execution of the host application as needed or requested by the user.  This is demonstrated in the ShapeAppMacroRecordingCSharp SDK sample when the macro add-in is unloaded and reloaded during the macro project build cycle.  This can be host or document oriented.

 

Any of the above styles of add-in management may also be used with different styles of integration:

1)      SDK:  A proxy is used and the VSTA pipeline is used for interactions between the add-ins and host.   This style of integration is used in all SDK samples

2)      NoRuntime:  No proxy is used, instead the add-ins reference the host directly and the VSTA runtime is not referenced or used.  This style of integration is used in the Microsoft ShapeAppMacroRecordingCSharp-NoRuntime sample available from Summit upon request (must fill out information form).

3)      NoRuntimeProxyShim:  A proxy shim, which defines only the entry point types, is used along with a direct reference to the host.  The VSTA runtime is referenced, but not used.  This style of integration is used in the ShapeAppMacroRecordingCSharp-NoRuntime-ProxyShim sample which is available from Summit upon request (must fill out information form).

 

 


Posted Aug 24 2010, 02:50 PM by Melody
Copyright Summit Software Company, 2008. All rights reserved.