Does any one know of a Delphi to .NET converter (either C# or VB.NET)? I've inherited a bunch of Delphi code, never seen Pascal before and rather than learn it, I'd rather just try to use an automated converter, if available, and clean up the code after that. Can't seem to find this kind of tool anyway I search - maybe that's because one doesn't exist - so I thought someone here may know.
Spare your time.. If you want to convert code because you don't understand or like the original language, my advice is: "Don't bother" (believe me, I've made numerous attempts to convert code). Especially if you're planning to just make a couple of small changes to the existing code.
You won't be able to convert the code and have it compile, let alone run flawlessly.
You might be able to translate portions into something that is syntactically correct, but you won't have the libraries or frameworks (RTL/VCL) that the software relies on.
You're going to have to go back to the Delphi code and be able to understand what's happening to fix parts that are not working. It's going to take more time to fix bugs in the generated code than it would take to study the existing code and rewrite it entirely.
And if you have the time to rewrite software in another language, you might as well just roll up your sleeves, learn the original language, and change what you need to change in the existing code.
I have no experience using these tools, but here are a couple:
Delphi2CS
TurnSharp
A similar question was asked:
What tools exist to convert a Delphi 7 application to C# and the .Net framework?
Related
I've got a contract where I have to continue the development of and old application suite that was programmed in VB5 back in the days.
I've bug to fix and new feature to develop.
So I have a few choices:
Keep programming in VB5
(NOOOOOOOOOOOOOOO!!!!)
Convert VB5 to C# (How??? Is it
possible without going insane?)
Rewrite the whole application suite
(Very time consuming)
Is there any other choices? What should I do?
EDIT: Ah and also, it relies on an ACCESS database which I'd like to move to SQL EXPRESS. Because it's a crazy database made illogically by a stupid programmer from the '90s lol.
Thanks
The choice I've made every time is to just re-write, or purchase a suitable replacement if I could find one.
I have tried doing incremental upgrades from VB6 to VB.NET, but I don't like that approach because it leaves around ActiveX controls that I'd rather not use. Re-writing is cleaner.
I don't think there is a converter from VB5 to C#. You might be able to go from VB5 to VB.NET and then convert to C#, but in my experience it's less time-consuming to re-write than it is to try to upgrade and fiddle around with the broken code.
There is no reliable way to do 2) so it's 1) or 3).
And I don't think your customer wants to pay for 3). But maybe you can sell it on reliability, support etc.
Otherwise you're stuck with 1)
One approach would be to tactically rewrite sections of the code in C# - you could start with the areas you are likely to be bugfixing the most, create C# assemblies to mirror the functionality, and then expose these to the VB5 code through COM interop.
A good suite of Unit Tests would be highly recommended for this approach!
I've heard that Working Effectively With Legacy Code by Michael Feathers is the best book around for understanding how best to chop up a problem like this.
The answer definitely depends on a lot of factors. I recently had a similar project (a 10-year plus old VB6 Windows app with a large, spaghetti codebase), and addressed it with a "hybrid" approach:
Bugs were fixed in VB6
New features were developed in .NET 4, using COM interop
We developed some WPF dialogs and styled them to go with the old interface to handle new UI.
This option only works when the new features are fairly independent of the main app, but it has the advantage of at least taking advantage of the productivity of new technologies and also paving the way for future conversion.
I've recently finished working on a project where we converted a lot of legacy VB6 applications to C# using Artinsoft's VB Upgrade Companion.
It's a tough call to decide which approach is the best. In a lot of cases, converting the code can end up being very painful, especially if there is a lot of logic based around features which are significantly different between the two platforms (e.g. one-indexed arrays, or handling errors via the Information.Err object instead of through exceptions).
On the other hand, if you try to write it from scratch, there is a good chance that you'll accidentally change some subtle behaviour that isn't immediately obvious when reviewing the original VB5 code. Things like this can be difficult to track down.
A good compromise is to use a converter to port the code over, then use this as a guide for writing things from scratch, as there will hopefully be places where you can just lift converted code across straight into the new code base. At the same time though, you get the benefit of writing more maintainable code everywhere else.
With all that said, if the original VB5 is well written and (relatively) well architected, then I would recommend against any sort of upgrade. You will spend far more time trying to match the existing behaviour of the old application than you would just working on the old code.
Good luck with whatever you decide to do - you'll need it :)
Maybe you should first convert to vb.net, and then to C#?
If you just need to fix a bug, and it's a reasonably simple bug, and you don't anticipate much more work beyond that - stick with VB5. Anything else will introduce far more work.
However, if this is really a "live" product which you expect to work on a lot in the future, I would probably start from scratch. My guess is that you've learned a lot about design and architecture since writing the app - so you might as well take the opportunity to write a more maintainable app. (You'll also probably have learned which design decisions in the original app ended up being mistakes.)
I've been playing with Java for years as a means of developing quick and easy tools for repetitive tasks. I am not a true "developer" in the traditional sense, but I have lots of experience creating a wide assortment of tools and PoCs.
Unfortunately for me, I have noticed many shops are specifically looking for experience with C#, and not so many for Java. Even here on SO, there are more questions and more followers to C# related issues than Java. My preference will always be Java over C# simply for the cross-platform compatibility, but since the languages are so similar, I believe it would be beneficial for me to cross-train. I have already dabbled in other languages and scripts (VB and other BASIC flavors, Javascript, VBScript, ASP, JSP, PHP, etc.) so adding another isn't out of the question.
My current Java environment simply consists of a text editor (primarily jEdit for its plugins and layout) and homemade scripts to compile/jar my projects. I don't like to use IDEs because I want full control over my code and don't want a program writing code for me. (I also prefer to write my own code as opposed to using any sort of external library/package, if feasible. It helps me learn and greatly reduces unnecessary code.)
Therefore, what are my options for a non-IDE C# SDK? Libraries are obviously not that important to me. I've heard of Mono, which appears to separate the functions, but haven't tried it yet. What other SDKs exist that are similar to a simple Java SDK combined with a text editor?
Using an IDE doesn't have to mean anything writing code for you. I'm not generally keen on designer-generated code, but unless you decide to use a designer (or snippets etc), Visual Studio won't be writing code for you. Of course it will create a skeleton class for you when you create one, add the appropriate method signatures when you implement an interface etc - but is that boilerplate really something you want to write yourself?
I'd also suggest that your policy of not using external libraries is a bad one. I agree that it's useful for educational purposes to sometimes reimplement something, but it means that the code quality is likely to end up being worse... why would you not want to use code that has already been used and improved by many other people? Yes, you need to be careful about what libraries you use - but you really don't want to do everything yourself... not if you want to be productive, anyway.
I often use a text editor and command line myself for simple test code (e.g. for Stack Overflow questions) but I wouldn't dream of doing that for "real" code that I plan to keep.
Honestly, a lot of C# and .NET is about learning the tools; Visual Studio gives you a lot that you wouldn't be able to do with a text editor. There's a free version, and I highly suggest you check it out! People hiring will want to know that you're familiar with the tools they'll most likely be using.
You can just start with Notepad and csc.exe, the the command-line C# compiler that ships with the .NET SDK.
However, IDE is not necessarily synonym for code generator. I would download Visual Studio Express and start with empty Console projects.
Have fun!
Don't forget you can build/assemble C# projects using MSBuild and a .sln file if you really want. But the IDEs will make life a lot easier.
The IDE will not write code for you, it will help you writing code. Using libraries will help you concentrate on what you really want to program, not the things that already have been done.
Check into AvalonEdit, the text editor component of SharpDevelop. It is an open source text editor that has classes that could implement features such as intellisense and syntax highlighting. You would only have to use as much of it as you wanted and you could embed it anywhere you would use a text box control.
If you are familiar with Ant from Java then you could also check out NAnt to do your compile phase.
As far as I know, with Visual Studio you also get a command line C# compiler, csc. You could use a text editor and manually compile your C# code with that on the command line if you really want - that wouldn't be very practical however when your project contains more than a handful of source files.
If your project becomes bigger, you could use a tool like NAnt, which is a .NET version of the popular Java build tool Ant.
I agree with Jon Skeet about that your way of working is not very practical. If you are really looking for a software development job, you'd better learn to use the tools that other developers use. An employer will also not accept the fact that you'd want to write all the code yourself instead of using libraries. By using libraries instead of writing it all yourself you save lots of time, you are reusing well-tested code and your code will be much easier to maintain by other developers.
What's the fastest way to convert an existing Vb6.0 win-based application into a c# win-based?
The core language is so different, that I would have to say start from scratch, and copy only the complicated code bits. If you start from scratch you won't have to deal with all the VB6 problems, while utilizing all the C# power.
VB6 has no real classes or OOP, which makes very different from C#. Also, there is very little control on the event manager (SubClassing).
So, start from zero, copy the UI layout, and think about how would I implement this in C# in the first place, it will make your life easier.
I think the fastest would be to convert it to VB.net. Check the following question for this answer
VB6 to VB.net conversion
ans then converting it to c#. But I feel converting manually will be the better option as you can re engineer the application and may be make it simpler.
Converting the code from Visual Basic 6 to C# should best be done using an automated migration tool, like ArtinSoft's Visual Basic Upgrade Companion, which supports migration to C#.There are several reasons for this suggestion, aside from my experience with the tool.
First, even if you migrate from VB6 to VB.NET there are several language specific features in VB.NET that will not translate directly to C#. So even if you're using a VB.NET to C# converter you'll have to handle these special cases (or find a tool that handles them for you). These can include optional parameters, AddressOf functions, Visual Basic Compiler assisted operations, like Information.Err(), and Unstructure Error Handling to Structured Error Handling using Try / Catch statements. Another thing to consider is that the VB.NET compiler is limited to showing only 100 compilation errors, and compilation errors can be quite common when migrating. When moving to C#'s the compiler and other code analysis tools like ReSharper can give you a better picture of the challenge ahead, and help you detect common compilation error patterns.
Second, by migrating directly to the target language you can focus on using the features available for that language from the start, no intermediate steps. Otherwise, you'll basically end up doing two migrations when you could have focused on just one.
Third, as renick stated even though migration tools can produce hundreds or thousands of issues, most of these have relatively easy solutions. Some of them can be fixed using a find & replace function. Commercial solutions have the added advantage that they support the migration of third-party UI controls to .NET equivalents.
Also a migration can be much faster than a rewrite, you still have to write code but only for the areas where there are issues.
Granted there are applications for which a migration is not an option, but for those that fit the use case for a migration, it's a very effective means of switching platforms. You shouldn't discount the option right off the bat.
Total rewrite. MS has some migration assistance, but I believe it's VB.Net only. But why look at porting, surely you'd be better off now rewriting the app, and just interop if you have any legacy parts that you need to keep alive. And only migrate the best bits. Use this as a chance to truly improve the application.
If you need it quickly; then don't go hand cranking it - you'll miss stuff out and tear your hair out!
I investigated this product a couple of years back and I felt this product was the best. it converts from VB6 to C#. They have a free trial too.
Try ArtInSoft. This company will migrate your VB 6 code directly to C#.
I am looking to switch to C#. I come from a C / C++ background but C# is a little different for me. I am switching mainly because of Silverlight and MVVM; all examples are in C#. Any information is in C# and I am confused when I read through it all.
What is a good place to start learning C# when starting with existing C / C++ knowledge?
Start writing code in C# ASAP. Only way to learn the language is to write it. You already understand VB.NET. You've got a huge lead on anyone new to .NET.
Take a smallish application you've written in VB.NET and methodically change it over to C#.
You'll learn the syntax, etc. quickly.
Write all of your future projects in C#. Just force yourself into the change and you'll do fine.
Read the best C# books. :)
The Wikipedia article "C Sharp (programming language)" is a decent introduction to C# as a language.
Shortly after learning VB.NET I decided I'd rather be coding C#. I learned it by reading a couple of books and working on a project. Slowly, I got my coworkers converted over to the language from VB.NET as well. The languages are very similar, some code conversion is just a matter of changing syntax.
However, if you've ever worked with a true VB'er you will see VB specific functions used in their code that'll make you scratch your head. There are string handling functions and casting functions for example that you will have to convert. Also, C# has no RaiseEvent. Events take a little more effort to understand in C# because you need to wrap your mind around delegates (C++ function pointers/callbacks). As others have said, if you are coming from C++ this shouldn't be too difficult.
Many people go on about needing to work on a project to understand a language, which I agree with. However, there are features of languages which you will never know about if you don't pick up a couple of books and read about them. I've been able to show my coworkers many useful techniques just by reading a couple of books.
Lastly, C# is a great language. I was very skeptical when I first started using .NET, but now I know that MS got the right talent together for that framework and language.
Good luck.
As you know C++ (as you wrote in the question) and VB.Net (as you mentioned in the title), C# won't be hard for you if do know them both well. If this is the case, just grab any source in C#, and read it.
By the way, the article from wikipedia is a very nice intro.
One thing that may work for you is to use a converter
Write your desired code in VB.
Paste small pieces of code you don't know how to write in C# into http://converter.telerik.com/ and convert.
Manually type the result into your C# project.
Gradually, reduce your reliance on converter as you become more familiar with language.
That is enough to get you started, however C# has language features that VB does not, or VB offers in a way that is so wordy that no one really uses it.
The more features you will come across as you look at code examples from around the web (like on stack overflow), and you need to either look up syntax or function manually, or convert from C# back to vb to understand what it is doing (use same converter). Or, just paste it in and see what it does.
I have a VB5 (non .net) project that I would like to upgrade to a c# project. Has anyone have any suggestions on methods or free tools that are avalible to help me with this.
Thanks
Brad
You are better off with a straight rewrite.
What I would suggest is first convert the project to VB6. It'll be much easier to go forward from there. There are a number of tools to help you do this. There is VBMigration Partner and there is vbto. I've not tried either so YMMV.
If costs are a constraint you could try this: there is a wizard in Visual Studio that will attempt to upgrade VB6 to VB.NET. It's not 100% accurate and you WILL have to write code for things VB.NET does not support such as control arrays, etc. Once the code is in VB.NET you can use a tool like SharpDevelop to convert the VB.NET to C#. It'll be a bit tedious but i suppose all roads, no matter how convoluted, lead to Rome.
In case you were able to migrate it to VB6 you can use the code advisor to see how you can fix your project to be compatible to vb.net, then you can migrate to vb.net, in case it success, you can use this tool to convert it to c# or the Reflector.
I give it a chance of 1x10^(-100)% to work.
Good luck.
If you're about to convert VB5 to .NET (whether it's C# or even VB.NET) the fastest way is to restart from 0 your implementation so you can take full advantage of .NET Framework classes. I don't know if there are tools to do this conversion automatically.
It's rarely a good idea to do a strict conversion from one language to another, particularly when they are as different as VB5 and C#.
Theoretically, you could convert VB5 to VB6 and then VB6 to VB.NET and then VB.NET to C#, but that just sounds crazy to me as I type it.
C# is so much more powerful than VB5 that you wouldn't want to covert the code anyway. After all, it likely has a poor design due to VB's weak OO capabilities.
I'd instead recommend re-implementing the functionality you need in C# (or whatever other language you want to use).
I know there exist a conversion tools, not sure though if there are some for vb5.
However, i'd recommend performing a redesign of the project, taking advantage of the .net features unavaiable in vb5. Specially it would be good redesigning for a OO language.
Migrating VB5 to C# just to have .NET is never a good reason. I would prefer to have a good look at the assumptions and design decisions I made in the VB5 version, rethink them all, add new ideas, sketch the UI and improve it to look closer to a modern one.
Then it's a new project, I wouldn't even call it a rewrite, because so much would have changed.
I've migrated a small 1-tier VB6 application to C# and I will never do it again.
There are applications out there that do a rather good job migrating from VB6 to VB.Net.
//Magnus
I’ve done it in the past but don’t recommend it. Getting the project to work correctly after the ‘auto-migration’ was not worth the effort. I ended up rewriting the program and was better off because of it.
Having done this myself I talk about the issues involved here.
Basically as ocdecio you are looking at least a partial rewrite. You will likely need to refactor your forms to move as much code out of them as possible. You will also need to refactor any VB6 specific features to work behind a interface that you can reimplement in .NET. Notably the Graphics commands, and the Printer functions. Migration Tools are usually worthless for any serious project.