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.