-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] System.Collections.Immutable version constraint causing grief #170
Labels
bug
Something isn't working
Comments
austindrenski
changed the title
[BUG] System.Collections.Immutable versioning causing major source generator grief
[BUG] System.Collections.Immutable version constraint causing major grief
Jan 11, 2024
austindrenski
changed the title
[BUG] System.Collections.Immutable version constraint causing major grief
[BUG] System.Collections.Immutable version constraint causing grief
Jan 11, 2024
austindrenski
added a commit
to austindrenski/open-feature-dotnet-sdk
that referenced
this issue
Jan 11, 2024
austindrenski
added a commit
to austindrenski/open-feature-dotnet-sdk
that referenced
this issue
Jan 11, 2024
Fixes: open-feature#170 See: open-feature#136, open-feature#137, open-feature#170 Signed-off-by: Austin Drenski <[email protected]>
austindrenski
added a commit
to austindrenski/open-feature-dotnet-sdk
that referenced
this issue
Jan 11, 2024
Fixes: open-feature#170 See: open-feature#136, open-feature#137, open-feature#170 Signed-off-by: Austin Drenski <[email protected]>
austindrenski
added a commit
to austindrenski/open-feature-dotnet-sdk
that referenced
this issue
Jan 16, 2024
Fixes: open-feature#170 See: open-feature#136, open-feature#137, open-feature#170 Signed-off-by: Austin Drenski <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Observed behavior
Still trying to figure out all the triggering bits, but tldr; in a mixed-target solution (e.g.
net48
,net8.0
, andnetstandard2.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 fromMSBuild.exe
when certain MSBuild targets are used (seems to relate to the VS install and which task DLLs are loaded).where
SomeProject.csproj
:and
SomeProject.Generators.csproj
:and then
SomeProject.csproj
is eventually being used bySomeLegacyWebProject.csproj
: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 ofOpenTelemetry
andOpenTelemetry.*
packages, but just not withOpenFeature
.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
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) version8.0.0
or later ofSystem.Collections.Immutable
without breaking source generators.Steps to reproduce
No response
The text was updated successfully, but these errors were encountered: