Support for .NET Framework 4.7.1?

[Fabian-Schmidt]

Hello,

Is it possible to add .NET Framework 4.7.1 net471 as a supported target Framework?

I found the change from 4.6.1 to 4.7.2 - #406 - , but I did not see the technical motivation for it.

The .NET Framework 4.7.1 is still supported by Microsoft .

Thank you

[AliveDevil]

That's probably on me, partially.

At that time I was trying to fix NetWatcherService, which required upgrading the target framework to .NET 4.7.2 (System.Collections.Concurrent.ConcurrentDictionary.GetOrAdd-0))) Though that never got finished, and later replaced by native C interop. The upgrade from .NET 4.6.1 to .NET 4.7.2 dropped Windows Server 2008 SP2 and Windows 8 as supported systems, while .NET 4.7.2 is in-place upgradable on all supported systems with .NET 4.7.1.

What's stopping you from targeting .NET 4.7.2?

Conversation (2023-07-25)

``` [18:28]AliveDevil: upping the target framework to .net 4.7.2 isn't something you'd want to do, right? [18:28]wasabi: Maybe. I thought about it once. But didn't find a compelling reason. [18:29]wasabi: There wasn't any of the libraries we used that depended on > 4.6.1 [18:29]wasabi: What'd you find? [18:29]AliveDevil: I have one: https://learn.microsoft.com/en-us/dotnet/api/system.collections.concurrent.concurrentdictionary-2.getoradd?view=net-7.0#system-collections-concurrent-concurrentdictionary-2-getoradd-1(-0-system-func((-0-0-1))-0) D: [18:30]wasabi: I use that all over. One second. [18:30]AliveDevil: ConcurrentDictionary.GetOrAdd(Key, Factory, FactoryArg) has been added with .NET 4.7.2. [18:30]wasabi: Oh with an arg? [18:30]AliveDevil: probably without factoryarg [18:30]AliveDevil: using it to not create a closure [18:30]wasabi: Yeaaaah. [18:31]wasabi: Hmmm. [18:31]wasabi: There's only been a few cases where I needed a closure. [18:31]AliveDevil: I have no issue going with the closure-variant. [18:31]wasabi: Since Factory takes Key anyways. [18:31]AliveDevil: So: DotNetWatchKey key = keys.GetOrAdd(path, (path, c) => new DotNetWatchKey(path, c), this); [18:31]AliveDevil: this is DotNetWatchService. [18:32]wasabi: Yeah, I would not worry about the closure for that. [18:33]wasabi: I'm trying to think whether upgrading to 4.7 though would hurt anything regardless. [18:33]wasabi: Checking supported windows OS versions. [18:34]AliveDevil: losing windows 8 [18:34]wasabi: server r2? [18:34]AliveDevil: no, 2012 r2 and 2008r2sp1 is supported with .net 4.7.2 [18:35]AliveDevil: losing server 2008 SP2. [18:35]wasabi: 2008 R2 was one I wanted to keep back when I made the decision. [18:35]wasabi: Because I knew actual people still running it. [18:35]AliveDevil: https://learn.microsoft.com/en-us/dotnet/framework/migration-guide/versions-and-dependencies#net-framework-472 [18:35]wasabi: Not that those people used IKVM. Just, that I knew it still existed out there in the enterprise. [18:36]wasabi: Hmm. SP1 might be fine. [18:36]AliveDevil: R2 without SP1 wouldn't be supported. [18:37]wasabi: Yeah. That's not a whole new OS update though. I think it's reasonable to say "yeah, you gotta do an upgrade to SP1" to a customer. [18:37]wasabi: As opposed to "you gotta reinstall windows". [18:37]wasabi: I think I'm fine with this. [18:37]wasabi: Probably should look at Mono/Unity, and where that stands. [18:38]wasabi: Because I do want to fix that some day. [18:38]AliveDevil: They say .NET 4.7 is fully supported. https://www.mono-project.com/docs/about-mono/compatibility/ [18:38]wasabi: Welp, there we go. [18:38]wasabi: Yeah, I would be fine with a 4.7 upgrade on IKVM. [18:39]AliveDevil: The method I'm after is only available in 4.7.2 … So 4.7 doesn't cut it there. (Edited) [18:39]wasabi: Oh [18:39]AliveDevil: Unity has .NET Standard 2.1 compatibility though. [18:40]wasabi: https://www.mono-project.com/docs/about-mono/releases/5.18.0/ [18:41]wasabi: Sorta on unity. They have that available as a profile. They also have il2cpp I think which is a hacked mono [18:41]AliveDevil: The oldest (2021.3) supported unity release has .NET Framework 4.8 included. https://docs.unity3d.com/2021.3/Documentation/ScriptReference/ApiCompatibilityLevel.html (Edited) [18:41]wasabi: Awesome. That's good enough for me. [18:42]AliveDevil: Got introduced with 2021.2 [18:42]wasabi: Long enough ago. [18:42]wasabi: My impression is people keep reasonably updated with unity. [18:43]wasabi: Neither Mono nor Unity atually work with IKVM today. So this is mostly academic. But I'd like to fix that up at some point, so want to keep the option opne. ```

[Fabian-Schmidt]

Thanks for the quick response.

Unfortunately I must target 4.7.1 (or earlier) in my use case and cannot upgrade the hosting environment. I also find it undesirable to target such an old version.

[wasabii]

Yeah..... I honestly don't think I'm going to do this. We're actually using the factory method of ConcurrentDictionary elsewhere now. Not in many places. But I don't really want to compromise all that just to support a very old version of Framework.

The decision at the time was to support Framework versions that supported Windows versions could be upgraded too. So, 2008 R2, I believe, can be upgraded safely to .NET 4.7.2.

[wasabii]

Looks like 2008 R2 extended support ended too though. Heh.

[NightOwl888]

Just a thought - ConcurrentDictionary source is free for the taking (MIT) and probably fairly trivial to backport.

[wasabii]

Yeah. Well, that's what I mean by "compromise all that". Copying Framework source code into IKVM.

[Fabian-Schmidt]

Thank you for the detailed feedback. I wanted to check the motivation.

I must explore alternatives now.

[joniles]

Just to add another datapoint, I've just received a query about providing support for using MPXJ.Net (the version of MPXJ using modern IKVM) on .Net Framework 4.7.1.

that's what I mean by "compromise all that". Copying Framework source code into IKVM.

Would an approach similar to this package (https://github.com/OlegRa/System.DateTimeOnly), which makes DateOnly and TimeOnly available for use with .Net < 6.0 be workable? I haven't looked at the implementation of ConcurrentDictionary, but if it is feasible for the code to be extracted into a separate NuGet package would IKVM be able to make use of it to make support for 4.7.1 possible? I'd be happy to tackle creation of a package like this if it is useful and feasible.

[wasabii]

I would probably not agree to included third party polyfils as direct deps of IKVM.Runtime anyways. We already polyfil a few things ourselves: for instance System.Range and System.Index, so we can make use of those features internally on Framework. They don't get exposed to users. Adding a third party package into our dep tree is a hard sell. I've just managed to finally remove Mono.Posix for instance, and that was a big win.

I'm okay with some of hte light weight MS polyfils: like System.Buffers, System.Memory, Unsafe stuff, ValueTuple, etc. Supported by MS. Low impact. Of certain origin, etc.

I think the biggest problem is that none of these requests come with a timeline. When would we be committing to drop NET471? What date? Would we just pin to MS' extended support date? Would those users have upgraded by then, or would we be back in the same place? None of this is clear.

I'm also frankly a little suspicious of people who claim they can't upgrade .NET Framework, but are somehow clammering to upgrade to the latest IKVM version. :)

[wasabii]

Ya know, another window is open too: IKVM 8.6.4 did support NET461. IKVM.Maven.Sdk 1.5.5 release went with this.

IKVM itself has undergone major internal changes since then. But it's not like 8.6.4 no longer works. Can ya'll not just keep using that for now? I'd still take patches to 8.6.4 and do releases from that. And its not like people can't do that themselves either.

[joniles]

Thanks for the feedback, most helpful.

I think the biggest problem is that none of these requests come with a timeline. When would we be committing to drop NET471? What date? Would we just pin to MS' extended support date? Would those users have upgraded by then, or would we be back in the same place? None of this is clear.

It's tricky. The approach I'm taking is just to give clear advance notice (e.g. N months from now XYZ will no longer be supported in new versions of ABC), so hopefully end users will have enough runway to sort out their upgrades. I guess we may be having a similar conversation about IKVM and 4.7.2 at some point in future. Having said all that, the query about 4.7.1 support has come after I've given my end users given that notice...

Ya know, another window is open too: IKVM 8.6.4 did support NET461. IKVM.Maven.Sdk 1.5.5 release went with this

Interesting observation. I'd like to keep the "mainline" version of my package on the current version of IKVM.Maven.Sdk, but I can see the potential for packaging a (separate? combined?) 4.7.1 compatible version of my package while the versions of IKVM.Maven.Sdk are functionally equivalent. I'll have a think about what's feasible...