Fix configuration handling in project system


We have a really bad separation between configuration-specific properties and non-configuration specific properties (thanks MPFProj...) that should be straightened out.


pminaev wrote Jun 4, 2014 at 7:27 PM

Zooba wrote Jan 2 at 5:01 PM

Zooba wrote Jan 2 at 5:15 PM

sun2sirius wrote Jan 7 at 1:02 AM

Support and use of configuration-specific properties in Python projects (issue 1502) is different than generic support of Project Properties API implemented by SharedProject. I vote for #1502 because we are having to maintain separate Python code that sets a bunch of environment variables for debugging, while it would be much better to set them in Debug configuration property window. But I also wanted to comment on the generic project support.

We use the SharedProject framework for our own non-Python project type and need the GetConfigurationProperty/SetConfigurationProperty methods work properly, maintaining the separate property spaces for each project configuration (issue 2826). It looks like SharedProject already has a good enough MSBuild-based implementation in place, and I was able to use it as is in our custom project type. The only caveat is timing - at some point after the project is loaded completely the above mentioned methods work OK, and the GetProperty method returns the right value based on the currently selected Active Configuration. But they do not work correctly at OnAggregationComplete or even at OnAfterOpenSolution time.

As was pointed out by pminaev in discussion 576529, the IVsSolutionLoadEvents.OnAfterBackgroundSolutionLoadComplete event is the time when MSBuild property methods work correctly. If this event is actually the right thing to use from the architecture perspective, then it would be good to add the IVsSolutionLoadEvents implementation to SolutionEventsListener.cs. It would be ideal if the above property methods worked correctly during the project load, but I am not sure if it is possible without reimplementation of some of the MSBuild functionality. At least the configuration-dependent property methods should fail rather than return misleading information until the correct data is available.