Dynamically creating flyout menus and commands in the Error List context menu (and potentially elsewhere) is a necessary capability for the result source services. Unfortunately the VS extensibility SDK doesn't provide a nice API for this purpose.
For menus, you specify the DynamicVisibility, DefaultInvisible, and TextChanges command flags. The latter indicates that you want the BeforeQueryStatus event to fire. Your handler for this event decides whether the menu should be displayed and what the text string is.
For commands (menu items, called "Buttons" in the .vsct table), it's even clunkier. You define one Button with the same command flags mentioned earlier, plus the DynamicItemStart flag. This indicates that the button can be followed by additional dynamically-created buttons, which are identified by sequential IdSymbol values.
Importantly, Menus cannot be dynamically created in code. Buttons can only be created via the above process. This means that everything has to be defined ahead of time in the .vsct file (think of them as placeholders). I have waffled on this but ultimately decided not to predefine a huge number of placeholders. If a future result source needs to create a complex menu structure, we can add more placeholders at that time. The GHAS service only needs one flyout for a handful (three currently) of buttons so I've only included one flyout menu, one child container group, and one DynamicItemStart button.
Because the service projects can't reference the Viewer project, the only way form them to request changes to the Error List context menu is via events. This is the best we can do right now but will improve once we break the Viewer project apart (https://dev.azure.com/mseng/1ES/_workitems/edit/2003961).
Another concession that will improve later: because the services can't reference the Viewer project, they can't know what a SarifErrorListItem is. To mitigate this, the SarifViewerPackage extracts the SarifLog object(s) and provides them to the service's Invoke handler(s). This issue will be resolved when the model classes are moved into a leaf project that can be referenced by both the Viewer and result source service projects.
Dynamically creating flyout menus and commands in the Error List context menu (and potentially elsewhere) is a necessary capability for the result source services. Unfortunately the VS extensibility SDK doesn't provide a nice API for this purpose.
Because the service projects can't reference the Viewer project, the only way form them to request changes to the Error List context menu is via events. This is the best we can do right now but will improve once we break the Viewer project apart (https://dev.azure.com/mseng/1ES/_workitems/edit/2003961).
Another concession that will improve later: because the services can't reference the Viewer project, they can't know what a SarifErrorListItem is. To mitigate this, the SarifViewerPackage extracts the SarifLog object(s) and provides them to the service's Invoke handler(s). This issue will be resolved when the model classes are moved into a leaf project that can be referenced by both the Viewer and result source service projects.