Application, HostID, Proxy, and EntryPoint Associations

There are a variety of configurations possible between host applications, hostID's, proxies, and entry points.  Which configuration to use is a design decision which requires careful consideration, especially if you are deploying multiple applications bundled together or one application targeted at different user groups.  Below are some possible configurations to consider.

Scenario 1)     1 Host Application,  1 HostID,  1 Proxy,  1 Entry Point:
This is the simplest and most straight forward scenario.  The host application loads add-ins which are all written against the same proxy using the same entry point.  The HostItemProvider for this scenario is very simple because there is only one type to return.  The add-ins are created based templates using the same hostID, proxy, and entry point.  Multiple templates using the same entry point may be used, for example one template could be the "bare bones" variety generated by ProjectGen and another could be more robust including events already hooked up.

 

Scenario 2)     1 Host Application,  1 HostID,  1 Proxy,  Multiple Entry Points:
This setup builds on the first scenario but offers templates using different entry points, for example Application level and Document level templates.  The host loads the add-ins using a more complex HostItemProvider to determine which entry point type to return to the add-ins.  The add-ins are created based on templates using the same HostID and proxy, but different templates and entry points.  Each entry point must have at least one template to be used by add-ins.

 

Scenario 3)     1 Host Application,  1 HostID,  Multiple Proxies,  1 Entry Point:
This setup is similar to the second scenario but offers templates using different proxies, for example a SimpleOM proxy for basic users and a FullOM proxy for power users.  The HostItemProvider for this scenario is very simple because there is only one type to return; the difference in the object model exposed is in the proxy and does not affect the HostItemProvider.  The add-ins are created based on templates using the same hostId and entry point, but different templates and proxies.  Each proxy must have at least one template to be used by add-ins.

 

Scenario 4)     1 Host Application,  1 HostID,  Multiple Proxies,  Multiple Entry Points:
This is a somewhat complex setup which offers both different proxies and different entry points which can be used to make a variety of templates, for example a SimpleApplication and AdvancedApplication as well as SimpleDocument and AdvancedDocument templates (SimpleApplication would have "this" or "me" as an Application object and expose only a few parts of the object model, while the AdvancedDocument would have "this" or "me" as an Document object and expose a robust view of the object model).  The host application loads the add-ins written against different proxies and entry points.  The HostItemProvider would determine which entry point type to return based on the entry point type of the add-in, for example Application or Document, but not Simple or Advanced; therefore, the SimpleApplication and AdvancedApplication add-ins would be handled the same way by the HostItemProvider.  The add-ins are created based on templates using the same hostId but different templates using entry points / proxy combination.  Each entry point/proxy combination would need its own template to be used by add-ins. 

 

Scenario 5)     1 Host Application,  Multiple HostID,  1 Proxy,  1 Entry Point:
This setup is very similar to the first scenario, but uses different hostIDs.  Each hostID has its own templates which could be very similar, for example having the hostID as the only difference.  The host application loads add-ins which are all written against the same proxy using the same entry point but multiple hostIDs.  The HostItemProvider for this scenario is very simple because there is only one type to return.  Add-ins are loaded based on entry point types, not hostIDs, so it is possible for one application to load add-ins based on templates registered under different hostIDs so long as the entry point type for the add-in can be resolved in the HostItemProvider.  The add-ins are created based templates using the same proxy and entry point, but the templates are registered under different hostID's.   

IDE and template considerations for this scenario- Each hostID should use a different ProjectTemplatesLocations because the VSTA IDE is  HostID specific; therefore, projects for HostID_A cannot be opened in the IDE for HostID_B.  Also, a host application can only register as a debug host for one hostID at a time; multiple IDE's for different HostIDs cannot be displayed or managed by the same application concurrently. 

 

Scenario 6)     1 Host Application,  Multiple HostID,  Multiple Proxies,  Multiple Entry Point:
This complex setup is very similar to the fifth scenario, but using different multiple proxies and entry points like the fourth scenario.  Each hostID has its own templates which could be very similar, for example having the hostID as the only difference, or very different, for example using different proxies and entry point combinations.  The host application loads add-ins written against different proxies and entry points based on templates registered under different hostIDs.  The HostItemProvider would determine which entry point type to return based on the entry point type of the add-in.  Add-ins are loaded based on entry point types, not hostIDs, so it is possible for one application to load add-ins based on templates registered under different hostIDs so long as the entry point type for the add-in can be resolved in the HostItemProvider.  The add-ins are created based templates using different proxy / entry point combinations and registered under different hostIDs. 

IDE and template considerations for this scenario- Each hostID should use a different ProjectTemplatesLocations because the VSTA IDE is  HostID specific; therefore, projects for HostID_A cannot be opened in the IDE for HostID_B.  Also, a host application can only register as a debug host for one hostID at a time; multiple IDE's for different HostIDs cannot be displayed or managed by the same application concurrently. 

Error when a project based on a different hostID is opened in ShapeAppCSharp's IDE:

 

Scenario 7)     Multiple Host Applications,  1 HostID,  1 Proxy,  1 Entry Point:
This is a simple scenario which can be used by applications which share base types, including the base type which will be an entry point type (for example two applications which use the same Document type as the entry point).  The host applications load add-ins which are all written against the same proxy using the same entry point.  The HostItemProvider for this scenario is very simple because there is only one type to return.  The add-ins are created based templates using the same hostID, proxy, and entry point.  Multiple templates using the same entry point may be used, for example one template could be the "bare bones" variety generated by ProjectGen and another could be more robust including events already hooked up.

IDE and template considerations for this scenario- Multiple applications can concurrently display, manage, and debug IDE's for the same hostID (ex:  run two instances of the ShapeAppMacroRecordingCSharp sample at the same time).  Therefore, applications can share a hostID without "locking" the other application out of debugging.

Because both applications use the same HostID, they will share the same IDE and registry settings like ProjectTemplatesLocation, AppName, and UserFilesFolderName.  Therefore, the IDE cannot be customized through the default settings file to be different for each host application.  Also, all templates for the hostID will appear as choices in the IDE.  It is possible to refine this by storing the templates in subfolders under the ProjectTemplatesLocation.  For example the ProjectTemplatesLocation could be C:\MyApp\Templates with the sub folders VisualBasic and CSharp, and within these folders the template could be divided in folders like C:\MyApp\Templates\{VisualBasic, CSharp}\{App_A, App_B}; the templates would appear as choices under the sub folders. 

Project template storage and new project pane for templates stored as described above:


Posted Nov 17 2008, 04:54 PM by Melody

Comments

Melody wrote re: Application, HostID, Proxy, and EntryPoint Associations
on 11-18-2008 4:31 PM

Check out the sample that goes with this blog at www.summsoft.com/.../1470.aspx

Copyright Summit Software Company, 2008. All rights reserved.