In this piece we will look into the changes coming in .NET framework during 2020 and ways to get ready for the transformation ahead. It’s always complicated to update your old stack in small increments. There are some strategies that could help you to handle these changes.
It’s going to be an amazing year for the .NET ecosystem:
- .NET Framework is “complete”. It’s not likely that there will be a new version of the framework. 4.8 will be the last one after 18 years.
- .NET Core 3.1 is an LTS (a Long Term Support version supported for three years after the initial release Dec 2019). This version of .NET Core will also be the last one. The most loved framework in 2019 is done, is it?
So, why is this going to be a great year? .NET 5 will come, in November 2020, to cover all the cases. It will be the new framework to solve all the problems. It will take the best from .NET Framework, .NET Core, Xamarin and Mono including AoT compilation. You will be able to develop apps for Windows, Mac, Web, Mobile, Cloud, IoT, Gaming, Machine Learning and Data Science. Of course, you will be able to create all of this from the most loved development environment in 2019: Visual Studio Code. What’s more is; this will include a great support for containers even adapting its behaviour with CPU and memory limitations introduced by Docker.
How do I prepare my company for this change?
- If you are building something new, do it with .NET Core 3.1.
- If you are not using .NET at all, should you consider it? Do you want to use WebAssembly? Maybe it’s worth taking a look at Blazor. Similarly, the way to go about it could be with Rust (performance).
- If you have a .NET Framework app, you will have some work to do.
Migrating from .NET framework to .NET Core 3.1
- Analyze your architecture. As always, building good software will allow you to be prepared for future changes like this one. A good architecture will help you a lot in migrating things. For instance, you should have your logic isolated from your UI and this will allow you to move forward easier. If you don’t have software that is prepared for this, consider replacing it.
- Analyze your situation: Use a Compatibility tool and check your dependencies status
- Upgrade dependencies: You need your dependencies to support .NET Standard.
- Migrate: Migrate your project files and config files to the new .NET Core structure (SDK-style). Choose the same folder and only open one of the projects at a time.
- Move your logic to .NET standard: Start to change your not-UI libraries to use .NET standard. They will be compatible with both frameworks, until 2.0.
- Analyze your UI: Remember that Winforms and WPF won’t be multiplatform. So, consider moving those to another tech. UWP (Universal Windows Platform) is a framework for PC, tablets, smartphones, Xbox, HoloLens, Surface Hub, and Windows 10 IoT Core. Maybe with WinUI?. Even if you want to stay and move forward with your old choice, you will discover some ground-breaking changes. It won’t be an easy movement. Consider moving to SPA (Angular, React, Vue, Blazor, etc). As always, consider using or buying a component library to boost your development speed and time-to-market.
- Client-Server communication: Do you want to change it? Were you using Remoting or WCF? You can use REST, GraphQL, gRPC, Websockets, SignalR, and/or WebHooks.
- Improve your code: use all the new features in .NET Core to improve your architecture
Replacing or transforming the app with a new modern stack
If you decide that your app is legacy and you need to build something new, I recommend avoiding a big bang change. Do it in small increments and release as often as possible. Here is how you can do this:
In the backend, if you have a good architecture, you can use the strangler pattern. You can also create backend libraries with .NET Core and use them from your old Framework App while you migrate. For the UI, if you need to integrate two different technologies, use standards if possible. In this case, web components.
If you have an old .NET MVC app, you can develop a new SPA and expose these new components as web components. The registration of the web components will be available in both apps and you can create a communication mechanism between them:
- Native custom events
- Input/Output changes in web components
- Advance communication between your UI apps, old MVC and new SPA, via reactive programming (Rxjs)
This will allow us not to generate new tech debt while changing the old components in an iterative way. Your customers will be enjoying your new SPA integrated with their old app from the very beginning. We will detail this approach in the next tech blog piece, using Angular as an example.
If you want to keep evolving your app, you need to update your stack. You can continue, of course, creating your software in .NET Framework 4.8 but sooner or later, you will need to upgrade. Start your migration now. Want to go deeper? Interesting things to follow regarding .NET and WebAssembly future in .NET: