locked
VisualStudio internal ProjectAutoToolboxManager seems to incorrectly implement IVsBuildStatusCallback RRS feed

  • Question

  • Hi,

    We have a VS Package that implements the IVsBuildableProjectCfg interface. It used to work fine with Visual Studio 2008 and 2010, but we noticed the build was always cancelled by one of the IVsBuildStatusCallback sink with Visual Studio 2012. This sink turns out to be the ProjectAutoToolboxManager class (located in the Microsoft.VisualStudio.Design.dll assembly). Apparently the version 11 ProjectAutoToolboxManager of Visual Studio 2012 implements IVsBuildStatusCallback (it didn't for VS 2008/2010) and the implementation of BuildBegin (http://msdn.microsoft.com/en-US/library/microsoft.visualstudio.shell.interop.ivsbuildstatuscallback.buildbegin(v=vs.110).aspx) method always returns false for the pfContinue parameter.

    This seems a bug to me. Can anyone confirm this?

    PS: In the mean time, the workaround for us is to ignore the IVsBuildStatusCallback implementation specifically for this class, but that's not very nice.


    Simon Mourier



    Monday, December 10, 2012 9:24 AM

All replies

  • I sent an e-mail to the person that owns this code, it does seem incorrect. They are out-of-office until Thursday and their message claims they have no access to e-mail, so it may be a few days. I will keep the thread posted.

    Ryan

    Monday, December 10, 2012 9:02 PM
  • Actually, looking a bit more at this I am somewhat confused. Here is the code for the ProjectAutoToolboxManager's BuildBegin method:

    int BuildBegin(ref int pfContinue)
    {
        // Since build is started we're not up to date so set IsUpToDate to false.
        IsUpToDate = false;
        return NativeMethods.S_OK;

    }

    So they never actually set pfContinue, which is fine, it is a ref param not an out param. I am unfamilar with this portion of code but who invokes these callbacks exactly? Is it the IVsBuildableProjectCfg? If so are you passing in an uninitialized bool (defaulted to false)? Or is someone else in the chain of callbacks setting it to false?

    Ryan

    Thursday, December 13, 2012 6:04 PM
  • Thanks for looking into this.

    Our package is similar to a C# or VB.NET package in the sense it supports the standard Build command. The way it works is this:

    * Other packages (such as ProjectAutoToolboxManager) register for build notifications using our implementation of IVsBuildableProjectCfg.AdviseBuildStatusCallback

    * The IDE calls our implementation or IVsBuildableProjectCfg.StartBuild when the Build command is executed.

    * Now, during our build, we call the sink's IVsBuildStatusCallback.BeginEnd for each sink.

    In fact when you look at the doc, it's sometimes referred as an out parameter (for example the VS 2012 doc: http://msdn.microsoft.com/fr-fr/library/microsoft.visualstudio.shell.interop.ivsbuildstatuscallback.buildbegin(v=vs.110).aspx)

    I suppose it comes from the fact it's origingally a native C++ interface. But you're right that it's a ref parameter in the VS 2008/2010 .NET interop assemblies.

    I suppose down the road, it's really a matter of convention. The doc clearly states this: "[in, out] Pointer to a flag that is set to true if the build process can continue and false if it should be terminated." It doesn't say how it should be initialized initially. Initializing to true is probably a better workaround than checking the type of ProjectAutoToolboxManager as we do today.

    ProjectAutoToolboxManager is a .NET implementation and a new IVsBuildStatusCallback implementer in the VS eco system, it may not follow other standard VS packages (C++/C#, etc.) :-)


    Simon Mourier



    Thursday, December 13, 2012 6:48 PM
  • Yeah, I suspect since it is ref in the interop that no one is enforcing its set state which means people are likely to diverge in what they actually do. I can file a doc bug with it claiming it is out, because it doesn't appear to be, it appears to be ref.

    I suspect it was in/out to allow a false to propagate if you kept calling the sinks, i.e. it would start as true and the only person that would ever set it would be someone toggling it to false, if they did so then people later in the chain would be called with pfContinue false and could 'do something' (if they had anything special to do on cancelled build). Of course that wouldn't help anyone that was called BEFORE the guy that set it to false, so it isn't really a compelling explanation :).

    Ryan



    • Edited by Ryan MoldenMicrosoft employee Friday, December 14, 2012 4:20 AM removed native example, found the recipient of the SendMessage was setting param
    Friday, December 14, 2012 4:13 AM