Why convert the DNN VB.net based modules to C#?
Good question.
Why would one want to convert a proven and correctly working DNN module from VB.net to C#?
- Technically speaking: there is no need
VB.net is as powerful as C#
- Functionally speaking: there is no need
The module does not gain any new functionality when it is 1 to 1 converted in another .NET language.
- And then there is the risk
VB.net and C# differ in details with things like strong typing, type conversion, parameter referencing and more. Do we introduce a step backwards i.s.o. forward?
So why?
The answer, in this case, is twofold:
- It is a good learning experience for 'not so experienced' .NET developers, who are still learning C#
You have a correctly working (VB) module at one side and a not-yet-good working C# module at the other side. So it is proven: it can work, just fix it!
- C# is the language of choice for almost every professional .NET developer
So it will be easier to find people who can understand the source of the module and maybe provide some code enhancements
How do you convert a large module from VB.net to C#?
There are several options: line by line or an online service to convert code fragments. But that is not the options that we have used.
Some time ago I bought a commercial product that can automatically convert complete VB.net based projects into C# in a couple of minutes. Have a look at vbconversions.com. Not very cheap (around $500), but well worth the money if you have serious projects that you want to convert. This tool does a decent job in converting VB.net source code into C# equivalents. It needs a VB solution/project that builds without errors and access to all referenced DLL's. It signals potential problems, has side by side source comparison and more.
What steps did we take in the conversion?
The initial step was the translation of the project from Visual Basic (VB) to C# using the translation tool. The resulting solution has all the same files and folders but now the code is C#. After that, a proper developing environment was set up whereby the C# and VB code could be compared and debugged side by side.
The second step was to make this generated project build correctly and fixing issues.
Most of the initial build errors were related to enumerators needing to be cast, operations and ascx files. Problems arising with ascx files are that methods getting called in the code behind get/set to private (which they also are in VB) which C# does not understand. Fix for this is to make them protected.
Sometimes onclicks attributes getting placed on the wrong tags or missing entirely.
Another issue which breaks the building process is the VB Nothing declaration. This translates into C# as 'null', but if applied to the declaration of a string, VB interprets that as an empty string ("") but in C# it gets assigned to the null which can cause unexpected problems.
What modules did we convert?
We had a go at DNN.Reports (a fairly simple, but old module) and DNN.Events (a very big DNN module that as been well maintained over the years).
Both modules are now released in their C# equivalents and have a new release. DNN.Reports required most of the basic work, DNN.Events had more work because of the size of the module.
The DNN.Reports module from VB.net to C#
The Reports module is a fairly old one. It has a lot of DNN API calls which are deprecated and removed altogether in DNN 9.2. So after the solution builds correctly in DNN 7.3.2, it was necessary to remove deprecated functions from the project. This part of the conversion and upgrade was time-consuming. It required replacing old DNN API methods with the new DNN API ones. The new DNN API calls used different parameters which required rewriting big chunks of code.
After all the errors and deprecated warnings were ironed out it was time to build the module and see if it still functioned properly. During this phase some unattended ascx file errors were handled and eventually, the module functioned just like it had before under VB.
Automating the build and packaging
When DNN.Reports was updated this way, we modernized and automated the build process. For this, the MSBuild extension (DNNtcMSBuild: MS Build for DNN module development) was used and the whole structure of the project was reorganized to match a more modern DNN module structure:
- Release notes were separated into multiple files;
- files to be cleaned up got put into text files;
- the dnn manifest is completely automatically generated as part of the build process;
- a new icon was added; cleanup, release notes and sqldataproviders were put in a new 'Installation' map;
- license and headers were updated;
- the code was refactored using ReSharper
- a new and an updated .build folder was added.
The last phase consisted of testing whether the new module installed and uninstalled correctly as well as checking whether files got cleaned up correctly after an install on top of an older version.
DNN.Events module from VB.net to C#
This module is much larger than DNN.Reports, but much better maintained over the years. No deprecated DNN API calls anymore in the most recent version, just a lot of work on casting, protected/private, string handling and more difference between VB.net and C#. But we managed to do so.
Credits must go to my colleague Mark van de Vries, a developer at XCESS. He did most of the development work for the conversion, code corrections, and solution improvements.
The end result: DNN.Reports 6.0.0 and DNN.Events 7.0.0 released
If you are interested in an updated version of DNN.Reports, a version that works correctly on DNN 7.3.2 to DNN 9.2 and has some issues fixed: download DNN.Reports here and give it a try. If you find any issues, document them here.
Looking for the C# version of DNN.Events? Download DNN.Events 7.0.0 here. Warning: converting VB.net solutions to C# is not a simple task. And although we did quite some testing, I guarantee you that there will be bugs to pop up in none standard configurations. But we also promise you: we will squash the bugs if you document them as an issue on GitHub.