We’ve had another newsgroup developer ask if it makes more sense to convert an existing Visual Basic 6.0 application to Visual Basic .NET or start over “from scratch”. We’re going to get this question more and more over the next decade (or two) as people gradually move to .NET. I think it would be useful to discuss the issues involved. No, I don’t know all the answers as my focus has been on data access interfaces.
As far as the data access layers of your application, I can see several alternatives. None are completely satisfactory as each has their own set of issues.
- Run existing COM-based ADO (what I call ADO “classic” or ADOc) code in a .NET application. The Visual Studio conversion wizards can move about 90% of your ADOc code so it can run in a .NET application using the COM interop layer—assuming you use Visual Basic .NET. COM interop puts a wrapper around the COM classes and tries to translate what COM expects to what .NET expects and back. Unfortunately, ADOc does a number of things that COM interop will never understand. This means that you’ll find that some code simply does not work the same. Sure, most of it will work, but you’ll forever be wondering if that issue you’re fighting is caused by COM interop or something you’ve done wrong.
- Convert existing ADOc code to ADO.NET (even version 2.0) can also be problematic. The default Recordset in ADOc is a server-side cursor—ADO.NET does not now and will not support server-side cursors for the foreseeable future. The earliest we can expect to see any server-side implementation is in Orcas (some time in the next three years). If your application is not built around server-side cursors (as most ASP applications) but uses ADOc disconnected Recordsets, the logical conversion from and ADOc function to an equivalent ADO.NET function is pretty easy. What makes things harder is that while the class names in ADOc are similar to the ADO.NET implementations, they are really very different behind the class names. I like to say the only thing ADOc and ADO.NET share in common is the fonts—but it’s not really that bad. Given the differences in functionality and features, I don’t think it’s useful to try to convert ADOc to ADO.NET on a line-by-line basis. Instead, I would examine a data access component and determine how to implement the equivalent functionality in ADO.NET—now that can be fairly straightforward. This means if you have a function that executes a stored procedure or ad hoc SQL query and returns a rowset, you can write that very quickly in ADO.NET. Can Visual Studio help with the conversion? No, not really but it can generate code for you if the function is fairly simple.
- If you’ve built a multi-tier application then you might consider converting the application in phases. The data access classes might be left in ADOc at first but in any case you’re going to want rethink this strategy eventually.
The real disadvantage to ADOc is its dependency on the MDAC stack. Fortunately, Microsoft has recently addressed that issue as well. The new SQL Server Native Client OLE DB provider can be used in existing ADOc application—but only when accessing SQL Server. The new SQL Native Client provider is not dependant on MDAC. This means you'll be able to access all of the SQL Server 2005 features from VB6 (although I have not tested this...).
If you’re still using JET with your VB6 application, you’re stuck with OLE DB in ADO.NET as well. While ADO.NET applications are not as susceptible to DLL hell issues, you’re still coupled to a deprecated technology—unless Microsoft Office decides to use the shock paddles on MDAC. I’ve seen some towers being set up on campus to collect lighting so who knows. As you convert to .NET I suggest you consider switching away from the home-office JET database to the better-supported and more secure Express version of SQL Server.
When we build Visual Basic 6.0 data access applications, we usually leverage the built-in (or more likely) third-party bound controls to construct the UI. When you migrate to Visual Basic .NET you’ll discover that the language is vaguely familiar but the UI controls are not—especially when you try to use more sophisticated controls like the DataGridView or other complex bound controls. The properties, methods and methodologies are very different. The new controls have a bevy of features that make it easy to do some things you wrote code to support in VB6. They're also missing some properties and methods so plan on rethinking your approach to bound controls. Data binding in the CLR languages has been totally rewritten (and rewritten again in the 2.0 Framework). That’s the good news. The bad news is that this means the binding code and techniques you used in Visual Basic 6.0 won’t work—or at least not in ways you would expect. The familiar cursor-based ADOc ISAM Recordset is gone. It’s been replaced (sort of) by the DataTable. You can’t “MoveNext” in a DataTable—you don’t need to. I could go on (and I do in my books on ADO.NET), but you get the idea. The best thing to do IMHO is simply forget ADOc and Visual Basic 6.0 and consider the .NET platform as something new, more powerful and something you need to learn. Those that don’t can plan on early retirement.
I encourage comments on this process. Have you had a good, bad, successful, unsuccessful, easy, painful, never-ending experience converting from Visual Basic 6.0? Post your comments here.