Clojurians Log v2
clr
Feedback requested: Support for .NET 6.0 I'm working on delivering ClojureCLR on the soon-to-be-released .NET 10.0. The first step is just to make sure all support libraries are updated to the latest versions under .NET 9.0. This has created a dilemma regarding support for .NET 6.0. The primary issue: .NET 6.0 is out of support. See https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core. The latest and final patch was in November, 2024. This causes problems for delivering ClojureCLR on .NET 6.0. Possible solutions: 1. Drop support for .NET 6.0. - Risk: If you need .NET 6.0, you are stuck with the current version of ClojureCLR, no updates. 2. Deliver .NET 6.0 with up-to-date support libraries. - Risk: These libraries do not support .NET 6.0 and have not been tested with it. Probably they will work. 3. Deliver .NET 6.0 with .NET 6.0 compatible libraries. - Risk: Those libraries will not receive security updates either. Explanation of the issue: When I updated libraries to current versions (not yet dealing with .NET 10.0, though I have it installed), I started getting warnings. Sample:
warning : System.Text.Json 9.0.10 doesn't support net6.0 and has not been tested with it.
Consider upgrading your TargetFramework to net8.0 or later.
You may also set <SuppressTfmSupportBuildWarnings>true</SuppressTfmSupportBuildWarnings> in the project file
to ignore this warning and attempt to run in this unsupported configuration at your own risk.System.Text.Json as an example here for a reason: Versions 6.0 and 8.0 of this library had a CVE issued ( https://github.com/dotnet/announcements/issues/329 ).
That specific vulnerability did have a patch issued for both .NET 6.0 and 8.0. For .NET 6.0, that was done in the penultimate patch. In the future, there will be no attempt to deal with security issues that affect .NET 6.0.
If I continue to support .NET 6.0, the choices are:
- Use the latest libraries, which are not tested against 6.0.
- Compile ClojureCLR for .NET 6.0 using old, possibly insecure libraries.
I think I can accomplish the latter through careful conditionalization of project references.
(The challenge will be tracking down which libraries need to be conditionalized.
Most of the complaining libraries are actually transitive, not direct, dependencies.
I can't say I'm looking forward to the effort.)
At any rate, your feedback is requested and appreciated.
I like that Clojure generally supports a very wide range of versions (even though it's a maintenance burden for the core team, you specifically in this case). For full disclosure though I just use .NET 8 (and soon .NET 10) so I wouldn't benefit from extend .NET 6 support.
Related to this, would it help if there were CI builds available? I imagine testing various SDK combinations locally could do be tedious. I hacked together this GitHub Actions config based on the 'preparing a release' doc: https://github.com/jamesdavidson/clojure-clr/actions/runs/19067692563/job/54462275630
It would definitely help to have CI builds available. I just have never gotten around to it. Thanks for the nudge and the leg up. Support .NET 6 is not big burden. At some point likely I will run into something in some library that doesn't work. But if someone wants/needs to use .NET 6, the decision needs to be made: unsupported libraries or supported by untested libraries. Nothing I can do to get around making a choice.
It seems like for anyone that values security, they would already be on dotnet 8 at a minimum and would soon be moving to dotnet 10.
That's my thinking. But I've learned to ask.
Typed Clojure compiles under ClojureCLR! I've never been so happy to https://github.com/typedclojure/typedclojure/actions/runs/18849272293/job/53781493414#step:11:28:
ERROR in (class-path-elem-nilable-test) (:0)
expected: (do (typed.clj.checker.test-utils/tc-e (fn [x :- Object] (ann-form (class x) Class))) true)
actual: System.InvalidCastException: Unable to cast object of type 'System.IO.FileInfo' to type 'System.Uri'.
at clojure.lang.Delay.deref (:0)
clojure.core$deref.invokeStatic (:0)
clojure.core$deref.invoke (:0)
clojure.core.typed.current_impl/fn__11719fn__11730 (:0)
typed.cljc.checker.init$load_impl__92187.invokeStatic (:0)
typed.cljc.checker.init/load_impl (:0)
clojure.lang.Var.invoke (:0)
clojure.core.typed.load_if_needed$load_if_needed__91328.invokeStatic (:0)
clojure.core.typed.load_if_needed/load_if_needed (:0)
clojure.core.typed.load_if_needed$load_if_needed__91328.invokeStatic (:0)
clojure.core.typed.load_if_needed/load_if_needed (:0)
clojure.lang.Var.invoke (:0)
clojure.core.typed$load_if_needed__9625.invokeStatic (:0)
clojure.core.typed/load_if_needed (:0)
clojure.core.typed.test.class_path_elem_test/fn__86147fn__86152 (:0)I'm happy for you that it appears to be one point of failure in all those tests. 🙂
Yes! I'm having copilot do that drudgery while I design how to handle C# types.