I started with a VB6 project a few years ago (company's custom ERP system) and I've slowly been migrating it to .NET. It's somewhere around half-done.
First of all, converting from VB6 to VB.Net is almost always a bad idea (and I did a lot of research on that). There's just too much different. Also, if your boss thinks that VB.Net is "just like VB6" then he's completely mistaken and you have to change his outlook fast.
My strategy was to keep the two code-bases separate and maintain them separately and then slowly move entire modules from VB6 to .NET but only when there was a significant change about to happen to that module, so we could amortize some of the cost. Even so, rewriting is a big expensive and risky task.
There are two ways to integrate existing VB6 with new .NET code (and you'll probably be doing that for a very long time, so you'd better get used to the idea). The first way I went about it was to start writing small modules in .NET and then have the main VB6 application launch the .NET executable passing in some command line parameters. This worked, but be warned that .NET has a start-up time hit of 4 to 10 seconds, so you're limited in what you can do this way.
Once it started to get really painful, I flipped the strategy and used the method from this CodeProject article to display the existing VB6 forms in my main .NET application. Once I went down this route, I was able to incur only one .NET startup time hit, and use ClickOnce for deployment, which was a godsend compared to how the VB6 app was deployed previously.
That said, here are the advantages I find in .NET over VB6:
- Better persistence frameworks (NHibernate, EntityFramework, Linq2Sql etc.)
- LINQ (I can't stress enough how important this is)
- Generics!
- Lambda syntax (solves a whole class of problems like "hole in the middle" elegantly)
- Similarly
Action and Func types
- Reflection (something that you rarely use, but when you do it's huge)
- Much better unit testing support (of course, I doubt you'll convince your other employees to unit test, but you should)
- ReSharper (and other refactoring/profiling tools) (10x better than MZ-Tools)
- ClickOnce and/or Setup/Installer Projects
- Windows Service Projects
- True object-oriented support (VB6 is based on COM and is really bad in this dept.)
- Static typing
- Baked in XML support
- WPF and Windows Forms (VB6's controls are very limiting)
- WCF
- Much more example code online
- Exceptions (VB6's error handling is absolutely terrible by comparison)
- Visual Studio's source control integration
Decimal type (VB6 never had a first class decimal type, even though it has CDec)- First class support for
Guid
- First class support for 64-bit integers
- Better collection libraries
- ReportViewer
- Multithreading, task parallel library
Disadvantages of VB6:
- You will notice a performance it. It might not be enough to worry about, but trust me, you'll notice it. VB6 compiles to native code after all.
To be fair, here are some disadvantages of maintaining a combined VB6/.NET solution:
- Maintaining two data access layers (assuming your VB6 app actually has one)
- Extra wiring to expose services/forms/etc. from one side to the other
- Twice as much complexity/architecture to keep in your head
Now, as you've hinted at, you really ought to rebuild your architecture from the ground up if you start writing code in .NET. However, it sounds like none of the people at your company are familiar with either the .NET and/or Java programming world, which is where a lot of the patterns and practices that are common to big enterprise frameworks come from.
If you take someone who's used to dragging a button on a form, double clicking on it, and writing some SQL strings directly in the click event handler, and that's been working for them, it's really hard to make them see an advantage to following SOLID design principles. On the other hand, if you bite the bullet and decide that all new code is going to be covered 90% or greater by automated unit tests, then you'll quickly realize that's really hard to do unless you adopt the SOLID design principles.
So you need to take a really hard look at the reality of the situation. In my case, I was the only programmer, and I was determined to have all new code be unit tested, even though I had no experience with it. I can't stress enough how much this negatively impacted what I could get done in the first week, even first months. Still, I was determined to do it, and I had buy-in from management. Most people don't have that luxury. Now I have lots of code and I just finished a major refactoring with almost no issues.
Realistically, you're not going to be doing unit tests, which means it's harder to justify principles like dependency injection to your team-mates. You're going to have to sell .NET on the merits other than architectural benefits. You have to focus on better library support and better tools. That's the only thing that will resonate. I would suggest the following in your demo:
- Create a Windows Forms project (stay away from WPF and xaml - it's too startling)
- Connect to a SQL database (some test database)
- Use Linq2Sql or EntityFramework to generate a data model for it
- Create a repository class that has a method to return some list of entities
- Write a query in that method using linq, point out the intellisense
- Point out that linq works on all objects, not just entities
- Show that if you change the database and regenerate the model, you get a compile error
- Drop a
DataGridView on the main window
- Demonstrate databinding by populating the grid with the entities from the repository
- Point out all the cool stuff about the grid that's so much better than VB6
- Create an .rdlc file (report)
- Make a simple report inside Visual Studio
- Drop a report viewer on the window and render the report inside the report viewer
- (Obviously you need ReportViewer installed and have practiced all this first)
- Come up with a "hole in the middle" problem and then demonstrate solving it by creating a method that takes an
Action as a parameter. Do this first by passing another method as the parameter, and then blow their mind by passing an anonymous delegate using lambda syntax
- Demonstrate generics by using the
List<T> and Dictionary<T1,T2> collection classes and show how it creates strongly typed code (VB6 has similar stuff, but it's dynamically typed)
- Write a
foreach loop that's embarrassingly parallel, use System.Diagnostics.Stopwatch to measure the time it takes to execute, then use the task parallel library to change the loop into a Parallel.Foreach loop and demonstrate the speed-up, assuming you're on a multi-core machine.
- Demonstrate the ability to add a global exception handler (this is something that VB6 can't do)
That's what I would do.
