Why to migrate to .NET 8

In the late 1990s, there was .NET Framework. It was a library, or framework, that was easy to use to build applications on Windows. They were inseparable. The .NET Framework was built so that it could only work on Windows.

Years went by, features were added, and the .NET Framework grew fat and complicated. Also, computing was transformed. Nowadays workstations are not the only thing. Mobile phones, the "cloud" and other things were rising above Windows. The need for creating applications that work across different platforms became imminent. Sometimes it was not justified to pay for Windows licenses, so applications were written on different platforms.

The changes were so big that even Microsoft saw a necessity to create a cross-platform version of the .NET Framework. It also made sense to create it from scratch and not on top of the existing .NET Framework.

Microsoft tried many different solutions to create cross-platform versions of the .NET library. They were known by multiple names (.NET Standard and .NET Core are the most notable ones.) but eventually a cross-platform version of .NET was called .NET 5, .NET 6. and so on. The last version of the .NET framework was 4.8, so number five was a good place to start.

Currently, Microsoft has stated that even though the .NET Framework is supported, all new development will happen on the cross-platform side. Also, the whole .NET ecosystem has moved towards cross-platform, and currently, most new developments on 3rd party libraries are on the cross-platform side.

To put it simply, .NET 5, 6, 8, and so on will provide multiple enhancements compared to the .NET Framework

Cross-platform compatibility

Improved performance

Improved security

Containers

.NET Framework and .NET have similar, but not the same, APIs so not everything will just work when moving to .NET. However, Microsoft made a compatibility layer in an early version of the cross-platform side so, you can run any .NET Standard 2.0 code on .NET Framework. On the other side, .NET is backwards compatible with .NET Standard 2.0.

Starting from early 2020 Frends have had a production-ready versions of Frends Agents built on top of the cross-platform version of the .NET library. As of writing this in late 2023, Cross-Platform Agent supports .NET 6 (and from Frends version 5.7 onwards .NET 8) and legacy Agents support .NET Framework 4.7.2. Thanks to the compatibility layer and backwards compatibility, both support .NET Standard 2.0.

Since 2020 Frends Tasks have been upgraded to support .NET and the earlier challenges of, for example, bringing XSLT 2 and 3 to .NET worlds have been overcome.

In Frends when you create a Process you need to define if it targets the legacy .NET Framework, or either Cross-platform technology (.NET Standard 2.0 or .NET)

In early 2023 with Frends version 5.6 we arrived at a point where Cross-Platform Frends is generally better and it is the version that we deploy by default. It should be mentioned that you can have both types of Agents in your environment. Also, even though Legacy Agents are supported all new development on the platform side happens on the cross-platform side first and if possible, changes are implemented on Legacy Agents.

Microsoft, Frends, and most of the .NET ecosystem have decided that the future is on the cross-platform world. Therefore it makes sense to update sooner rather than later as in the future there is even more to migrate. Also, it is sometimes possible to migrate with very minimal effort.

Most of the "old" (i.e. non non-.NET Tasks) support .NET Standard 2.0 meaning that most existing Processes can just be recompiled to target .NET Standard 2.0. The .NET Standard Tasks will also work in .NET Processes.

You can also go directly to "full" .NET if you make use of the new .NET Tasks.

There are basically two ways to migrate your Processes to cross-platform. Either you go directly to .NET 6 with Tasks, probably having twice as many Agents during the migration, or you first migrate all Processes to .NET Standard 2.0. and start creating new Processes with .NET. Also in this case you can just reinstall the cross-platform Agent in place of the legacy Agent. Going directly to .NET with new Tasks is probably more costly now as it requires more manual work. Going to .NET Standard 2.0 first is probably cheaper now, but you might need more manual work in the future if you need to migrate Processes to .NET 6 later.

The problem with .NET Standard 2.0 is that it provides a subset of what is common in .NET Framework and .NET. So it in a sense combines the worst parts of both. Also, we wanted to change the way Tasks are packaged to be more granular and move and redo most community Tasks to be official. The change to a cross-platform world provided a clear breaking point of when to make this change.