|
Best Tool for me is ReSharper
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
What might be useful, if it exists, is a tool that would let you embed C# in VB6 or vice versa allowing you to incrementally rebuild the app one module at a time. THis's dependent on the legacy apps structure not being too horrible; but at 400k lines and worked well enough to be kept alive this long I'm assuming that it did have more software engineering that the average craplication that earned VB6 so much hate over the years.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
I have been a firm believer in Rokford Lhotka's Business Objects....
|
|
|
|
|
Used Rocky's framework for years. Good stuff.
Mike
|
|
|
|
|
If all you're doing is converting it then what do you hope to gain? If you're not prepared to rewrite it just leave it as it is.
|
|
|
|
|
By "Converting" I meant re-writing while keeping all of the same functionality.
|
|
|
|
|
You clearly are looking to move to C#, but if you really want to shorten the learning curve, consider converting/rewriting to VB.NET. Once you get it to that point, there are tools that can convert to C#.
Why VB.NET first? The learning curve is much shorter and at least some VB6 code will work without too much fuss. (beware of the whole int/short/long issues)
If you want a direct conversion to VB.NET from VB6, I VB 2008 was the last IDE that had a migration tool.
"Go forth into the source" - Neal Morse
|
|
|
|
|
I understand your logic and agree to some point. But as someone who started in VB5, then moved to VB6, then moved to VB.Net (using your logic!!) and then finally to C#, I really wished I would have gone straight to C#. There's a good argument that VB6 and VB.Net are somewhat similar in syntax, but there are enough differences that you ARE learning a new language. So you might as well move to whichever language you actually want to learn.
While using VB.Net, I used to wonder about all the people ranting about it. I understand the lazy variable declaration issue, but if you just set Option Explicit then you're good. However, now that I use C# I understand their viewpoint, although I don't fully share it. But I would choose C# hands-down over VB.Net. It's a much nicer and more concise/readable language. VB.Net is too "wordy".
Just my opinion from my experience. Still, kmoorevs makes a good point.
Mike
|
|
|
|
|
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.
|
|
|
|