VSTA solution debugger randomly fails to start

Latest post 09-07-2007 8:36 AM by alphaps. 20 replies.
  • 07-16-2007 9:26 AM

    VSTA solution debugger randomly fails to start

    Hi all,

    While integrating VSTA into my legacy COM app, I intend to start the DTE debugger programmatically. This would allow end users to set up breakpoints and do all the debugging stuff without having to press down F5 first from the DTE before running their macros.

    To start the debugger, I merely make the following MC++ call:

    _macroProject->DTE->Solution->SolutionBuild->Debug();

    (where _macroProject is my EnvDTE::Project^).

    From time to time, I get a VSTA error message box "The operation could not be completed". Some other times, it just works fine, and I can then stop the debugger by calling:

    _macroProject->DTE->Debugger->Stop(true);

    I do not get the conditions which make the call fail. It tends to work better if I first interactively start the debugger (F5) then retry it programmatically. Do you know whether SolutionBuild->Debug() is the right call or if maybe I should use any extra calls before it? I've tried Debugger->Go(true/false) but it does not work, and _macroProject->DTE->Solution->SolutionBuild->SolutionConfigurations->Item("Debug")->Activate() does not help either.

    What's more, according to the documentation, calling SolutionBuild->Debug() should be enough to select the "Debug" configuration, build it and start the debugger.

    I guess there could be a VSTA issue behind that with app. domains bad setup or add-in loading.

    Any better hint?

    Regards

    Alexandre

     

  • 07-16-2007 12:07 PM In reply to

    Re: VSTA solution debugger randomly fails to start

    Hi again,

    I solved a couple of issues and now I do not get this message ("The operation could not be completed") as often. Yet I still get it from time to time, but I am working on it with new ideas.

    If it may help somebody, I had issues with:

    • missing RegisterExternalDebugHost() calls before SolutionBuild->Debug(),
    • missing reactivation of the Release mode after Debugger->Stop(true),
    • RemoteObjContract object changing between Release and Debug modes (issue related to the Proxygen bypass)

    Alexandre

     

  • 07-16-2007 5:07 PM In reply to

    • Melody
    • Top 10 Contributor
    • Joined on 04-26-2007
    • Syracuse, NY
    • Posts 245

    Re: VSTA solution debugger randomly fails to start

    Alexandre- are you using Windows 2000?

  • 07-17-2007 4:38 AM In reply to

    Re: VSTA solution debugger randomly fails to start

    Nope - Windows XP Pro SP2 English.

     

     

     

  • 07-17-2007 10:04 AM In reply to

    • Melody
    • Top 10 Contributor
    • Joined on 04-26-2007
    • Syracuse, NY
    • Posts 245

    Re: VSTA solution debugger randomly fails to start

    Alexandre,

        There are several issues that could cause a VSTA message box "The operation could not be completed."  Most of them occur when using Windows 2000.  I attempted to reproduce the error on my machine (also XP SP 2 English) but was unable.  Could you send a sample or give more information?  One fix you may want to try is to first build, then wait (100), then debug.  If you check out the ShapeApp samples you will notice that they use a message filter that handles reject calls by waiting; however, the reject calls they handle are different than the message you are receiving (look at ShapeAppAdvancedCSharp MessageFilter.cs).

    -Melody

     

  • 08-02-2007 5:20 AM In reply to

    Re: VSTA solution debugger randomly fails to start

    Hi all,

    Indeed implementing a custom MessageFilter solved many problems. So far, I used try/catch blocks nested within for(int tries=0; tries<3; tries++) loops... really unclean and you cannot just add those loops everywhere.

    I added traces inside this MessageFilter implementation, and I realize the program runs through the IMessageFilter::RetryRejectedCall method a lot of times...

    So this is a good advice to implement such a MessageFilter, I recommend everyone to visit :

    http://msdn2.microsoft.com/en-us/library/ms228772(VS.80).aspx

    Within only 30 seconds of intensive use, my program went through the RetryRejectedCall() method 4 times!

    Many thanks to Melody.

    Alexandre

     

  • 08-02-2007 9:29 AM In reply to

    • Gary
    • Top 10 Contributor
    • Joined on 07-13-2006
    • Posts 318

    Re: VSTA solution debugger randomly fails to start

    Alexandre,  thanks for the helpful link!

  • 08-10-2007 9:55 AM In reply to

    Re: VSTA solution debugger randomly fails to start

    Gary, you're welcome.

    The TestCon VSTA sample mentions the following feature:

    "- Process-sync code to bring down VSTA when the process is killed (by closing the console window, Ctrl+Break, etc.)"

    I am very interested by this feature, yet I had no time so far to review thoroughly your TestCon sample and retrieve this particular feature from the code.

    Can you point me out to the relevant parts implementing this feature?

    When my host app crashes, its associated vsta.exe process remains on forever.

    I can see on Melody's blog that she's posted an interesting article about the MessageFilter issue. Maybe this other issue would also be of interest to other ppl.

    Thanks in advance!

    Rgds

    Alexandre

  • 08-10-2007 3:40 PM In reply to

    • Gary
    • Top 10 Contributor
    • Joined on 07-13-2006
    • Posts 318

    Re: VSTA solution debugger randomly fails to start

    A console process has its own list of application-defined HandlerRoutine functions that handle CTRL+C and CTRL+BREAK signals. The handler functions also handle signals generated by the system when the user closes the console, logs off, or shuts down the system.

    TestCon looks at CtRL-C signals.  At startup, a ControlHandler is setup by the TestCon host app to watch for Shutdown requests of the following types

            private static bool ControlHandler(Win32.ConsoleControlEventType ctrlType)

            {

                switch (ctrlType)

                {

                    case Win32.ConsoleControlEventType.CtrlC:

                    case Win32.ConsoleControlEventType.CtrlBreak:

                    case Win32.ConsoleControlEventType.CtrlClose:

                    case Win32.ConsoleControlEventType.CtrlLogoff:

                    case Win32.ConsoleControlEventType.CtrlShutdown:

                        if (mProgram.mVSTAHookup != null)

                        {

                            mProgram.mVSTAHookup.StopVSTA();

                            mProgram.mVSTAHookup = null;

                        }

                        break;

                }

                return false;

            }

    ...making sure that mVSTAHookup is released.

     

    As well, there is a public method exposed that allows the addin to shutdown in an orderly way, also making sure that mVSTAHookup is released:

     

           public void ShutDown()

            {

                if (mVSTAHookup != null)

                {

                    if (mDesignTime && mVSTAHookup.IsDTEVisible())

                    {

                        mVSTAHookup.StopDebugging();

                    }

                    else

                    {

                        mVSTAHookup.StopVSTA();

                        mVSTAHookup = null;

     

                        ReleaseControlHandler();

                    }

                }

            }

     

  • 08-20-2007 5:56 AM In reply to

    Re: VSTA solution debugger randomly fails to start

    Hi Gary,

    1- Thanks for the info, however it does not apply to my Win32 windows app. I guess I could catch the WM_ENDSESSION message, but I am afraid it will not be called upon a "hard kill", such as "End Process" from the task manager. It will not be called either when my app crashes, and hence vsta.exe will remain resident. Any idea regarding this?

    2- I also have another question about the COM events that VSTA exposes (via VS DTE). I use callbacks OnDocumentSaved and OnBuildDone to backup the sources and the compiled DLLs into a database. I also need to backup the .csproj/.vbproj when it is saved (for example when you add/remove a .NET reference to the project). However, I did  not find any suitable event that would be fired upon these modifications.

    Thanks a lot in advance,

    Alexandre

     

  • 08-20-2007 2:24 PM In reply to

    • Gary
    • Top 10 Contributor
    • Joined on 07-13-2006
    • Posts 318

    Re: VSTA solution debugger randomly fails to start

    For #1,  Have you looked at all the messages (especially last ones) when task manager kills the app?  I'm not sure what can be done for these scenarios, outside of a process observer that will kill the vsta.exe process created by the aborted application.  I will ask the VSTA team for any ideas beyond WM_ENDSESSION and WM_QUERYENDSESSION.

    For #2,  http://msdn2.microsoft.com/en-us/library/aa983653(VS.71).aspxshows that projects for each language have their own Exstensibility objects.  These are available from the DTE and provide you with Add/Remove Reference events: http://msdn2.microsoft.com/en-us/library/aa984593(VS.71).aspx 

    Regards, Gary

  • 08-22-2007 8:24 AM In reply to

    Re: VSTA solution debugger randomly fails to start

    Hi Gary,

    #1 Ok let me know when the VSTA team has answered.

    #2 These Add/Remove events are fired when you actually add/remove a reference, but not when the VSTA project is saved, so it does not really solve my problem which is to keep a consistent up-to-date database view of the actual VSTA project's projection on the hard disk. I suppose I could let that as is, assuming the user will eventually rebuild the project after the modifications, or save his source, and I am already updating the database view upon OnDocSaved and OnBuildDone.

    If I update the database upon OnReferenceAdded/OnReferenceRemoved, I will be sending to the database an unsaved/unchanged project, which is useless. Then, let's imagine the user saves the project and quits VSTA without further building/doc saving. In that case, the hard disk projection will be newer than the database view. As the hard disk projection is volatile (deleted upon exit), the user is facing the loss of his project's modifications.

    Possibly this will be flagged as a "known limitation" in my VSTA-enabled app!

    Best regards.

    Alexandre

     

  • 08-22-2007 9:36 AM In reply to

    • Gary
    • Top 10 Contributor
    • Joined on 07-13-2006
    • Posts 318

    Re: VSTA solution debugger randomly fails to start

    For #2, you're looking for a 'AfterProjectSaved' event.

    Maybe this combination would work:

    When Common Environment Object Model's 'Solution.BeforeClosing' event occurs call something like this altered MSDN example shows

    Imports VSLangProj
    Sub StoreProjectSaved(ByVal aVSProject As VSProject)
       Dim theProject As EnvDTE.Project
       theProject = aVSProject.Project
       If (theProject.Saved) Then
          ...store in database  

       End If
    End Sub

     

     

  • 08-22-2007 9:37 AM In reply to

    • Gary
    • Top 10 Contributor
    • Joined on 07-13-2006
    • Posts 318

    Re: VSTA solution debugger randomly fails to start

  • 08-22-2007 2:47 PM In reply to

    • Gary
    • Top 10 Contributor
    • Joined on 07-13-2006
    • Posts 318

    Re: VSTA solution debugger randomly fails to start

    Another approach would be to use an In-Process Host to persist the project when it closes...

    The lifetime of the in-process host is equal to the lifetime of the project. An in-process host is an add-in for the VSTA IDE project system that loads when the project is opened and unloads when the project is closed. 

    (ms-help://MS.VSCC.v80/MS.VSIPCC.v80/MS.VSSDK.v80/dv_vstasdk/html/6dcd5b9d-e692-4e9a-bf72-2d8965582aab.htm)

    For instance, the In-Process Host could cause a DTE event that would signal the host application to persist the project.

Page 1 of 2 (21 items) 1 2 Next > | RSS
Copyright Summit Software Company, 2008. All rights reserved.