The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
You should look for a low code solution.
I highly recommend DevExpress XAF.
What is the budget for the project?
C# with DevExpress XAF.
With one low code solution in C#, you produce :
- Web (touch enabled)
- multi-platform Mobile app with native look and feel.
Your source code is mainly the description of your objects and their relations, where you add declarative validation and other goodies via attributes.
Your application creates (or updates) the database automatically (including indexes, foreign keys, necessary n-n relation tables, etc.) and produces a beautiful default UI that you can fully customize, either in Visual Studio or at run-time.
The learning curve is sharp, but well worth it.
Everything is done by following best design patterns.
+1 for DevExpress. I didn't use their XAF, but I used all of their WinForms controls. They have great functionality, but were a bit "heavy" - meaning the program screens took a little bit longer to load than you would expect. Still, I wouldn't hesitate to use them again. I changed jobs, and they don't use DevExpress. I still have my five year old license though!
+1 million for LinqPAD. It is NOT just for LINQ. It is incredibly useful for writing and testing code snippets. You can create whole classes in it. And you can add references to your .Net assemblies and call their methods from within your LinqPAD code. I also use it for common queries, functions and maintenance tasks.
You can use the free version, but you need to buy a license to get the syntax help. Totally worth it and it supports the developer.
I have done this - taken a large VB project (which I wrote) and converted it to a shipping product written in C#. A few things I learned
1. Don't convert the VB, write a new application. Take the lessons leaner from VB app and apply them using C# and .NET. Use it as an opportunity to improve the code and algorithms used, even if it is supposed to be functionally similar or the same.
2. Write something else in C# first. C# and VB6 are more similar than you would think but the differences are key. Write something using VS2017. Make your mistakes there. It doesn't have to be something big, just something to get you up-to-speed with it.
3. Whatever you think it will take, it will take longer.
4. Whatever you think it will take, it will take longer.
5. Consider the external parts of your VB project: OCXs References etc. If you don't have control of them it could make life tricky in C# land.
6. You asked about tools: VS2017 is the best tool you can use. Concentrate on that first!
I converted a few VB6 programs to C# and some more from VB.NET.
When I joined the firm that I am currently working for they had a bunch of VB6 and VB.Net software and they wanted this translated to C# asap.
Ofcourse the best way is to start all over, but that was not an option my boss wanted (and he is the boss so he decides).
So I used VS2008 (it has a wizard for this) to translate VB6 into VB.NET.(Google will tell you how, but it is pretty straight forward).
And for the VB.NET programs I used SharpDevelop 4.4 (make sure to use this version and NOT a newer version, because for some reason the took the convert option out).
SharpDeveloper 4.4 (I am sure using google you can find this free software) has an option to convert VB.Net to C#. Load the VB.NET solution in SharpDevelop. Right click the solution and click Convert => C# (it has other convert options as well).
You will find that is not perfect. A lot of times you will need to replace brackets like ( with [. Strings in VB.Net start counting from 1 in C# this is 0 (if you didn't use VS2008's wizard to convert from VB6 to VB.Net than you need to keep this in mind).
You will need to create new screens (you can select everything and copy this to a new screen) and than make sure that the code is bound to this screen. You will also need to select for instance your buttons and select the correct click event to the click event of this button.
Than when you compile there will be some references to some VB.NET stuff that cause an error which you will need to remove.
Start with a simple project. If need be create a helloworld in VB6 and convert thus.
I used these options to convert about 15 projects to C# and it saved us a lot of time.
You will get the hang of it as to where you will need to make changes, in most cases it is the same kind of stuff that goes wrong.
You will also find that VB.NET is a lot more forgiving than C#. When you work with a database and retrieve info, there will not be a conversion to string. And when you use this method you will sonn find out that you need to go through the code and add '.ToString()' when you collect info from a database.
There are function in VB that have no counterpart in C# (if I am not mistaken Mid or MidStr is such a function). SharpDevelop will add some DLL so that you can still use these functions.
As the majority of the applications already was in VB.Net I am not sure if there are many functions in VB6 that do not have a counterpart in VB.Net. I do not think it will be that many.
However should this occur, lets say it is function GetCoffee() (I am pretty sure VB.Net does not have this function), than it will be converted to VB.NET there will be a comment line that this cannot be converted. SharpDevelop will also keep the code as it is.
Compiling the code will ofcourse produce an error at GetCoffee(). You can than use Google to see what this function does and simply create your own interpretation and write a new method.
I converted a major software component (a very complex one) from VB6 to VB.Net some years ago. Converting to C# would not be that much more difficult. However, having said that, it would be a surprise to me that there were really any tools that would make the conversion much easier. The environments (COM vs. .Net) are different. There are similarities but a fair amount of the work is, simply, going to have to be manually done. The basic logic can remain the same but the fact that .Net implements first class object orientation where VB doesn't is going to make you want to optimize as you convert.
I don't mean to be the bearer of bad news or anything but unless someone has developed some "magic bullet" software (which I doubt) you're just going to have to tough it out.
If you think hiring a professional is expensive, wait until you hire an amateur! - Red Adair
- CodeCracker for C# ( Extension )
- and use the VS CodeAnalysis.
Those give a good insight about how things should be done. Don't take every rule as required, but instead think how it suits your project. The help articles are great at explaining why and how and when.
Write UnitTests. When you convert Methods, you may want to try them anyway. And trying them by clicking through the software and creating the situations every time you want to test something is a sisyphus work. The Addon AxoCover can show you which branches of codes are used in the test cases.
A lot of devs are "yeah making tests takes time and i dont have it", and yes it takes time if you write them afterwards. Write them instead of playground console apps and wasting time by clicking though the ui. If you notice a class can not be tested, because it requires a lot of other classes, your class may be not that good.
I'm currently in the last phase of converting a ~250.000 line project from VBA (!) to C# and I agree that re-writing it as a functional clone would have been the better way.
But here is how I did it:
1. VBA -> VB6 (not your issue but included for completeness' sake)
- acquire and run an old VB6-IDE
- import/convert VBA-project
- fix compile-errors
2. VB6 -> VB.NET
- acquire and run an old version of VisualStudio (those still had a converter for legacy-VB6! I think I used 2005)
- import/convert VB6-project
- fix compile-errors
-> now we're in .NET-wonderland!
3. VB.NET -> C#
- run an old version of "SharpDevelop" (I used v4.4 - as far as I know the feature in question was removed in v5!)
- open/import VisualStudios VB.NET-project
- convert to C#
- open/import in VisualStudio
- fix compile-errors
-> now the code-base is where it's supposed to be - in C# and in VisualStudio!
During these conversion-steps I often treated the codeFiles not only within the respective IDE but also as "normal" text-files in <insert-text-editor-of-choice>.
For that phase I recommend
- EditPad (for the actual search-and-replace-stuff)
- Agent Ransack (for identifying the codeFiles in need tampering)
- and a good and healthy dose of regEx!
When arrived in VisualStudio I recommend
They both are very good at spotting code-habits that stem from VBA/6 and were simply converted!
Fixing the (comparatively few) comile-errors introduced in each conversion-step didn't take too much time / effort.
- the vast majority of those were of the same few types and quite simple to fix. Again: freshing-up on regEx is highly recommended
- Most time went into replacing some filthy VBA/6-only stuff that doesn't have an 1:1 equivalent in C# (for good reasons). But this kind of code needed re-writing either way.
While the outlined approach worked very well and took surprisingly little time, the actual work is then only starting
- yes, VBA/6 and C# do stuff in different ways
- and they especially lack a lot of C#s capabilities so the resulting code - while working - is almost always very clunky, verbose and un-elegant
looking back, re-writing the code as functional clone would have been the better way!
Perhaps there is a middle way: convert the old code to have some kind of quarry for quickly looking up / copying old algorithms where necessary (without having to do the same steps of syntax-conversion over and over again)...?
4. No politics (including enviro-politics[^]), no sex, no religion.
«While I complain of being able to see only a shadow of the past, I may be insensitive to reality as it is now, since I'm not at a stage of development where I'm capable of seeing it. A few hundred years later another traveler despairing as myself, may mourn the disappearance of what I may have seen, but failed to see.» Claude Levi-Strauss (Tristes Tropiques, 1955)</