A few years ago, I interviewed with a large company for a senior development position. .NET 3.0 had just been introduced, and I was surprised by the number of interview questions that focused on it. When I asked why there was such an emphasis on .NET 3.0, the development manager beamed while telling me how they were currently busy updating all of their applications to use the new framework. Furthermore, he said they were in the planning stages for a total rewrite of their main desktop application to utilize the new code base. I asked why they felt the urgent need to upgrade when I had witnessed the application working fine. The response I got was their CIO was a Microsoft enthusiast and always wanted to be on the latest version.

I could not understand the need to replace an application that had no glaring problems — maybe there were issues to which I was not privy, but this was never mentioned. I could better understand if the application was horribly outdated and using ancient technology, but that was not the case.

I’ve never been an early adopter of technology; I normally wait for widespread acceptance and stability. My opinion is there has to be an important new feature or performance improvement to make the case for upgrading, since it is usually a major endeavor.

The complex upgrade process

The complexity of upgrading a code base to a new version of the .NET Framework depends upon the size and number of applications, but the core approach remains the same. First, you have to download and install the latest framework along with any patches. The development team should be familiar with what the new version offers, known issues, and so forth. Also, you need to make sure third-party libraries/products being used are compatible or determine if a compatible version is available.

Once the environment is set up, the application code is opened and recompiled with the new version. At this point, compilation issues may arise – deprecated features often appear at this point – so time must be devoted to clearing up these issues to ensure a good compilation. It’s tough to estimate since complete knowledge of the current code base is required, along with thorough knowledge of the new framework.

When the application is recompiled error free, it must be tested using the updated code. Larger organizations have development and test environments where time is allotted for the quality assurance (QA) team to properly test. A small organization may have a different approach, but the key is making sure everything works as planned before moving to production. The final step is rolling out to production where that environment must have the new framework installed and set up before the code is rolled out.

What .NET 4 has to offer

Industry conferences focus on the latest and greatest when, in fact, most developers are stuck working with older versions. While it is great to get a look at the future, many developers have issues and questions related to past versions.

Microsoft TechEd 2011 was no different, as it focused squarely on .NET 4 and how it can improve your life (well, as it pertains to your development activities). .NET versions 2.0, 3.0, and 3.5 were interrelated with .NET 2.0 as the common base, but .NET 4 is an entirely new upgrade. I recently used .NET 4.0 as a model for the upgrade decision.

The many new features in the release are beyond the scope of this article, but here is a brief overview of what .NET 4.0 has to offer:

  • In-Process Side-by-Side Execution: Applications can load and start multiple versions of .NET in the same process, so you can control the framework version used by the code.
  • Garbage Collection: The concurrent model is replaced by background processing.
  • Reduced client profile: The pared down version of .NET contains only features used by client applications.
  • jQuery: It is fully embraced and included in all Web applications by default.
  • Chart control: This ASP.NET control is now a standard piece of the framework.
  • Cleaner Web markup: Reduced HTML, jQuery adoption, and session-state compression offer Web application enhancements.
  • Web deployment: This task is now automated with many new features.
  • WPF 4 (Windows Presentation Foundation): You can create better interfaces with new features, including the ability to run in browser.
  • WWF (Windows Workflow Foundation): This is completely rewritten with full backwards compatibility support.
  • MVC 3: Framework for building standards-based Web applications.
  • Dynamic languages: Easier integration with dynamic languages like IronPython and IronRuby.

When looking at the feature list, think about what .NET 4.0 offers that warrants an upgrade. I could easily integrate jQuery in previous versions, and the chart control was available as an add-on in .NET 3.5, so the upgrade was not absolutely necessary in my case. On the other hand, if WPF 4, WWF, or MVC 3 is something you must have, then move ahead. (So far, my favorite features are the ability to target different frameworks, jQuery support, and the chart control, but this could change as I continue to get acclimated with .NET 4.0.)

Conclusion

Moving to a new version of a development language/environment, whether it is .NET, Java, or something else, is not a simple process because there are many factors to consider. This is why many large companies are slow to adopt new versions, as it requires a lot of time for planning, testing, and execution. Many businesses use the latest technology for new development, while maintaining existing applications built with older technology.

As a developer, working with the latest technology is exciting but is not always necessary depending on the company’s needs. Upgrades can be rocky endeavors that should be approached with caution.

How do you approach a new version of a development environment or tool? What factors do you consider when deciding on an upgrade? Share your thoughts and experiences with the community.

Note: The .NET Framework 4.5 Developer Preview is available for download.