Summit Software

Hello again ;-)

Still working on the VSTA integration V1.0 (are there any news about release date for v2.0?) into our software. I got a new issue:

I'm using more than one addin to enhance the application. The addins are loaded and unloaded during runtime of the application, depending on the data the end user works on. This works perfekt. The user is able to debug the addins loaded from the VSTA IDE. Therefore for each addin there is an object instance of a management class, managing the adin an the event calling inside the addin. Each instance calls

    m_HostDebugUri = ExternalDebugging.RegisterExternalDebugHost(this);

to register itself for the debugging. This class implements the OnDebugStarting() event and is called from the VSTA framework when debugging starts and loads the addin into the debug context. The instances of the management class write the information which addin they manage and the m_HostDebugUri to a table, so when the user starts debugging inside the VSTA IDE, the corresponding HostDebugUri is set in the VSTA IDE via a hook in the Command handler for the debugging command. So the user is even able to debug more than one addin parallel using more than one VSTA IDE. This works also perfekt, I'm able to debug more than one addin in parallel.

The problem is the following, everything works well up to the pojnt when the first addin is unloaded and the management class calls

    ExternalDebugging.UnregisterExternalDebugHost(m_HostDebugUri);

After that step the debugging does not work anymore for the remaining addins and also for new loaded addins which are registering a new ExternalDebugHost. The OnDebugStarting() event is correctly called from the VSTA framework but when one tries to load the addin into the debug context the error "System.Reflection.TargetInvocationException: System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> System.Reflection.TargetInvocationException: System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> System.Runtime.Remoting.RemotingException: The requested object is not registered in the running object table." occurs.

When I remove the ExternalDebugging.UnregisterExternalDebugHost(m_HostDebugUri); calls from the addin unload code everything continues to work correct but with the ROT-Viewer I can see that the number of VSTA entries in the ROT table grow and grow with each addin loaded and unloaded. When the application is closed, all entries in the ROT table are removed but I don't have a good feeling about filling the ROT table with an unlimited number VSTA entries until program termination.

Do you have any idea how to unregister an ExternalDebugHost from a process without stopping the debugging to work for other addins in the same process?

Hello Thorsten!
>any news about release date for v2.0?
The beta is available, but no news on the RTM date yet.

>This works also perfekt, I'm able to debug more than one addin in parallel.
Great!  If you'd like to show off your IDE management send it to VSTAsupport@summsoft.com, I'd love to take a look.

In the SDK, the ExternalDebugging.UnregisterExternalDebugHost Method has the following description:
Notifies Visual Studio 2005 Tools for Applications that an application no longer supports debugging add-ins in an external process.

I take this to mean that this call works on the host application, not the specific instance of VSTA used in debugging.  Therefore, you do not want to use this call when there are muliple intances open to close one.  Out of curiosity, do the different instances of VSTA have differnt M_HostDebugUri's?

>I can see that the number of VSTA entries in the ROT table grow and grow with each addin loaded and unloaded.
Does unloading an add-in create a new entry in the ROT?  I would expect that the entry would remain, but not that a new one was created.

When an add-in is unloaded do you quite the DTE (this.dte.Quit();) for that add-in?  If doing this from the host is not removing the entry from the ROT you may want to try doing it from an In Process Host.  Here is a link to our In Process Host sample which removes the VSTA entry from the ROT when the host application is "hard" shutdown.  You could adapt this IPH to check if the DTE is visible (or some other flag) and quit it from the IPH.

 

FYI- in VSTA v 2 beta external debugging does not add an instance to the ROT and there is no ExternalDebugging.UnregisterExternalDebugHost Method.

 

Hope this helps!  Please let me know if there's anything else we can do for you.
-Melody

Hi Melody,

Melody:

Great!  If you'd like to show off your IDE management send it to VSTAsupport@summsoft.com, I'd love to take a look.

Out of curiosity, do the different instances of VSTA have differnt M_HostDebugUri's?

Well, it's not very sophisticated. I have an instance of a management class for each loaded addin. The management class implements the ExternalDebugHost interface. When the addin is loaded, the RegisterExternalDebughost method is called with the pointer to the instance of the management class and the returned HostDebugUri (different for each instance of the management class) is written in a local data table. I have a management class for the VSTA IDE, so one can open multiple instances of the VSTA IDE with the different addins.  The IDE management class hooks the  command buttons in the IDE for debugging. So when the user wants to debug an addin, the management class looks the addin up in the local data table to get the HostDebugUri (and marks it as blocked). This HostDebugUri is set into the IVstaHostAdapter.SetDebugInfo of the VSTA IDE and the debugging is started.

So in short, I get an HostDebugUri for each addin I load and when the user opens IDE's with some of the addins, the IDE is provided the matching HostDebugUri for debugging. This mechanism is generic, so it should be possible to debug an unlimited number of addins in parallel.

Melody:

In the SDK, the ExternalDebugging.UnregisterExternalDebugHost Method has the following description:
Notifies Visual Studio 2005 Tools for Applications that an application no longer supports debugging add-ins in an external process.

I take this to mean that this call works on the host application, not the specific instance of VSTA used in debugging.  Therefore, you do not want to use this call when there are muliple intances open to close one.  

Ok, thanks for the confirmation.

Melody:

Does unloading an add-in create a new entry in the ROT?  I would expect that the entry would remain, but not that a new one was created.

You are right, there is one entry created for each addin loaded.

Melody:

When an add-in is unloaded do you quite the DTE (this.dte.Quit();) for that add-in?  If doing this from the host is not removing the entry from the ROT you may want to try doing it from an In Process Host.  Here is a link to our In Process Host sample which removes the VSTA entry from the ROT when the host application is "hard" shutdown.  You could adapt this IPH to check if the DTE is visible (or some other flag) and quit it from the IPH.

I checked the example, it might be an option for me to remove the ROT entries directly from the ROT instead of using UnregisterExternalDebugHost, I'll check this. If this is no option I think I will just implement a pool management of the addin management classes, so each instance of the management class once created and registered in the ROT will be put back in the pool for use with the next addin instad of destroying the object instance. So I won't nett the Unregister call and also no unlimited number of entries are created in the ROT over time.

Melody:

FYI- in VSTA v 2 beta external debugging does not add an instance to the ROT and there is no ExternalDebugging.UnregisterExternalDebugHost Method.

Hope this helps!  Please let me know if there's anything else we can do for you.
-Melody

I looking very forward to VSTA 2, but I need a release version before I can migrate...

Thanks Melody, you have been very helpful, as always.

  Thorsten