Managing .NET framework upgrades_问答_开发者_运维开发者技术经验分享

This is more of a "project management" question. I apologize if this is not the right site to post to, but I did not know where to post it.

Say that you have 1 million lines of .NET 2.0 code (C#, ASP.NET and VB.NET) in a product that is currently being sold and used by a large number of clients. Your company has been developing this product for the past 10 years and still actively adding features and fixes.

The question is how do you manage the upgrade of the .NET framework and the code to .NET 3.5 or even better 4.0? a complete rewrite is not an option since the company does not have enough resources to have some developers work on ".NET 4.0 version" while others work on the ".NET 2.0 version" which is generating money.

EDIT For example, we have an old and very limited workflow engine we developed back in the .NET 1.1 days. We would like to be able to "upgrade" the app and replace this engine with Windows Workflow. Developers want to take advantage of new technologies/features in .NET (Management wants to too, but does not have the resources to do so)

EDIT 2 Another example, the ASP.NET pages in the application are old and do not use master pages. They were developed back in the .NET 1.0/1.1 days. We "switched" the compilation to ".NET 2.0", but we are not capitalizaing on the 2.0 featu开发者_JAVA技巧res. Applying master pages to the pages would take about 3 months and the management does not have resources to do that (upgrades don't bring immediate money as opposed to develop a new feature and sell it.

Thank you,

Even with two edits, the question is still unclear to me. To resume, on one hand, you want to migrate an application to use new features like WF or ASP.NET masterpages; on the other hand, you say that there are no enough resources to migrate to new features. In other words, you are asking what can you do to do a certain task for which you don't have enough resources. The only way seems to be to obtain more resources to make the migration.

In all cases, the old codebase, targeting a specific version of .NET Framework, will work on newer versions of the framework without major changes. You still need to do a few changes, but it's quite different from having to rewrite the whole codebase. In the worse case, you would need to rewrite the large blocks of code which use depreciated classes (CAS (code access security: for example sandboxing) is a good example, since .NET Framework 3.5 code is completely depreciated in .NET Framework 4).

You can also keep some libraries targeting .NET Framework 2.0 while migrating other libraries: a given library can use libraries which are written for previous versions of the framework.

It means that, in circumstances where you don't have enough resources to migrate 1 million lines of code at a time, you can still migrate some parts of code, then others, etc.

After rereading your question one more time, I have a few more points to note:

The product is currently used by your customers. Are those customers ready to migrate to the latest version of .NET Framework? If a large company uses your product on a huge number of machines, and if they have currently .NET Framework 2.0 only (which happens too frequently, alas!), they would probably be angry if you tell them that their DBA need to spend months updating all their machines in order to use the next revision of your product.
WF or masterpages are funny to use. But you already have a product which works well, and which was tested, including in production environment. Do you want to use the new features to reduce future development costs, or do you want to use the new features to use the new features? If it's the last case, it may be better to stay with a high quality legacy code, instead of having an untested code which uses the newest features of .NET Framework, but fails in circumstances when the older but more mature code worked.

You simply set the project target framework to 4.0. The old 2.0 code will still work, but now you will have the additional 3.0, 3.5 and 4.0 features available. You can use those features in any new code and as time allows, you can refactor/rewrite some of the old code. At no point are you "forced" to use 4.0 features, unlike the upgrade from 1.0/1.1 to 2.0 which had breaking changes. If your software is relatively modular, with well-defined interfaces, then it should be relatively easy to rewrite each individual piece independent of the rest.

The key here is that versions 3.0+ are additions to 2.0, not replacements.

For what it's worth, .NET "version" upgrades are mostly backwards compatible. You might encounter some additional warnings for deprecated calls when compiling your existing codebase, but they will usually still work. However! If your code is sufficiently "unique" or "special" and by that I mean it would fit in better on www.thedailywtf.com then you might have some issues.

There really isn't a big deal in .NET upgrades, as opposed to say Java version upgrades which I've seen break things in new and mysterious ways.

In addition, it should be trivial to set up a test machine, and try it out, if you have that large of a customer base. Usually, you don't even have to recompile! Just take the old binaries and run them on the machine with the new frameworks installed.

I just did a test conversion of my application to 4.0. Outside of changing a few namespaces, updating the project files to use .NET 4.0-- there was (almost) no code to change.

Compared to the 1.1 to 2.0 conversion, the conversion from 2.0 to 4.0 was effortless.

Most of your effort will be in deciding what new features to use.

You need to make sure your client download the .NET 4.0 runtime, so they can run .NET 4.0 application. Just run a windows update should do.

Upgrading your app from .NET 2.0 to a higher version say 3.5 is easy. You need to switch the project's Target Framework to .NET 3.5, build it, and fix any errors if there's any.

I'm unsure exactly what your question is. The way you ask it, the answer is to simply target the build to the new framework dlls. Visual Studio has a dropdown menu for this.

edit #1:

I think I understand your question a bit better now - it seems like you're really asking 'What is the best practice for migrating an existing codebase to use new libraries?'.

.Net allows multi-targeting. If you want, for example, Workflow Foundation, you can add a project targeting .Net 4.0 and wrap the functionality you want, then call that from your existing projects. I don't think there is any sort of versioning imposed by default on private assemblies, which is what almost all retail software uses (If you were using the GAC, you might run into problems).

If you have been practicing interface-based programming, it's no great stretch to swap out your existing implementations for new ones that are simply wrappers to .net 4 functionality and the calling code literally cannot tell the difference.

It sounds as though you'd have few problems merely switching the framework targets of the entire solution, which gives you no versioning issues whatsoever. Do watch out for behaviour that has changed between framework versions - off the top of my head, XSLT is one of these - which could conceivably break code which somehow relies on squiffy behaviour.