News Stay informed about the latest enterprise technology news and product updates.

On managing a .NET Framework 1.x migration

There are many compelling reasons to migrate projects from .NET 1.0 and 1.1 to a later version of the .NET Framework. A recent Burton Group report offers advice for developers considering such migrations.

Managed code environments like the .NET Framework bring important capabilities to application development such as policy enforcement and separation of the different aspects of business software development.

In a recent report on the subject, "The Microsoft .NET Framework 2.0: Managed Code on the Windows Platform," Lyn Robison, an analyst with the Burton Group, dove into some of the benefits of the evolving .NET Framework and offered advice for companies looking to make the move from older versions of the framework.

In an exclusive interview, meanwhile, Robison noted that moving to .NET 2.0 and 3.0 offers numerous benefits, largely more capable, secure, and easier-to-develop applications. But, like all transitions, a move to a newer version of .NET requires some planning and cost considerations.

In deciding how to migrate, three main considerations must be made -- the business value of the applications in question, what will happen to the app's code base and the learning curve that application developers will face.

Evaluating applications for business value

Robison said it makes the most sense for a company to invest substantially in moving to better tools that help it differentiate itself from the competition. In other areas that don't provide as much competitive advantage, it makes more sense to use commercial off-the-shelf software products instead, as those don't consume as many development resources.

Organizations need to adopt a portfolio approach to their application software, Robison said. Such an approach takes a strategic view that treats applications as assets that add value.

More on leaving behind the .NET Framework 1.x
Book excerpt: Upgrading to Visual Studio 2005

Applications are best evaluated along two axes, he continued. One is the value to the business and how well it supports or enables the organization to achieve goals. The other is how well the application fits into the technical architecture.

Some applications provide excellent business value but don't fit well into the technical architecture. These applications tend to suffer from poor performance or laborious maintenance, but, because of the business value, they ought to be upgraded.

Other applications can be good from an IT perspective but don't fit the business process. In these instances, Robison said, the developers need to evaluate whether there is some way to add more value or training to make the application more compatible with business goals.

In either case, Robison noted, once decisions are made to standardize the development environment and user machines, the organization gets a uniformity that becomes easier to maintain and manage.

Messin' with the code

As a development team is evaluating the business value of its applications, it must also make a deliberate decision about moving from .NET 1.x to 2.0.

It is possible to have .NET 1.1 and 2.0 run side by side on a client. While this does mean an additional .NET runtime is loaded into memory, the.NET runtime is not a huge memory hog for typical modern PCs, Robison noted.

At the same time, he added, it makes more sense to standardize this kind of transition, as opposed to moving from .NET 1.1 to .NET 2.0 on a project-by-project basis. There are breaking changes in .NET 2.0 that can become an issue in terms of maintaining multiple sets of code bases and client-side components that need to be addressed. For example, if the application is developed with .NET 2.0 code, all clients need to be upgraded with the .NET 2.0 components in order to execute the program, unless the developers have delivered a specification that the code will only be able to run with .NET 1.1.

From a development perspective, .NET 2.0 and Visual Studio 2005 offer significant improvements over their older counterparts -- namely, new APIs, new Web and Data Controls, new themes, new skins and a new version of the CLR (Common Language Runtime).

Moreover, moving to the .NET Framework 3.0 adds further capabilities to application development:

  • Windows Presentation Foundation provides rich capability for rendering objects and user interfaces in client applications.
  • Windows CardSpace, which is useful in developing single sign-on applications, ensures that users don't have to continually type in ID and passwords.
  • Windows Workflow Foundation provides a tool chest for developing workflow into applications.
  • Windows Communication Foundation offers a way to exchange data among applications structured as a service-oriented architecture.
  • As a whole, the .NET Framework 3.0 also better exposes the capabilities for providing better cohesion between desktops and data centers.

In addition, the upcoming .NET Framework 3.5, which will ship with Visual Studio 2008, adds capabilities like LINQ and, in the months following the release, a new ADO.NET Entity Framework.

The Language Integrated Query allows developers to use logical data models, making it easier to connect with database information models. LINQ helps reduce the impedance mismatch between object-oriented programming and object-relational mapping by building into OOP languages the natural ability to query and to update a relational database. It is very valuable in terms of programmer productivity and in terms of reducing the amount of source code that needs to be written, Robison said.

The hedonistic calculus of a .NET Framework upgrade

As is to be expected, Robison indicated that there are some definitive costs associated with moving to .NET 3.0.

For example, .NET 3.0 does not support some of the older operating systems such as OS/2 or Windows 2000; .NET 2.0 supports operating systems all the way back to Windows 95.

There are certain developer prerequisites in moving to .NET 3.0, such as understanding OOP, XML, and XAML, the Extensible Application Markup Language that plays a prominent part of WPF and Silverlight development. (One bit of good news -- Robison sees no need to worry about deciding between Visual Basic vs. C#, since, in his mind, Visual Studio has no preference one way or the other.)

Getting acquainted with .NET 3.x typically takes months, not weeks, Robison noted. The first few projects will tend to take more time than they ordinarily would. However, as skills are mastered, a developer is likely to have some significant productivity enhancements and can then move on to larger projects.

One advantage, down the line, is upcoming support for the dynamic languages IronPython and IronRuby. These tend to be less verbose and more forgiving in terms of syntax and object types, and they lend themselves well to developing small applications quickly.

With IronPython you can quickly switch between the standard library and those functions within.NET. The developer can write Python code that is pure Python or switch and call the .NET Framework.

IronRuby applications, on the other hand, are developed so calls to the standard library are translated into calls into the .NET framework; with Python the developer can make explicit calls into the .NET class library.

Dig Deeper on VB 6 to VB .NET Migration

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.