.NET Standard 2.0 / .NET Framework support?

[AvremelM]

Note

This is only about Facet, Facet.Attributes, and Facet.Extensions, but NOT Facet.Mappings or Facet.Extensions.EFCore.*

While Facet and Facet.Attributes target .NET Standard 2.0, it's not made clear anywhere if the generated code will compile/run in an application/library targeting .NET Framework or .NET Standard.
(Facet.Extensions targets only .NET8+, but some experimentation seems to indicate that it could easily target .NET Framework too. Of note, the Facet.Tests project targets only .NET10.)

So:

1. Is Facet intended to be consumable by .NET Standard 2.0 or .NET Framework projects?
   • It seems certain .NET APIs would need to be polyfilled by the consuming project, e.g., ReferenceEqualityComparer, IsExternalInit.
2. If so, would a PR that refactors the Tests project to multi-target net472;net10.0 be accepted?
   • (Of course, tests on Facet.Mappings.* and Facet.Extensions.EFCore.* would not be run for that target)

Edit: Pushed a proof of concept commit/branch. All tests building and passing (excluding those in UnitTests\Extensions\EFCore and UnitTests\Extensions\Mapping)

[Tim-Maes]

Hi @AvremelM

Currently, Facet does NOT support .NET Framework or .NET Standard 2.0 projects for consuming applications, even though the analyzer itself targets netstandard2.0.

The generated code uses System.Collections.Generic.ReferenceEqualityComparer which is only available in .NET 5.0+. If you try to use Facet in a .NET Framework 4.7.2 project, the generated code will fail to compile

As per Microsofts recommendation, I would probably choose the path of focusing on modern .NET stacks. Do you feel there is a need for Facet to have a broader enterprise legacy reach? Accepting such a PR though would indeed validate current compatibility issues

[AvremelM]

Thanks for the clarification. A few points I hope you'll consider:

• Many teams (including mine) have .NET Framework codebases that will remain so indefinitely. These are often mature, stable applications where migration isn't possible without a complete rewrite. For projects in this position, modern tooling like source generators represents one of the few ways to improve developer experience without requiring a full platform migration.

• If the Nuget package (for Facet and Facet.Attributes) targets netstandard2.0, consumers will reasonably assume the output is usable on that range unless stated otherwise. (The only place that indicates otherwise is hidden in a collapsed Features > Integration section in the README).

• The only blocker you cited (ReferenceEqualityComparer) is trivial to polyfill or replace behind an internal abstraction. If that’s the lone dependency pushing Facet into net5+, the restriction is more accidental than architectural.

  (For reference, here's the entire implementation of ReferenceEqualityComparer)

  // From (https://github.com/dotnet/dotnet/blob/main/src/runtime/src/libraries/System.Private.CoreLib/src/System/Collections/Generic/ReferenceEqualityComparer.cs), 
  // comments removed for readability 
  sealed class ReferenceEqualityComparer : IEqualityComparer<object?>, IEqualityComparer
  {
      private ReferenceEqualityComparer() { }
      
      public static ReferenceEqualityComparer Instance { get; } = new ReferenceEqualityComparer();
  
      public new bool Equals(object? x, object? y) => ReferenceEquals(x, y);
  
      public int GetHashCode(object? obj)
      {
          return RuntimeHelpers.GetHashCode(obj!);
      }
  }

(Facet.Mappings is blocked by IFacetMapConfiguration et al. which use static interface methods, which is not polyfillable at all)

---

If the intent is to remain modern-only, clearly documenting the effective minimum runtime (net8+ ?) in both the README and the Nuget package would prevent confusion.

But if you're open to the idea, I'm genuinely willing to contribute a PR that:

• Adds net472 as a target to Facet.Attributes, Facet.Extensions, and Facet.Tests
  • Refactors the Tests project to isolate Mappings/EFCore tests/DTOs so they don't interfere with the net472 target
  • Polyfills missing test dependencies (like Random.Shared) via the Polyfill package
• Adds a source-generated polyfill for ReferenceEqualityComparer in the Facet generator itself, emitted wrapped in an #if !NET5_0_OR_GREATER

This approach would maintain the current experience for modern targets while enabling legacy platform support, without adding runtime dependencies.

Would you be open to reviewing such a PR? I understand if the answer is no, but I wanted to make the case that there's real value here, and that the majority of Facet's functionality is 99% there already.

[AvremelM]

(Also, FWIW, I actually have a proof of concept building and running on my local machine already)

[Tim-Maes]

OK so you made a pretty convincing case there, can be implemented at low cost and provides a sulotion for a legitimate use case. I lean toward accepting this proposal.

Technical implementation sounds good, and it does remove the confusing mismatch between analyzer target and runtime reqs. Are you willing to maintain the support for NET framework?

Thanks for your time and efforts already!

[AvremelM]

Thank you!

Are you willing to maintain the support for NET framework?

Sure. I'm certainly happy to maintain/contribute if and when this makes it in.
(Especially when/if my team begins actually consuming this library in our codebase.)

---

I realized there was an unresolved question in the Tests project (which I confess I didn't consider thoroughly enough before, despite getting it running and tests passing locally).

• Ideally, a user installing Facet shouldn't need to add any polyfills themselves.
• Thus net472 test code also shouldn't add any polyfilling at all
• If we add code to Facet's generated output that requires polyfills under netstandard2, net472 tests should break so we see it.

Problem: Right now there are lots of things in the Tests project that need extra polyfills to compile for net472 (e.g., Random.Shared).

Possible solutions (ordered from least to most effort/robustness):

1. Don't worry about it until it becomes a problem (right now generated code only needs ReferenceEqualityComparer and we plan to have Facet polyfill that)
2. net472/netstandard2.0 package declares explicit dependency on Polyfill nuget package (as does the Tests net472 target)
3. Test fixturing could be split off into a separate netstandard2.0 library project so it compiles with any polyfills as internal but doesn't expose them to the actual Tests project.
   1. Means no new .NET features can be used in the Tests project (at least for code that needs to be compiled for net472)
4. Facet/Facet.Attributes/Facet.Extensions gets split into a (single) separate test project with fixtures/factories/etc. that use no non-netstandard2 features. Code shared between those tests and EFCore/Mapping tests gets moved to a shared netstandard2.0 library like #3 above.

I'd probably lean toward 3 or 4, as they seem the most 'correct' to me. But if you have a different preference or want to explicitly rule out some of these options, please share.
I realize 3 and 4 would enlarge the cost of this PR, and that might affect your decision here a bit.

[AvremelM]

(Added POC commit/branch)