How to determine if a Project is enabled for building for a given Configuration?

[bhehe]

I'm in a situation where I need to process on a project-by-project basis, and I've encountered a scenario where I have a project set to NOT be built via the Solution configuration for both Debug & Release.

Usually, I point the dotnet cli to the Solution and allow it to handle these types of matters, but in this case that doesn't work for unrelated reasons. So now as I iterate over the projects, I need to skip any that are not supposed to be getting built.

I've tried inspecting the Solution & Project objects (Nuke's own) and then for the Project's I've been peeking into the MSBuild project's properties trying to find something I could inspect there. I thought I had it when I found one called "Building" but that seems to always be false at the time I'm inspecting it.

When I look at the Configurations property on both the Nuke Solution & Project objects, that's just a string value saying that the configuration is defined - but no further metadata is present.

Any suggestions on a good way to implement a simple "IsBuildEnabledForConfiguration(string config)" type of helper method?

[bhehe]

I was focusing on inspecting all the Properties and failed to notice there is a true standalone property on the MSBuild Project object/type itself - IsBuildEnabled. I was expecting it to be part of the 'evaluated properties' so I kept focusing there.

Now the bad part - it doesn't seem to have the correct value. I've got 2 different projects set to not be enabled via the Solution for both configurations and I am passing in the Configuration value when I get the MSBuild project type from the Nuke project type.

Wondering if this is perhaps a bug; I'll peek at the source and see if I can find how it's getting the value but if this is coming from MSBuild itself and those native types and not Nuke I'm not sure why it wouldn't reflect the correct value.

[bhehe]

After peeking at the source code for Nuke, I was looking at the ProjectModelTasks and the ParseProject doesn't seem to include awareness of the Solution and therefore its configurations for each project (this was a very quick glance only, so maybe I'm just not seeing how it does that).

I'm thinking this may be a true bug in the sense that it wouldn't be accurate and something you could rely on.

[matkoch]

Build configurations are part of the Solution model. A project loaded through the Microsoft.Build package has no awareness of whether it's enabled for build or not in the solution it's included in.

What you need to do is put Solution.Configurations and Project.Configurations together, but there's no built-in functionality.

[bhehe]

Digging in and refreshing my own memory on what the SLN file contains, I think I see something I can inspect and come to the correct conclusion - but - it still seems like the available property (IsBuildEnabled) should have worked and perhaps it should be based on the same logic I'm looking to leverage in the interim.

What I see is in my SLN looks like the following:

-- Project that is configured to build:
{44594FF0-B01B-400D-8623-167AF47F5459}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{44594FF0-B01B-400D-8623-167AF47F5459}.Debug|Any CPU.Build.0 = Debug|Any CPU
{44594FF0-B01B-400D-8623-167AF47F5459}.Release|Any CPU.ActiveCfg = Release|Any CPU
{44594FF0-B01B-400D-8623-167AF47F5459}.Release|Any CPU.Build.0 = Release|Any CPU

-- Project that is NOT configured to build:
{096EB00B-0DC7-40F8-BD48-73355FAC2F0E}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{096EB00B-0DC7-40F8-BD48-73355FAC2F0E}.Release|Any CPU.ActiveCfg = Release|Any CPU

So, it appears that I could test for the presence or lack of for the configuration that includes the ".Build.0" suffix and when it's not present that means it's not to be built. I'm going to attempt to use an interim version based on the code below:

var isBuildEnabled = project.Configurations.Any( c => c.Key.Contains(configuration + "|") && c.Key.Contains("Build."));

[bhehe]

@matkoch thanks for the info; It does seem like the Project object has this awareness (somehow) since I could see the Configurations there and they do appear to be abiding by the Solution's configs. We are starting with the Solution object and then using a foreach(...) against Solution.Projects so that must somehow be making it work - for those that are built there's 4 items in the set versus the projects not set to be built only have 2.