locked
IVsProjectUpgradeViaFactory where the new project type supports a different list of platforms that the old project type RRS feed

  • Question

  • Hi.

    I have noticed a bit of a problem when upgrading projects via their factory (a crash / hang, specifically).

    Our new project types support the "Any CPU", "x86", and "x64" platforms, but our old project type supported a single dummy plaform called "Standard".
    When opening an old solution which winds up calling into our IVsUpgradeProjectViaFactory implementation, we of course have to change the platforms to something we actually support now.

    The problem arises because the solution file has configuration information for the old platform (which is, of course, no longer returned by our configuration provider; we only return the 3 platforms above). This winds up causing an access violation in msenv.dll (I loaded the symbols from the Microsoft symbol server and it seems to be related to checking the active configuration).

    If I edit the solution file by hand, and replace "Standard" with "Any CPU", the upgrade is successful.

    Is this a known problem, and is there a workaround (besides manually upgrading the solution file)?
    I couldn't find anything on Microsoft Connect about it.

    Could I perhaps utilise the distinction between IVsCfgProvider2.GetPlatformNames and IVsCfgProvider2.GetSupported PlatformNames to allow me to return the "Standard" platform in such a way that it is never used?

    Thanks,

    Adam.

    Sunday, August 22, 2010 11:15 PM

Answers

  • It turns out you are supposed to return E_FAIL if asked for a configuration that does not exist (if you return S_OK, they assume the pointer you return points to a valid configuration object and you will get an access violation when they attempt to dereference it).

    I've been told that they will update the documentation so it mentions this.

    Monday, August 30, 2010 12:16 PM

All replies

  • I have submitted this to Microsoft Connect.

    https://connect.microsoft.com/VisualStudio/feedback/details/589189/visual-studio-crash-when-upgrding-a-project-whose-supported-platform-list-is-different-than-the-old-project-system

    Thursday, August 26, 2010 12:53 AM
  • Hello Adam,

    I notice that product group is working with you on this issue. It will be great if you can update resolution here if the issue is resolved. Thanks.


    Looking for TFS Hot Issues? Follow us at Twitter.

    Hongye Sun [MSFT]
    MSDN Subscriber Support in Forum
    If you have any feedback on our support, please contact msdnmg @ microsoft.com

    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Thursday, August 26, 2010 8:46 AM
  • Sure, will do.

    I think if this is a bug, then it's an old one. I seem to remember running into a version of it a long time ago (as far back as VS2005) when we first renamed the single platform supported by our project at the time.

    I think VS expects any platform listed in the solution file to be one of the ones returned by the project configuration provider (and simply doesn't handle the case where it doesn't).

    Thursday, August 26, 2010 11:18 AM
  • It turns out you are supposed to return E_FAIL if asked for a configuration that does not exist (if you return S_OK, they assume the pointer you return points to a valid configuration object and you will get an access violation when they attempt to dereference it).

    I've been told that they will update the documentation so it mentions this.

    Monday, August 30, 2010 12:16 PM