[BUG] System.Collections.Immutable version constraint causing grief

[austindrenski]

Observed behavior

Still trying to figure out all the triggering bits, but tldr; in a mixed-target solution (e.g. net48, net8.0, and netstandard2.0), OpenFeature is breaking source generators when loading the solution in IDEs (e.g. both Rider and Visual Studio), as well as when building directly from MSBuild.exe when certain MSBuild targets are used (seems to relate to the VS install and which task DLLs are loaded).

CSC : error CS8784:
  Generator 'SomeGenerator' failed to initialize. It will not contribute to the output and compilation errors may occur
  as a result. Exception was of type 'FileNotFoundException' with message 'Could not load file or assembly 'System.
  Collections.Immutable, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
  The system cannot find the file specified.'.

[C:\a\dotnet\SomeSolution\src\SomeProject\SomeProject.csproj::TargetFramework=netstandard2.0]

where SomeProject.csproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFrameworks>netstandard2.0;net8.0</TargetFrameworks>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="../SomeProject.Generators/SomeProject.Generators.csproj" OutputItemType="Analyzer" ReferenceOutputAssembly="false" />
  </ItemGroup>

</Project>

and SomeProject.Generators.csproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="4.7.0" PrivateAssets="all" />
  </ItemGroup>

</Project>

and then SomeProject.csproj is eventually being used by SomeLegacyWebProject.csproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>library</OutputType>
    <TargetFramework>net48</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <!-- N.B. in reality this is a transitive reference coming from deep within the project graph -->
    <PackageReference Include="System.Collections.Immutable" Version="8.0.0" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="../SomeProject/SomeProject.csproj" />
  </ItemGroup>

  <Import Condition="Exists('$(VSToolsPath)/WebApplications/Microsoft.WebApplication.targets')" Project="$(VSToolsPath)/WebApplications/Microsoft.WebApplication.targets" />

</Project>

Now one look at SomeLegacyWebProject.csproj and the immediate reaction of any reasonable engineer is to blame the legacy of it all, but this project plays nice with all of the other modern components that we continue to shoehorn into it, including a whole slew of OpenTelemetry and OpenTelemetry.* packages, but just not with OpenFeature.

I hate opening issues without a minimal repro, so will keep trying to put one together and ping back here if/when I can, but hoping the nuances of reproducing my actual use case won't stymie making progress on resolving this, since I think it's fairly clear cut.

The primary issue is that OpenFeature flows this constraint onto consumers:

dotnet-sdk/build/Common.props

Line 27 in d0c25af

<PackageReference Include="System.Collections.Immutable" Version="[1.7.1, 8.0.0)" />

I would like to see the upper-bound of this constraint removed as was originally proposed in #136 since we're back here 6 months later as predicted by @toddbaert in #136 (comment).

See: #136, #137

Expected Behavior

I can reference OpenFeature from projects consuming (transitively or otherwise) version 8.0.0 or later of System.Collections.Immutable without breaking source generators.

Steps to reproduce

No response