This topic has been in the ’news’ lately (well, at least in the blogs) and I’ve been considering replying…. but it turns out I don’t have to, because Dave Totzke has done it for me. I don’t really agree with his comment that we’ve kept C++ alive because Office is written in it… it is actually because the managed world doesn’t replace the need to write native code against the underlying hardware and OS. We need to have at least one avenue for folks to write the high-performance graphic software, device drivers, network packet filters, etc…. so we need unmanaged C++ to stay. There isn’t a similar need for new development on VB6.

Yes, it is hard to upgrade complex code bases, but when you install VB.NET it doesn’t uninstall your copy of VB6. It is possible to maintain an existing code base while you write new code in .NET and then interop as necessary between the two worlds. Within MSDN, we have Access applications that pop-up Windows Forms when you click certain buttons… we have VB6-based add-ins for Outlook and Word that are simple wrappers around .NET code and some that are a mix of VB6 code and VB.NET code…

There are some things that were in VB6 and are not available in VB.NET that I feel still need to be available, but I think they could be made available as .NET components, ActiveX components, or add-ins to Visual Studio. Take DDE for example, it just isn’t part of the .NET Framework, so I think it would be nice if we had a small component that allowed me to access DDE from within .NET, fired events when new data arrived, etc… I wish that people would put their effort towards building/requesting these types of components instead of advocating something that just isn’t a good idea. At the very least, push for more effort to be put into the upgrade process, lets get someone to build more than just a wizard, build a tool that does the upgrade and includes a ton of additional libraries to help with transitioning older code. That would be a lot of work, but the end result is still better than just doing incremental development on VB6.

By the way, this is as good of time as any to point out that I do believe that there is something missing in the .NET world right now. We need an Access-like tool for .NET… not what VB6 was, which was really much too complicated for the level of developer I’m thinking of… but something that is a drag-and-drop database form focused application creation tool. Like Access, Filemaker Pro, Hypercard, etc… but producing .NET code behind the scenes so that you can extend simple applications created using this tool with code produced out of VB.NET/C#. I think I’ll call it Access.NET 🙂