Using COM in ASP.NET, or use a standard DLL instead?

Question

We are moving a classic ASP application with VB6 COM objects, over to the .NET world, and we are puzzled about how to migrate our COM objects in as straightforward a manner as possible. I have found a lot of 'how-to' articles, but not much in the way of 'why' articles. Are we better off rebuilding the COM objects as standard DLLs which query the database (this is a DB-heavy application), or should we rebuild them as new COM objects in C#? What are the advantages and disadvantages of each approach? Is there yet a different approach we should consider? We are not yet a very strong shop in .NET so any and all suggestions are most welcome.

thanks in advance, Mike

Answer 1

My experience would suggest you should re-write the COM objects into a DLL because the risk is low that something will break during conversion and the time this will take is a LOT shorter than re-writing in C#.

Migrating to .NET can only really be done by hand, but once in a COM DLL you can do this on a part by part basis.

Answer 2

This is a hard question, as there are a lot of variables. Let's assume, for this thread, that you have a decent amount of separation of concerns and a set of COM DLLs with decent performance.

Assuming the above and taking your post into account (tons of code in the COM components), the path i would normally look at is rewriting the UI in .NET first and use .NET wrappers to call the COM components. This is easily done by referencing the COM component. Moving to some native DLL method might help if you have a performance problem once wrapped, but it is a more complex direction to set up the code to invoke native methods, so I would not head that route first.

You then have two directions to possibly head. Focus on user stories (usability) or focus on migrating individual libraries (COM DLL >> assembly one at a time). I prefer the story direction, althought you will potentially end up with dead code. Rather than think about migrating, I would rewrite one story at a time, so you are focused on doing it right in .NET. Migration ends up with a lot of COM code written in .NET, which is nasty.

I would consider finding at least one .NET expert, whether hired as an employee or a consultant, so you do not let old habits leak in bad code. This expert should be hired primarily to keep you on the right road and not as another set of coding hands. Not saying the person cannot code, but make sure you do not over utilize this person as a warm body, as his primary job, during development, is to keep you from shooting yourself in the foot. If you can get this person in early, consider hiring someone with some architecture experience to help design the application for .NET. It is more expensive to experiment up front than it is to refactor later.

DON'T try migration programs. They DON'T work. You are not only making a development platform shift, you are making a complete paradigm shift. If you try to use any automated tool to migrate code, you will end up with an inferior application.

One other thing. If you are a VB shop, consider moving to C#. It sounds counter productive, as there is a learning curve, but sticking with VB means you will try to write VB6 in VB.NET. The end result is a bad code base that is hard to refactor.