none
How to intercept the Visual Studio command execution event of Project Build/Rebuild RRS feed

  • Question

  • With reference to How do I intercept a Visual Studio command execution, I intercepted the events of VSStd97CmdID.BuildSln and VSStd97CmdID.RebuildSln successfully. But I am unable to intercept VSStd97CmdID.BuildProjPicker, VSStd97CmdID.RebuildProjPicker, VSStd97CmdID.BuildSel, VSStd97CmdID.RebuildSel, with which I want to intercept the event of project build/rebuild. 

    Even after I switch to intercept the events of VSStd2KCmdID.BuildOnlyProject and VSStd2KCmdID.RebuildOnlyProject, the interceptor still does not work. 

    Very interesting that if I use DTE2(EnvDTE80) instead of DTE(EnvDTE), no interceptor can work, including previously successful VSStd97CmdID.BuildSln and VSStd97CmdID.RebuildSln.

    Any idea? Thanks. 

    # I'm developing an add-in in VS2008.

     

    Wednesday, December 8, 2010 8:14 AM

Answers

All replies

  • Hi Liang,

     

    Thanks for your post.

    As the blog mentioned, this method can intercepting the command at the VS level.

    Which means only solution layer's command can be detected but project's command would be blocked.

    As I know, DTE.commandevents is global.

    For more information, please check http://msdn.microsoft.com/en-us/library/bb166180.aspx

    As a workaround, I suggest to try IVsRegisterPriorityCommandTarget Interface which can target to all commands except for addins',

    but it would lead a bad performance.

    Hope my suggestion help resolve your issue.

     

     

    Best Regards,

    Ziwei Chen

     


    Ziwei Chen [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by Liang Ye Monday, December 13, 2010 6:07 AM
    Friday, December 10, 2010 8:18 AM
  • >but it would lead a bad performance.

    To clarify, it can lead to degraded performance as the shell routes EVERY single command QueryStatus/Exec through every single registered priority command target before doing the 'normal' route.  This means if any priority command target is slow or doing dumb things then it slows the entire shell down.  This is bad as it becomes obvious at 'the worst times' like on menu drop, before showing a context menu, executing commands, etc... If your priority command target is written to quickly determine if the command it is being presented with is the one it wants then it shouldn't be terrible. Though lots and lots of 'quick' ones can be as bad as a single slow one.

    I have long wanted to add a way to register a priority command target and specify (up front) the handfull of commands you are interested in, that way the shell could not even bother calling your command target if the command in question wasn't in that list.  Unfortunately it hasn't 'met the bar' yet to implement :(

    Ryan

    Friday, December 10, 2010 5:07 PM
    Moderator
  • I would recommend using the DTE.CommandEvents to create a BeforeExecute (or AfterExecute) handler for the specific commands you want to intercept.

    Sincerely,


    Ed Dore
    Sunday, December 12, 2010 12:11 AM
    Moderator
  • @ Ryan and Ed: Thanks for your additional information.

     

    @ Liang: Do our replies help to resolve this issue?

     

    Best Regards,

    Ziwei Chen

     


    Ziwei Chen [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, December 13, 2010 2:43 AM
  • Thanks Victor, Ryan, Ed

    @ Ed

    In fact, the How do I intercept a Visual Studio command execution is just using EnvDTE.CommandEvents approach to intercept events. However, as Victor's comment, they can only take effect to VS level commands such as CleanSln, BuildSln.

    @Victor

    Now I know there is limitation for add-in to intercept command events. Thanks for your answer.

    Monday, December 13, 2010 6:07 AM