[Feature Request] Add Support for MSBuild Conditionals and Properties.

[dellis1972]

It would be very handy to be able to use MSBuild Conditional statements and MSBuild Properties within the slnx file.
This would allow for conditional inclusion or exclusion of projects and also to allow paths to dependent projects be configurable.

<Solution>
  <Configurations>
    <Platform Name="Any CPU" />
  </Configurations>
  <Project Path="C\C.csproj" Condition="Exists('C\C.csproj')" />
  <Project Path="B\B.csproj" />
  <Project Path="A\A.csproj">
    <BuildDependency Project="B\B.csproj" />
    <BuildDependency Project="C\C.csproj" Condition="Exists('C\C.csproj')"/>
  </Project>
</Solution>

or

<Solution>
  <Configurations>
    <Platform Name="Any CPU" />
  </Configurations>
  <Project Path="$(PathToC)\C.csproj" Condition="Exists('$(PathToC)\C.csproj')" />
  <Project Path="B\B.csproj" />
  <Project Path="A\A.csproj">
    <BuildDependency Project="B\B.csproj" />
    <BuildDependency Project="$(PathToC)\C.csproj" Condition="Exists('$(PathToC)\C.csproj')"/>
  </Project>
</Solution>

[teo-tsirpanis]

See #123 (comment) for reasons why adding non-trivial parsing logic to solutions is not a good idea and might never be done.

Could you expand on your use case? Why does C.csproj might or might not exist?

[dellis1972]

A couple of use cases I have come across.

1. Maintaining a cross platform project which has project that target netX.0-windows means if those projects are in the sln file (or slnx) it won't build on a mac or linux, you either have to remove the project or maintain two solutions. On large projects this can cause issues since developers forget to add new projects to one or the other.

<Project Path="$(PathToWindowsApp)\WindowsApp.csproj" Condition=" '$(OS)' != 'Unix'"/>

2. Wanting to switch out PackageReferences for ProjectReferences to debug issues. This is trivial for MSBuild, however you do need to edit the solution to get to get intellisense etc.

[teo-tsirpanis]

1. I just tried to build a Windows app on WSL, and got error NETSDK1100: To build a project targeting Windows on this operating system, set the EnableWindowsTargeting property to true. [/mnt/c/Users/teo/code/win-app/win-app.csproj], which means that it is possible to do it. Either way, solution filters seem like a better way of excluding specific projects.
2. For this case, editing the solution does not look like an unreasonable thing to do, whether the use of the project is a temporary change in the local development tree, or something more permanent.

[richardstanton]

This was out of scope for the original slnx format. We decided to not include MSBuild evaluations in the initial implementation for a few reasons. It added complexity to the code, where the original goal was to reduce merge conflicts with the .sln format. However, and new feature added to the file format would need to be supported by all of the components that consume them. This requires coordination and feature work for multiple teams.

[barrywimlett]

using git submodules to include source projects for dependent nuget packages

I want to disable projects in the solution
<Project Path="$....\SomeLibrary.csproj" Condition=" '$(Configuration)' != 'Release'"/>

so I can't reference them in other projects

<ItemGroup Condition=" '$(Configuration)' == 'Release'" >
<PackageReference Include="SomeLibrary" />
<ItemGroup />
<ItemGroup Condition=" '$(Configuration)' != 'Release'" >
<ProjectReference Path="$...\SomeLibrary.csproj" />
<ItemGroup />