In my previous blog I talked about why we moved from vb.net to C#, in this blog I’ll talk about how we transitioned.

We’re very fortunate at DuckheadSoftware, we’re independent, meaning we can do what we want, we’re also from the UK, meaning we’re optimistic 🙂

As previously explained, we lost a lot of our code to hackers, we’re not proud of that, but it did provide us with a stop-gap, to sit back, have a beer, contemplate the meaning of life, the universe, and Microsoft developing.

So, we’re now on a path to C#, but we have years, and over a million lines of code in vb.net to convert. There are tools to convert code en masse, but we’d learn nothing by doing that, so our approach was to wipe our development machines, re-install and only have C# code on them. A big bold move !

OMG, what a shock, but in a good way, it wasn’t that hard to get into C#. Physiologically I hated it, but technically it was just new stuff to learn.

I’ll talk about the good, bad, and ugly in another post, but here I wanted to look at the transition and where the pains were.

Firstly, we couldn’t just start converting our code base, we needed a project, and so we decided to convert one of our small apps – HEIC to JPEG. It was a good candidate because it was designed to be as simple as possible for the users, so the User Interface would be easy to convert, as would the code controlling it.

We decided to rewrite it from scratch, after all, how hard could it be ? – well, again, not tooooo bad. The User Interface (UI) was written in XAML, so that pretty much came over without change, although, as it was a rewrite, we went through all our reviews and updated it a bit – I’ll write another blog on the Microsoft App Store at some point.

So, the UI was simple, not perfect, there are quirks with using C# that using vb.net doesn’t have, for example: vb.net has the ‘handles control.event’ keywords, which C# doesn’t; vb.net also has the ‘dim withevents’ which auto-wires up events, C# does not and that has to be handled manually. There are also lots of complaints from Visual Studio that we were using the wrong naming conventions, we had to change our naming policies to manage that.

Now that we we’re happy converting the UI, the next step was the code base. We knew we could re-create only the bits this app needed, so it wasn’t a complete rewrite of our libraries, although it ended up being much more code than we were expecting. We approached the new code with a combination of ‘vb.net to C#’ code converters on the internet, and a lot of googling. We’re already developers/coders, we know how to code, it’s just the language that changes, even the .net framework and XAML were almost the same. C# only has around 80 keywords to learn, some syntactical differences (like curly brackets, semi-colons, and case dependencies, more on that in another blog), and editor handling changes to work through 🙂

vb.net to C# code converters are, to be honest, only useful for simple conversions, anything complex in vb.net gives converter errors or the wrong conversion syntax, which when learning a new language is very disappointing, but hey, it’s free, we can’t complain. What this did allow was for us to take our knowledge of vb.net, look at the code, and see what the changes looked like in C#, it was fairly self explanatory; I ended up not reading the book I bought on C#, although I probably will at some point in the future for more advanced stuff in .net core syntax.

It took about two weeks of coding in C# to gain some ‘keyboard memory’ and start typing variable names after the type. By not allowing any vb.net code in our new environments we were never tempted back to vb.net, that was a big thing because it would have been so simple to revert back.

In addition to all this, our code library is brand new, so we were also able to remove legacy and backward compatible ways of doing things to bring our library up to date.

Another update we made was moving from .net framework 4.8 to .net core 3.1, that was super simple (thank you Microsoft), although a few breaking things were found that we had to work around, especially with threads. This change also meant we had to look at any libraries we use from GitHub to ensure compatibility, thankfully they were compatible, but we had a chat with a few of their developers to make sure of a few things and iron out the odd crease.

I still forget some basics and have to google things like “select case in C#”.

So, our approach worked, we have a replacement app in the Windows App Store, HEIC to JPEG v4, it’s not only in C# 8, but also uses .net core 3.1. We’re monitoring crashes and so far it looks good.

The disadvantage of our approach is maintaining our vb.net codebase for previously published apps. With our hacked server, this was going to be a big piece of work anyway to put everything back together for some of our older apps, but with the new skills we have developing in C#, we can rewrite an app quickly if needed; I’m sure that won’t be the case for other developers. We can, if absolutely needed, rebuild our vb.net server and update apps, we’re just pushing back on ever doing that if possible.

In conclusion then, we have a plan to rewrite our apps and upgrade them as we do it based on feedback in the store, something that might not have happened so quickly if we’d have stayed with vb.net. We’ve paused all development on new apps, which is disappointing, but temporary. As a developer I feel ‘better inside’ knowing I’m on a path that enables me to look forward to Xamarin/MacOS, .net core 5 and WinRT APIs, with less worry about “will it still be viable in 5 to 10 years’