From .NET Framework to .NET 5

Note: .NET 5 is still in preview version and does not officially supports Visual Basic.Net Forms as of April 23, 2020.

It has been over a decade since I wrote my last code in Visual Basic 6. A bunch of friends wanted to revive an old game engine, written in Visual Basic .NET, from a community I was part of and I accepted it - hence I am currently toying with Elysium on my free time.

VB6 stopped being supported by Microsoft a long time ago. While Elysium by itself deserves a separate post, I wanted to make the server run in Linux, so the team could create a default map together. Thus, I went to convert my project from .NET Framework 4.5 to .NET 5 (which also implies in converting to the new “Core” virtual machine).

First, as it is explicit at the beginning of the post, the Visual Basic support for the actual .NET Core 3.1 is very partial - while it can run console applications in multi platforms, there’s no support for the Windows Forms library.

While porting the server (which is mostly a console and sockets/packets and text file processing), the conversion itself was pretty easy, although the “Portability Analyzer” from Microsoft didn’t work with me. My issues were, essentially, three:

1. Environment: References to the ‘Application’ class (e.g.: ‘Application.StartupPath’ or ‘Application.Exit’) are not used anymore. Instead, I should call via the Environment (e.g.: ‘Environment.Exit(-1)’) or via System.IO library (e.g.: System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly.Location)). Application.DoEvents() is not recommended for use anymore (instead, use an asynchronous function).
2. Cryptography was my main issue for the server-side. AES/Rijndael’s algorithm does not support keys over 128-bits in .NET Core, so I actually had to rewrite all the buffer sizes for it and regenerate a new key standard for it. This was pretty much the crucial point that allowed direct communication with the server and client in different operating systems.
3. Speaking of ‘key standards’, we also used a RSA key. The original procedure of generation in .Net Framework was using CspParameters and RSACryptoServiceProvider, which was dependent of Windows APIs and hence not compatible with the new .NET. Instead, we had to call the RSA.Create method for generating the new key, and replace all the references of RSA_CSP and CspParameters.

As for the client, there s a workaround to be able to edit forms using Visual Studio: it’s simply about using the preview version (16.6.0) and creating a VBProj file. Inside it, it’s just a matter of adding/replacing some XML tags:

 <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>netcoreapp5.0</TargetFramework>
	<UseWindowsForms>true</UseWindowsForms>
	<StartupObject>Cliente.FrmMenu</StartupObject>
	<ApplicationIcon>Source\My Project\Icon.ico</ApplicationIcon>
  </PropertyGroup>

You’ll be able to design some forms. Depending on your code, there’ll be the need to fix some references and make explicit references for forms. Finally, this is still Windows-only as it’s dependent of Windows-only APIs.

Most will work out of the box. But looks the interaction between the user interface and the backend code is pretty different from the original Framework version! And since there’s not much documentation (nor error logs for it), looks like I’ll need to wait for the final version in order to do a full rewrite and port the client.

Edit (18/05/2020): I’ve taken notice that .NET 5 will not be able to support cross-platform WinForms as it depends on Wind_o_ws-specific APIs.