|
I agree, go straight to C#. The jump from VB6 to VB.NET is not any different than jumping to C#, so cut out an unnecessary step.
Why go C#? Depending on which survey you read, C# has at least twice the market share of VB.NET. As a professional programmer/analyst I learned to focus on languages that would get me the next job. In job hunting I see a lot more C# reqs than VB.NET, so the surveys appear to have some validity.
|
|
|
|
|
Just want to second what Nish said. Also, to plug to our old friend Tom Archer who works at Microsoft, it may be worth getting his book [^]. It's a bit dated now, but in this case that's good.
It's a book that's specific about coming from a Visual Studio 6.0 world (from more of a C++ standpoint but still) to help with the fundamentals of C#. After the fundamentals, you can always read up on what's happened with the language lately... which has been a lot.
Jeremy Falcon
|
|
|
|
|
Given that Resharper has already been mentioned, what other tools would be useful?
Well, you might want to look into NDepend[^]. I use this tool a lot to check code quality; it's really useful for showing you dependencies and telling you the cost of those dependencies for instance.
Then there's unit testing (whether or not you are a fan of TDD, having well written unit tests is a real bonus). You can go with something like NUnit, the Visual Studio unit tests, xUnit or so on. Speaking of unit testing, as your code grows you might want to invest in NCrunch[^]. It's a great way to see if your code changes have broken any tests without you having to remember to run the tests yourself.
There are many other tools you can add as you grow, but I'd give these a look if I were you.
This space for rent
|
|
|
|
|
Is there an underlying reason to re-write beyond the fact that the code is out of date?
You may find, along with Nish's brilliant advice, that you could speed things up by wrapping the old functional parts into an API that can be called by the 'new' version.
That way you don't need to rewrite everything from day 1 to get moving. Wrap the API that can be called by the new solution and then you can replace the functionality piece meal rather than all at once.
veni bibi saltavi
|
|
|
|
|
As Balboos said, delete and rewrite. Anything in VB6 is going to look like an aborted fetus in C#. Not that it doesn't look like that already in VB6. 
|
|
|
|
|
You mean "rewrite". Converting VB6 code to C# would mean using old COM-interfaces, where there's easier managed solutions available.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
You need one of these:
http://com-sub.info/Mad/Welcome
And a few tabs of Anacin.
|
|
|
|
|
A few tabs, yes. Tabs of what may vary. 
|
|
|
|
|
Message Closed
modified 19-Sep-18 11:16am.
|
|
|
|
|
+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!
Mike
|
|
|
|
|
LinqPAD - http://www.linqpad.net is totally worth it. It's very nice to play around with small snippets and run them immediately / compare them to other languages.
|
|
|
|
|
+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.
Great suggestion mOsa!
Mike
|
|
|
|
|
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!
|
|
|
|
|
LS,
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 hope I was able to help you.
Kind regards,
Clemens Linders
|
|
|
|
|
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.
-CM
If you think hiring a professional is expensive, wait until you hire an amateur! - Red Adair
|
|
|
|
|
What you try to do - LEARN or CONVERT???????
|
|
|
|
|
BOTH!
They are not mutually exclusive.
It is far better to kill 2 birds with one stone that one bird with 2 stones.
|
|
|
|
|
If I got it correctly, you wanna... study C#? Then FIRST you need to learn C# and THEN convert code. And hardly there is any converter except your head. 
|
|
|
|
|
I recommend
- StyleCop.Analyzers
- 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.
Oh and good luck, sir!
|
|
|
|
|
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
- StyleCop
- ReSharper
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.
But:
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
I repeat:
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)...?
|
|
|
|
|
If these folks [^] had a newspaper, would all of it be Fakir news than most other publications?
Even if it's all true?
(this will teach you not to complain when it's "quiet in here")
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
No time to think about that yet. I'm still busy trying out cooking with alternative fats.
I have lived with several Zen masters - all of them were cats.
|
|
|
|
|
CodeWraith wrote: alternative fats.
In my profession opinion, I strongly suggest you center you efforts on mineral oil.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Even my car gets fully synthetic oil - and likes it!
I have lived with several Zen masters - all of them were cats.
|
|
|
|
|
Any send me codez urgentz group?
modified 20-Oct-19 21:02pm.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
