Getting .NET Framework 3.5 and VS2008 Adopted

I'm currently trying to pro-actively drive the adoption of the .NET Framework 3.5 and VS 2008 within my company to start using it when it is released early next year.  Our current standard is C#, using the .NET Framework 2.0 and VS 2005 SP1.  We have a small portfolio of applications still running on .NET 1.1.  Unfortunately we also have a big portfolio still running on VB6 .  As part of the adoption I need to look at a migration roadmap for these applications and answer questions like:

• What's the impact on our existing application portfolio?
• Do we need to retest the applications?
• What will the tool support look like?  Third Party Vendors?
• What are the run-time deployment considerations?
• What are the training requirements?

I also need to try and motivate(sell) the adoption against business measures like Reduced SDLC time, Increased agility, Client centricity and Operational efficiency.  This is proving to be quite a challenge!  I want to share my findings thus far and try and elicit some further feedback on how other people are approaching the topic.  Please tell me I'm not the only one having to do something like this

.NET 3.5 and VS 2008 in context

Before going further, I think it is important to quickly recap and position .NET 3.5 and VS 2008 within the context of the existing .NET versions and VS tool set.  I found the "Green Bits" and "Red Bits" slide from Daniel Moth's .NET Framework 3.5 post to paint a clear picture of how .NET 3.5 builds and extends upon .NET 2.0 and 3.0. 

Daniel goes on to explain that:

When we say red bits, those are Framework bits that exist in RTM today i.e. NetFx v2.0 and NetFx v3.0.

NetFx v3.5 includes updates for those two existing frameworks. However, those updates are not a whole bunch of new features or changes, but in reality a service pack with predominantly bug fixes and perf improvements. So to revisit the terminology: Fx 3.5 includes v2.0 SP1 and v3.0 SP1. Like with all service packs, there should be nothing in there that could break your application. Having said that, if a bug is fixed in the SP and your code was taking advantage of that bug, then your code will break of course. To be absolutely clear, this is an in-place upgrade to v2 and v3, not a side-by-side story at the framework/clr level...

When we say green bits, we mean brand new assemblies with brand new types in them. These are simply adding to the .NET Framework (not changing or removing) just like Fx 3.0 was simply adding to v2.0 without changing existing assemblies and without changing the CLR engine. 

Scott Hanselman recently created a HTML page that shows the actual Red Bits API changes that have been made to the CLR.  In terms of Visual Studio, Daniel has another great slide in his Visual Studio 2008 stack post.

Because of the nice multi-targeting support provide by VS 2008, you can use the same IDE to develop against .NET 2.0, 3.0 and 3.5.  There is therefore no reason to have both VS 2005 and VS 2008 installed on the same machine.

Migration Roadmap

Looking at our application portfolio list, we have a portfolio of applications that can be classified within the following technology categories:

1. .NET 2.0
2. .NET 1.1
3. .NET 1.1/COM Hybrids
4. COM (VB6, ASP)

.NET 2.0

The easiest migration path as these applications should migrate seamlessly to .NET 3.5 and VS 2008.  You just open the projects in VS 2008 and decide whether you still want to target .NET 2.0 or make use of the new .NET 3.0 and 3.5 features. 

.NET 1.1

The .NET 1.1 and .NET 1.1/COM Hybrid applications also shouldn't prove to be too difficult as .NET 2.0 is mostly backwards compatible with .NET 1.1 (see this list for breaking changes between .NET 1.1 and .NET 2.0).  There are some tricks involved with migrating ASP.NET 1.1 projects, but it seems like you should be able to follow a similar migration path using VS 2008.  As your application will now be running off a different version of the CLR, .NET 2.0, I think some extra testing should be conducted to verify that everything still works fine.

COM

As for the last category of applications ... (big sigh) - I wish there was a magic button to get rid of these!  Furthermore, the extended support for the VB6 development tooling is coming to an end April 2008.  Fortunately the VB6 runtime will still be supported for quite some time as highlighted here:

The Visual Basic team is committed to “It Just Works” compatibility for Visual Basic 6.0 applications on Windows® Vista™. The Visual Basic team’s goal is that Visual Basic 6.0 applications that run on Windows XP will also run on Windows Vista. The Visual Basic team is also committed to the Visual Basic 6.0 development environment running on Windows Vista. As detailed in this document, the Visual Basic 6.0 runtime will be supported for the full lifetime of Windows Vista, which is five years of mainstream support followed by five years of extended support (http://support.microsoft.com/gp/lifepolicy).

Ideally we want to get rid of all the COM functionality.  As the runtime will still be supported for quite some time, I'd argue that there is little incentive for upgrading applications that aren't being maintained.  However, for the VB6 applications under development, what should your migration strategy be?  If we assume a port (I'll leave the topic of whether to port or re-write for another day), I would reason to port these applications directly to .NET 2.0 and VS 2008 and skip .NET 1.1.

Besides the Upgrade Wizard that ships as part of Visual Studio .NET, Microsoft has also released the Interop Forms Toolkit that allows you to host .NET forms and controls within a VB6 application. This allows you to upgrade your application in a more phased approach. 

One aspect to not forget about is the availability of Third Party Vendor updates that will run off .NET 2.0 and later.  This is especially troublesome for COM libraries and controls that have long been abandoned by the companies who developed them.

Motivating against Business Measurements

As mentioned, I need to motivate the adoption against certain business measurements like Reduced SDLC time, Increased agility, Client centricity and Operational efficiency.  To make it more tangible, I translated these business measures as having the ability to write good quality software, that addresses the business problems at hand, quickly and effectively.

VS 2008 Improvements

VS 2008 includes numerous IDE improvements that in my mind will support these business drivers:

1. Multi-targeting support
2. Web Designer, Editing and CSS Support
3. Code Editing Improvements
4. Javascript Debugging and Intellisense
5. ASP.NET AJAX Support
6. Multi-threaded Debugging improvements
7. Performance Improvements to the VS IDE
8. Code Analysis Improvements and enhancements
9. New VS 2008 Code Metrics
10. Windows Presentation Foundation Designer
11. VS 2008 System Profiler Improvements and enhancements

.NET Framework Improvements

Numerous additions have been made to the CLR that in my mind also supports our company's business drivers and the architectural drive towards a Service Oriented Architecture.

1. Base Class Library Improvements
2. LINQ 
3. Windows Communication Foundation as a unified communication stack for building and running connected systems.
4. Windows Workflow Foundation for building workflow enabled applications.

C# Language Improvements

Lastly I feel that the C# Language Improvements like automatic properties, object initializers, collection initializers, anonymous types, lambda expressions and extension methods can make developers more productive in creating solutions to the business problems at hand.

Conclusion

I'm wondering, what other techniques are you using to drive out your adoption?  Have you found any other valuable resources to assist you in your efforts?  What lessons have you learned from trying to do something similar?  What have I left out of reckoning? Looking forward to your feedback!