Supporting .NET 6

[stijnmoreels]

Is your feature related to a problem? Please describe.
We should support .NET 6 throughout all the Arcus repositories, as .NET Core will vanish the end of the year (2022).

What suggestion do you propose?
#188 will make sure that we support the lowest possible version for the target framework.

Additional context.
Original remark:

Sorry for me to be a bit picky on this, but I'm not convinced that the changes that have been done now, are good.

What frameworks are we supporting in Arcus ?
I'd say that if we support .NET 5.0, .NET Core 3.x and .NET standard, that we should maybe explicitly test on those.

For instance :

<ItemGroup Condition = "'$(TargetFramework)' = 'net5.0' or '$(TargetFramework)' = 'netcoreapp3.1'">

and

<ItemGroup Condition="'$(TargetFramework)' = 'netstandard2.0'>

These are assumptions based on this article.

(Don't know if this works, 'cause I haven't tested it or played with it).

Originally posted by @fgheysels in arcus-azure/arcus.observability#166 (comment)

[tomkerkhove]

Since .NET 6 is coming out this fall which is LTS, I would suggest to rename it to be .NET 6 compatible.

What do you think?

[stijnmoreels]

.NET 6 released. 🎉

[stijnmoreels]

From @fgheysels:

Since .NET 6 has been released, and .NET 6 is the latest LTS version, we should start supporting templates that are based on .NET 6.

I don't know if we should still support .NET Core 3.1 as well ? Maybe default to .NET 6 and provide a parameter to generate a project for .NET Core 3.1 ? Although this will be something that we'll only support for a short term as .NET Core 3.1 support ends in december 2022.

[fgheysels]

My idea would be (for Arcus libraries):

• drop .netstandard
• support .NET 6 and still support .NET Core 3.1 for a while.

For templates:

• only support .NET 6 as I think this is the way forward.

[stijnmoreels]

Definitely the templates to .NET 6, I think that's logical as it's new projects.

The other thing, we'll have to check.

[fgheysels]

My idea would be (for Arcus libraries):

• drop .netstandard
• support .NET 6 and still support .NET Core 3.1 for a while.

For templates:

• only support .NET 6 as I think this is the way forward.

I've changed my mind regarding Arcus libraries:

We're currently targetting .netstandard2.0 and .NET Core 3.x.
For libraries where we're targetting .netstandard 2.0, we should migrate to .netstandard 2.1. .NET 6/x will be fully compatible with .netstandard 2.1 .NET Core 3.x is also compatible with .netstandard 2.1. When targetting .netstandard 2.1, we'll be available for a wide range of applications, without being obsolete.
What is now targetting .NET Core 3.x -> slowly migrate to .NET 6

Priorities for me would be:

• Migrate Arcus templates to .NET 6
• Migrate Arcus libs from .netstandard 2 to .netstandard 2.1
• Move away from .NET Core 3.x and migrate to .NET 6

Any thoughts @stijnmoreels @tomkerkhove @gverstraete @pim-simons

[pim-simons]

I haven't had too much time to look into this, but the way you describe it @fgheysels it seems like a good plan 👍🏻
Agree that migrating the templates is a priority, I usually use the templates to start building new stuff so that would be a good one to have.

I am interested in why you changed your mind regarding .net standard, not saying I don't agree, just interested in the thought process behind it 😄

[stijnmoreels]

Any thoughts @stijnmoreels @tomkerkhove @gverstraete @pim-simons

I agree, (discussed offline). We should check if we don't break anything in the process. Technically (very technically), this migration from netstandard 2 > 2.1, is maybe something that is considered a breaking change...

[fgheysels]

Library authors who need to support .NET Framework customers should stay on .NET Standard 2.0. In fact, most libraries should be able to stay on .NET Standard 2.0, as the API additions are largely for advanced scenarios. However, this doesn’t mean that library authors cannot take advantage of these APIs even if they have to support .NET Framework. In those cases they can use multi-targeting to compile for both .NET Standard 2.0 as well as .NET Standard 2.1. This allows writing code that can expose more features or provide a more efficient implementation on runtimes that support .NET Standard 2.1 while not giving up on the bigger reach that .NET Standard 2.0 offers.

https://devblogs.microsoft.com/dotnet/announcing-net-standard-2-1/

[stijnmoreels]

https://devblogs.microsoft.com/dotnet/announcing-net-standard-2-1/

Hmm, seems like remaining on netstandard 2.0 is the way to go then (for libraries that already had this). There are, however, libraries that target both (netstandard 2.0 & netcoreapp 3.1).

[fgheysels]

We could also say that we'll stop supporting .NET Framework in the near future.

[stijnmoreels]

We could also say that we'll stop supporting .NET Framework in the near future.

We could, but I don't know what's the common target framework for Codit projects (existing and new)? Maybe some environments require one or the other...

[gverstraete]

We could also say that we'll stop supporting .NET Framework in the near future.

We could, but I don't know what's the common target framework for Codit projects (existing and new)? Maybe some environments require one or the other...

Only supported versions by Microsoft at the moment is .NET Core 3.1, .NET 5 & 6. I think we can raise the bar to that minimum requirement no issue: https://dotnet.microsoft.com/platform/support/policy/dotnet-core

If new projects are started with older versions, I think we need to have a discussion with them ;)

[tomkerkhove]

Agreed

[fgheysels]

Do we have an overview of which projects still need to be migrated, or for which projects we haven't released a .NET 6 version yet ?

I thought we had an issue where we kept track of that, but i can't find it anymore.

[stijnmoreels]

Do we have an overview of which projects still need to be migrated, or for which projects we haven't released a .NET 6 version yet ?

I thought we had an issue where we kept track of that, but i can't find it anymore.

It's referenced in the issue's description: #188 will make sure of this.

[fgheysels]

Ah ok. :')
Can we continue with releasing all our libraries for .NET 6 support, as this should be the highest prio atm imho, since more & more people will be looking to convert their solutions from .NET Core to .NET 6

[stijnmoreels]

Ah ok. :') Can we continue with releasing all our libraries for .NET 6 support, as this should be the highest prio atm imho, since more & more people will be looking to convert their solutions from .NET Core to .NET 6

Yes, of course. Like we talked about: .NET 6 support is our primary objective, service-to-service correlation closely behind that one. The next library is background jobs, so that's the one I was focusing on the last couple of days/weeks.

[gverstraete]

Don't want to put pressure, but any ETA?

[stijnmoreels]

Don't want to put pressure, but any ETA?

😄 that's hard to say. The current focus is background jobs, but that is also the last big repo with functionality, then it's just updating our templates which could go quite fast.
At Arcus, we don't really have deadlines as it's all under R&D budget and most people are even working on Arcus 'when there's time left from other projects', so it's very dependent on the busy schedule of everyone.
We hope to help you soon 😉 .

[fgheysels]

@gverstraete : The .NET 6 version of BackgroundJobs is released. :)
https://github.com/arcus-azure/arcus.backgroundjobs/releases

[stijnmoreels]

Ok, this is officially done! 🥳