What C# tools do you recommend?
-
Resharper. And don't give it up, C# isn't terribly difficult. Like an English muffin, it just has many nooks and crannies, and is infinitely better with butter(Resharper). I would suggest a functional clone rather than direct conversion, though. It's unlikely that a VB6 program is structured in a way that will work well in C#.
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli
Nathan Minier wrote:
Resharper.
:thumbsup:
Eric
-
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
-
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 : - WinForms - 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. See my answer to another similar question here, that includes links to tutorials and demos: Generic Multi Purpose .NET Layered Framework[^]
+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 am trying to convert my VB6 code to C# (Desktop programs). I am looking for tools that will help increase my efficiency and shorten the learning curve. Any suggestions? Other than "give it up!" :laugh:
If everything seems to be going well you are obviously overlooking someone or something....
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
-
Thanks, I will check it out. And yes I am actually re-writing a functional clone as you suggest. Sorry I did not make that clearer. The Program is around 400,000 lines of code. :omg:
-
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. :cool:
-
I am trying to convert my VB6 code to C# (Desktop programs). I am looking for tools that will help increase my efficiency and shorten the learning curve. Any suggestions? Other than "give it up!" :laugh:
If everything seems to be going well you are obviously overlooking someone or something....
-
BOTH! They are not mutually exclusive.:cool:
It is far better to kill 2 birds with one stone that one bird with 2 stones.
-
BOTH! They are not mutually exclusive.:cool:
It is far better to kill 2 birds with one stone that one bird with 2 stones.
-
I am trying to convert my VB6 code to C# (Desktop programs). I am looking for tools that will help increase my efficiency and shorten the learning curve. Any suggestions? Other than "give it up!" :laugh:
If everything seems to be going well you are obviously overlooking someone or something....
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 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.
-
I am trying to convert my VB6 code to C# (Desktop programs). I am looking for tools that will help increase my efficiency and shorten the learning curve. Any suggestions? Other than "give it up!" :laugh:
If everything seems to be going well you are obviously overlooking someone or something....
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 . 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)...?
-
Resharper. And don't give it up, C# isn't terribly difficult. Like an English muffin, it just has many nooks and crannies, and is infinitely better with butter(Resharper). I would suggest a functional clone rather than direct conversion, though. It's unlikely that a VB6 program is structured in a way that will work well in C#.
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli
Presumably, in a world of reuse, I am the only one concerned when I hear “rewrite”, “redesign” or “refactor”. IT staff spend an inordinate amount of time reinventing the wheel over and over rather than moving on and accomplishing something new. I suppose it maintains the inflated “need” for IT workers.
-
Presumably, in a world of reuse, I am the only one concerned when I hear “rewrite”, “redesign” or “refactor”. IT staff spend an inordinate amount of time reinventing the wheel over and over rather than moving on and accomplishing something new. I suppose it maintains the inflated “need” for IT workers.
Or it could be that one obsolete language is architecturally incompatible with best practices in another. Crazy, I know.
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli