We Keep Coding

Less time consuming : Rewriting or converting an app from VB5 to C#

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.)

What's the fastest way to convert an existing Vb6.0 win-based application into a c# win-based?

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#.

Scripting Automation within VB.NET application

The software company I work for offers data conversion as a service for new clients who have previously used other similar software. I've written a VB.NET application to automate common conversion operations, and have separate logic between known vendors. A particular file layout has become rather common, but due to the nature of how this particular competitor's application stores information, certain fields mean one thing for one client, and another for a different client.
Certain elements within this vendor's format change every time, so I've written the application to account for that. Because some data fields mean different things to different vendors, I have to change my mapping code every time. This wasn't an issue when I had one of these every six months or so, but these are becoming much more common and I would much rather find a way to further automate this process.
I was thinking of implementing a simple interpreted scripting language that would allow me to save the conversion settings for the client in a text file, so I'm not having to feed the settings into my app every time I run it. My goal is to have the time spent in implementing this pay off in faster conversions in the long run.
This is the example I had in my head:
# this is a comment
RECORD INCLUDE(source[Class] != 'I' && source[Category] != 99);
FIELDMAP
destination[name] == source[name];
desintation[address] == source[mailingaddress1];
...
END FIELDMAP
BEGIN
# logic goes here
END
I don't want to make this more complicated than it needs to be. I admit that I've never even looked into scripting and am kinda clueless as to where to start or what other considerations need to be made.
Are there already scripting libraries for .NET that will do most of what I want? Is scripting the wrong way to go about this? I really don't want to reinvent the wheel if there is a better way.
Thank you for any help. :)

IronPython (one of the the DLR languages Jake referred to) is a .NET implementation of the Python scripting language. It allows you to access .NET code (including framework classes and class you've written) and would be an excellent choice for this sort of task.
It doesn't have any real dependencies (other than the .NET Framework) and you won't need to learn much learn much Python-specific syntax in order to get the job done.
(If you decide to go with IronPython, I recommend using Notepad++ as your editor.)

Rather than write a custom language, you could embed any of the DLR languages (IronPython, IronRuby, or JScript), or you can use compiler services to compile VB.NET from your application.
Another idea ... if you only need to change the mappings between variable names, maybe you could just come up with a little XML file that would define the mappings.

Feasibility of shared code between .NET and Silverlight?

Having just gone through a small experimenting session to try to see how much work it would take to bring our .NET class library, or at least portions of it, into Silverlight so that we can reuse business logic between the two worlds, I'm wondering if others have experience with this sort of thing.
The things I noticed, off the top of my head:
Lots of attributes missing (Browsable(false) for instance)
Lots of interfaces missing, or present, but empty (ICloneable is hidden, ITypedList missing)
Reflection differences (everything reachable needs to be public)
Some base class differences (no Component?)
So I'm wondering, is it really feasible for me to even look at this as a possibility?
I got the initial code running, but I had to just comment out a whole lot of the base functionality, mostly around handling lists since they are based on ITypedList and some base classes. Apparently I need to change to ObservableCollection in Silverlight, so a whole of of base-code needs to be changed in order to cope.
The actual business test class I created is 99.5% identical to the one I would've made for .NET, only some minor changes that would easily be usable in .NET as well, just not as I would've made it before looking at Silverlight. In other words, it looks feasible to share business logic, provided I can make the base classes compatible.
Just so I'm clear, what I'm talking about is that I would basically have two project files, one for .NET, and one for Silverlight, but the actual C# source code would be the same, shared between the two.
So does anyone have any experience with this? Any tips or guidelines?
Will it be worth it? It certainly warrants more looking into.

It is definitely feasible.
It's done on a project here; the Silverlight project includes the C# ones, and there are some #IF statements handling some things (like log4net declarations), and other times things are just re-implemented. But in general, it's a huge win, and you should definitely attempt it (and certainly, we have, successfully).
-- Edit:
One point though, is that our OR/M (LLBLGen) didn't have inbuilt support for 'simple' objects to send down through Silverlight; but someone had written a plugin that handled it, which helped. So it may be worth considering what sort of DAL you're using, and how well it supports Silverlight.

What I've done to facilitate this is:
Frequent use of partial classes and #if !SILVERLIGHT to separate code into parts that Silverlight can handle.
Use of code generation whenever possible. For example I've been experimenting with T4 templates that generate Silverlight equivalent attributes (DisplayAttribute instead of DescriptionAttribute for example)
Whenever there's an interface/attribute that isn't implemented by Silverlight (such as IDeserializationCallback, ICloneable, INotifyPropertyChanging) I will create a dummy interface of the same name in the Silverlight application as long as I know that the fact that the implementation won't be used is not a problem.
Finally, it's worth noting that in Silverlight 4, the assembly format does allow for sharing of binaries between Silverlight and .NET as long as there are no dependencies that Silverlight does not support.
One more note about the separate base classes - it may be worthwhile to create an abstract class that derives from ObservableCollection in Silverlight and BindingList (or whatever you're using in .NET) to minimize the impact on your typed collections.
UPDATE
Today I was working on porting some .NET code to Silverlight that made heavy use of the System.Diagnostics API's like TraceSource, SourceSwitch, etc which do not exist in Silverlight. I created very minimal implementations of these in the Silverlight project and put them in the Einstein.Diagnostics namespace. In doing so I decided I needed a convention to easily identify code that was mimicking the .NET Framework vs. my own code. So I renamed the placeholder files to prefix them with an # sign. I also prefixed the class names in those files as well. The nice thing about that is that the # sign does not actually change their class names as far as the C# compiler is concerned. So #SourceSwitch still compiles to be Einstein.Diagnostics.SourceSwitch but in the code I can easily see something is up. I've also decorated these classes with a [SilverlightPlaceholder] attribute.

I do this with protobuf-net, and I use a few approaches:
conditional compilation symbols in the project file to trigger subtle code-branches (yes, it isn't perfect, but it works)
re-introduction of some things; attributes might be an example here - your code can still use re-introduced attributes, even if the framework code doesn't; as a more extreme example of this, for compact framework I had to re-introduce a good chunk of the Expression API, which was fun
just drop some things ;-p
However if you are using ITypedList (which you mention), I can see that whole approach falling apart pretty messily; component-model is complex enough already, without having to force your way through the hacks too. It really depends quite how far you've gone down this road. Maybe 4.0 / dynamic will open up some of these options again?

One possible fix to your issue is to copy the missing code from the Mono project. Back in the day, I did a small project with the Compact Framework and it was missing the entire System.XLM namespace. I just copied the entire thing from Mono into my project, compiled it and it worked great with minimal changes, iirc.

When to create your own dll what should be in it

I as of yet, have not had a need to create a dll in .NET as my programs tend to be distinct from one another (and I haven't programmed for too long). However I am starting to gather a library of regularly used methods now which tend to have copies in lots of my programs (or similar methods that could be made more generic).
As I understand it a dll should be created to share common methods between programs.
So I can put my methods in the dll, what about things like custom dialog boxes and common forms. I currently have a custom error form and a print preview dialog which are used in almost all my programs. Is it good practice to put these in a dll?

"Good practice" in this case really relies on how much code-duplication you're cutting down on. If these dialogues are used throughout a lot of your programs and they take up a lot of code, then yes, it's probably a good idea to move them to a shared space.
But don't be tempted to throw everything in there. You'll find yourself having to override it and by that point you're probably writing more code than you were before. Keep things simple. Keep them generic. Keep them useful.
Before you start, though, be aware that you are creating a dependency tree. If you update your library chances are you'll have to put in some time maintaining your apps that use it... But this is no different from using a third-party lib.

To create a new dll, you just add new project (library) to your solution, and add it as a project reference to your main programme.
It is possible to put anything you want to this project. All dialog boxes, user controls, etc. are just classes, so you can share them as easily as any other class. I think it is good practise to share as much as possible.

Sure why not?
What you're building here is actually a small framework, pretty much like the .Net framework itself. Everything that you think is common between your applications can be put in the assemblies: forms, methods, business logic, exceptions, common data access.
When your framework grows you might want to split up that common DLL. For example if you have common forms in a DLL and you also develop batch applications then they don't need to reference to the DLL containing the WinForms specific classes.

Alternatively you can put the source files for these methods in a common place and just add them as links when you include them in your project/solution.