Breaking Change Disscussion: .NET 4.5 Support

[Mike-E-angelo]

Currently ExtendedXmlSerializer supports .NET Framework 4.5.

This is not ideal as it essentially forces two builds for every release: .NET 4.5 and everything else.

I wanted to start a discussion around this if anyone is still using .NET 4.5 and if this is used in any capacity with ExtendedXmlSerializer.

The idea is that we could bump the ExtendedXmlSerializer package to 2.2.x and make ExtendedXmlSerializer a strictly .NET Standard 2.0 library, which would support 4.6.1 as a minimum baseline.

If you absolutely require 4.5, you would have to force your dependency to the last version of ExtendedXmlSerializer 2.1.x (and pray you don't run into any bugs).

I am open to discussion around this and welcome any comments. Speak now or forever hold your peace. 😆

[Mike-E-angelo]

Looks like 4.5.1 and below is unsupported, so this is really about any projects that use 4.5.2 and 4.6:

https://github.com/Microsoft/dotnet/blob/master/releases/README.md

[WojciechNagorski]

I'm going to send some information next week. It is not so easy because of the issue in Full dotnet.

[Mike-E-angelo]

Yeah? I guess I would have to see it. I was able to remove it without any problems, all tests pass here:

https://github.com/Mike-EEE/ExtendedXmlSerializer/tree/dotnet461

It's basically removing the net45 from the ExtendedXmlSerializer

https://github.com/Mike-EEE/ExtendedXmlSerializer/blob/dotnet461/src/ExtendedXmlSerializer/ExtendedXmlSerializer.csproj#L8

and replacing net45 with net461 in ExtendedXmlSerializer.Tests:

https://github.com/Mike-EEE/ExtendedXmlSerializer/blob/dotnet461/test/ExtendedXmlSerializer.Tests/ExtendedXmlSerializer.Tests.csproj#L5

[WojciechNagorski]

https://weblog.west-wind.com/posts/2019/Feb/19/Using-NET-Standard-with-Full-Framework-NET

[WojciechNagorski]

dotnet/standard#514

[Mike-E-angelo]

OK, so it seems like additional DLLs in the output folder is the primary inconvenience for .NET Framework 4.7.1 and below.

So, a hassle with extra assemblies, but still works. I understand how that can be annoying to someone who is being mindful of disk space and utilized overhead.

That stated, as time goes on, the greater the chance a 4.7.1 and lower SLN incorporating a .NET Standard project only increases, leading to the inevitable (and annoying) inconvenience.

Personally, I do not find that annoying and am only glad that it works. 😁 Of course, I am using .NET Core these days and have given up .NET Framework for some time now.

Along those lines, my thought on this is that the .NET Framework is being phased out in favor of the new NEW (😆) .NET 5. With that in mind, we should keep this issue open with high (pinned) visibility and then revisit in one year.

That should give plenty of time for a sample of those who use .NET Framework 4.7.1 and lower to respond to this issue.

At which point we can analyze the current IDE and .NET landscape to determine if it's a "big deal" or not to go .NET Standard 2.0-only.

Sound good?

[WojciechNagorski]

Disk space is not the biggest problem. Let's imagine that someone has a program in full .net framework with an installer. After installing ExtendedXmlSerializer, the installer will have additional MB more. Quest what he will do? He will uninstall ExtendedXmlSerializer and he solves the problem in a different way.

[Mike-E-angelo]

Yeah? I would still classify that as a disk space problem. The more time that passes, the more common this will be, so those who use 4.5-4.6.1 will encounter this more and more (with other packages not ExtendedXmlSerializer), and eventually will migrate to 4.6.2 (especially if they are on 4.6.1!) to reduce the number of redundant dependencies on disk.

Is my hunch. 😁

I still say we wait a year to see if anyone who is using 4.5-4.6.1 to contribute to this discussion.

We currently have 64 GitHub repos that use EXS... is there a way to see which framework they are using? That would be a good sample set to start analyzing.

[WojciechNagorski]

It is not only a local disk space problem. Programs are built on some CI server so, they are saved on a shared disk. These installers are sent over the network, so there is also a network issue. The next problem is the time of sending.

Some people want to have also a clean bin directory. After installing .Net Standard in .Net Framework library you will get https://weblog.west-wind.com/images/2019/Using-.NET-Standard-with-Full-Framework-.NET/AssemblyHell.png

(picture from https://weblog.west-wind.com/posts/2019/Feb/19/Using-NET-Standard-with-Full-Framework-NET)

I think that we can remove .Net 4.5 but we should publish .Net 4.6(.x) version also.

[Mike-E-angelo]

Some people want to have also a clean bin directory

I understand that. I am one of them. 😁 Or at least, I understand the unnecessary .dlls. That image was my takeaway from that blog article when you shared it earlier, too. It's quite striking!

I think that we can remove .Net 4.5 but we should publish .Net 4.6(.x) version also.

Technically this is the right thing to do as net45 is officially no longer supported by MSFT. However, this leaves us in the same spot as we are now of having to support two versions of ExtendedXmlSerializer when ideally we should only have one in netstandard2.0.

Here's the table, actually:
https://dotnet.microsoft.com/download/dotnet-framework

Seems that 4.5.2 is the earliest that is supported.

We could bump from net45 to net452, which would protect 4.5.2-4.6.1 from AssemblyHell.png. 😆

However, I would still like to move to netstandard2.0 only at some point which would reduce the complexity of our project.

Let's keep this issue open for a year and find out. I would love to know how many users are on 4.5.2-4.6.1.

[Mike-E-angelo]

Thinking about this more, let's table this discussion until we see how .NET 5 and the new tooling fares out. Maybe they might find a way to get around the dll include hell for .NET Framework which makes this a non-issue.

One can hope. 😆

[MagicAndre1981]

.NET Framework 4.5.2, 4.6, 4.6.1 will reach End of Support on April 26, 2022, so end is near.

Your dependency Sprache will drop 4.5, too with their version 3.0.

[Mike-E-angelo]

Dang, a better memory than I @MagicAndre1981! So essentially we become a .NETStandard-only library at this time, I would take it. I'm OK with this as it would greatly simplify our test suite. Still feels a little wrong chopping it all away, though.

I guess technically that's a non-issue. Conceivably, we would bump the major version (4.0.0), so those who still need to use .NET Framework can still use the 3.x found on nuget.

In any case, please do feel free to open a new issue around that time and we can take it from there. 👍