locked
SolutionContext.ConfigurationName set returns E_FAIL RRS feed

  • Question

  • I have the following code in a custom project based on MPF for Projects - Visual Studio 2010:
    EnvDTE.Project dteProj = CurrentProject();
    dteProj.ConfigurationManager.AddConfigurationRow("MyCustomConfig", "Debug", false);
    var solution = dteProj.DTE.Solution as EnvDTE90.Solution3;
    foreach (EnvDTE80.SolutionConfiguration2 solConfig in solution.SolutionBuild.SolutionConfigurations)
    {
      foreach (EnvDTE.SolutionContext solContext in solConfig.SolutionContexts)
      {
        if (dteProj.UniqueName != solContext.ProjectName)
          continue;
    
        //Returns E_FAIL 
        solContext.ConfigurationName = "MyCustomConfig";
      }
    }

    As you can see everything is pretty straight forward. I create a new configuration for my project and want to use it in a solution context. Setting the configuration name returns E_FAIL.

    Why is the assignment failing? What is the correct programmatic equivalent for selecting a project configuration for a project from the drop down in the Configuration Manager dialog box?

    Thanks


    Thursday, February 21, 2013 1:16 PM

All replies

  • Hi,

    The short answer: EnvDTE.Solution.SolutionBuild.ActiveConfiguration and EnvDTE.Project.ConfigurationManager.ActiveConfiguration

    The long answer: read my posts:

    The convoluted build configuration automation model (EnvDTE/EnvDTE80)
    http://msmvps.com/blogs/carlosq/archive/2008/08/29/the-convoluted-build-configuration-of-the-automation-model-envdte-envdte80.aspx

    and:

    The diagram of the convoluted build configuration automation model (EnvDTE/EnvDTE80) (Part 2)
    http://msmvps.com/blogs/carlosq/archive/2008/09/01/the-fiagram-of-convoluted-build-configuration-automation-model-envdte-envdte80.aspx


    MZ-Tools: Productivity add-ins for Visual Studio: http://www.mztools.com. My blog about developing add-ins: http://msmvps.com/blogs/carlosq/

    Thursday, February 21, 2013 10:05 PM
  • Hi,

    Thanks for the answer. I have already read your blog posts. It is how I learned about SolutionContext in the first place :).

    Regarding your suggestion, doesn't ActiveConfiguration  refers to the current configuration, the one that will be built? I'm trying to set the project configuration for all solution contexts.

    Also I have fiddled with the code a little bit and have discovered that if the newly created configuration is propagated to the solution, assigning it to the solution context does not fail.

    Any thoughts on this?

    Thanks

    Friday, February 22, 2013 8:02 AM
  • Has anyone encountered this before? Is it a bug in the extensibility framework?
    Monday, February 25, 2013 8:40 AM
  • Hi,

    I have reproduced the issue. While the user interface allows you to change the project configuration of a solution configuration, it seems that the automation model doesn't. I am not sure if it is a bug or a "by design" decision.


    MZ-Tools: Productivity add-ins for Visual Studio: http://www.mztools.com. My blog about developing add-ins: http://msmvps.com/blogs/carlosq/

    Monday, February 25, 2013 4:58 PM
  • I seems this is a BUG in the automation model fixed in VS 2012. 

    http://connect.microsoft.com/VisualStudio/feedback/details/545416/setting-the-solutioncontext-configurationname-does-not-work-to-set-the-solutions-project-to-a-new-configuration

    Any ideas how I can work around this issue?

    LE: I stand corrected. The issue is still present in VS 2012
    Tuesday, February 26, 2013 5:57 AM
  • I have been struggling with setting the solutionContext.ConfigurationName, and finally found that this does not work in at least VS2010 because of some bug. I managed to find a work-around for my use case and decided to share it here, hoping it might help others.

    My use case:

    - given a solution configuration "X"
    - given a project for which configurations "X" and "Y" exist
    - for which the project's configuration is set to "Y" 
    - and for which it should have been set to "X" instead

    The work around looks like this:

    var manager = project.ConfigurationManager;

    // First backup the currently active project configuration.
    manager.AddConfigurationRow("DummyHackWorkaround", "Y", false);

    // Now remove it.
    manager.DeleteConfigurationRow("Y");

    // The project configuration has now fallen back to "X" (which
    // was automatically selected based on the solution configuration.)
    // Now we can restore the configuration that was previously selected.

    manager.AddConfigurationRow("Y", "DummyHackWorkaround", false);
    manager.DeleteConfigurationRow("DummyHackWorkAround");


    Thursday, May 29, 2014 4:02 PM