locked
Installing VSPackage causes some tabs in project designer to disappear RRS feed

  • Question

  • Hi All,

    I'm developing a VSPackage to provide Visual Studio integration for a binary post-processing tool my company sells. Basically, the package adds a new property page to the project designer, so that developers can set configuration-dependent properties for use with our tool.

    The package works great on our development and test machines, but some of our users have reported an issue where installing our package causes some of the tabs/pages in the project designer (C#) to disappear. Uninstalling our package brings them back unharmed. The problem affects both VS2008 and VS2010 (the two versions we support), and occurs on machines running various 32- and 64-bit flavors of Windows.

    I've combed over every line of code in the package, as well as the registry entries created by our installer, and nothing seems to be out of the ordinary. I've run VS with the /Log flag on an affected machine, and nothing unusual turns up in the activity log.

    The only correlation I've made is it's always the same tabs that go missing: Build, Debug, and Code Analysis.

    Does anyone have any ideas as to what could be causing this problem? Registry entries gone wrong on some machines? Maybe some weird SxS issue with .NET or COM? Maybe our package is loading a different version of some assembly referenced by the other tab packages, and causing them to break somehow? I'm completely baffled at this point, so any help, suggestions, or off-the-wall ideas would be much appreciated.

    EDIT: In case it matters for some reason, our package / property page isn't providing it's own project type. We're simply adding a property page to some existing project types.


    Monday, July 11, 2011 4:49 PM

Answers

  • Hi Yi,

    I ultimated traced the problem down to some weird behavior in how VS was loading VSPackages. Turns out, if you have a fresh install of VS, there (usually) won't be a "ConfigPropertyPages" key under (VS root)\Projects\(Project Type GUID). When this key isn't present, it seems that VS will load the Build and Debug tab packages by default; however, as soon as the key is created, that default behavior stops and the packages aren't loaded any longer.

    The only solution I could come up with was to have the installer for our software add the keys for the Build and Debug tab pages under the ConfigPropertyPages key so that VS would load them along with our software. Once I did that, everything worked just fine; so as not to change this behavior if it's expected by any other tools installed on the machine, I've set our installer to mark the created keys as permanent (so they won't be removed if our software is uninstalled).

    Hopefully this sheds some light on the situation in case anyone else runs into it in the future.

    Cheers,

    Jack

    • Marked as answer by Jack Pappas Wednesday, August 3, 2011 2:44 PM
    Wednesday, August 3, 2011 2:43 PM

All replies

  • Hello,

    I'm not sure what's the exact problem without knowing any detailed information of your package.

    As you said, you can not repro this issue from your side, and only few of the customers reprot this issue. Is there any common background from them? Is there any possible another third party packages leads this problem?

    Regards,

    Yi


    Yi Feng Li [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.

    Thursday, July 14, 2011 9:50 AM
  • Hi Yi,

    I ultimated traced the problem down to some weird behavior in how VS was loading VSPackages. Turns out, if you have a fresh install of VS, there (usually) won't be a "ConfigPropertyPages" key under (VS root)\Projects\(Project Type GUID). When this key isn't present, it seems that VS will load the Build and Debug tab packages by default; however, as soon as the key is created, that default behavior stops and the packages aren't loaded any longer.

    The only solution I could come up with was to have the installer for our software add the keys for the Build and Debug tab pages under the ConfigPropertyPages key so that VS would load them along with our software. Once I did that, everything worked just fine; so as not to change this behavior if it's expected by any other tools installed on the machine, I've set our installer to mark the created keys as permanent (so they won't be removed if our software is uninstalled).

    Hopefully this sheds some light on the situation in case anyone else runs into it in the future.

    Cheers,

    Jack

    • Marked as answer by Jack Pappas Wednesday, August 3, 2011 2:44 PM
    Wednesday, August 3, 2011 2:43 PM