Migrating from .NET 1.1 to .NET 3.5

Question

What would be some compelling reasons to upgrade a web app from .NET 1.1 to .NET 3.5?

Answer 1

Generics, lambdas, LINQ, many others that I forgot about I'm sure.

Answer 2

.net 1.1 is deprecated, not being further developed. i'm not sure about security issues. but in general, it's abandoned, and as of 2.0 microsoft ensures back-compatibility in newer versions which isn't the case to 1.1.

so if you have a chance to move - move. you get new language features, you get a framework being constantly built further and further. you get linq if you need it, silverlight support, generics of course, etc.

Answer 3

Don't forget about WCF, WF, WPF, CardSpace, etc.

Answer 4

The biggest difference is that you are moving to the .NET 2.0 CLR (This is the same CLr that the current .NET is running on).

This means you have an abundance of bugfixes, and CLR level Generics support. They rest of the changes are just changes to the foundation class libraries, and new languages features in the compilers.

Answer 5

I've actually recently finished converting an entire code-base from .NET 1.1 to .NET 2.0. Take into account that .NET 3.5 is actually just sets of extensions for .NET 2.0, it's not a completely new base.

The difference is really quite substantial in many parts. To me, .NET 1.1 had not been "tamed" in any way whatsoever, and required an awful amount of code. Furthermore, VS 7 had to be used against .NET 1.1, so older tools were required.

For web apps a different web config was required as it exposes the .NET version which made it even messier. Don't get into the ".NET 3.5 has new features therefore I must move to it" motion, because you have to make the decision based on requirements, not on potential tool uses. As many-an-author rightly points out, there's a good chance you won't use half of the features that compose the entire framework.

I would recommend, on the other hand, to shift from .NET 1.1 to .NET 2.0 at least.

Answer 6

There are a number of compelling reasons for upgrading to .NET 3.5. As others have pointed out, however, 3.5 is largely (if not wholly) nothing more than extensions to 2.0; however, 2.0 brings a large number of features to the table that make it well worth the move. That being said, in my mind, if you're going to make the move, it seems kind of silly to move to 2.0 and not just move to 3.5.

Extension methods alone are extraordinarily useful. I find myself using them far more frequently than I thought I would. Further, many of the newer features in 3.5 are based on them. Generics vastly simplify a great deal of our development; and, if you're coding in C#, automatic setters and getters are a boon. Lambda expressions are still relatively new for me, so I can't speak to them, but I understand that others find them particularly useful.

WPF presents a whole new way of writing applications, and I have used it. It shows great promise; unfortunately, it doesn't appear to be getting the wide adoption that I (personally) think it deserves yet. Hopefully, that'll change with time, but that will depend on whether or not Microsoft itself begins pushing it more aggressively.

As far as the Framework itself is concerned, I find that much functionality is improved or provided that was previously missing from 1.1; as it matures, the Framewok seems to be heading in a direction that requires us to write less code for those tasks that we commonly perform (such as directory services, FTP access, named pipes, and so on). The rough edges are getting smoother.

So, in short: moving to 3.5 would mean that your newer applications could be written with less code, and existing applications could be refactored to use less code (not that I'd recommend doing so solely for that purpose). 3.5 puts a wide array of productivity tools at your disposal; my personal opinion is that those tools alone make it well worth the leap forward.

But, like any business decision, you have to weigh all that against the state of your projects--and any potential defects that might arise when you port the codebase. My experience to date has been that we ran into a few snags, but not enough to bring the entire operation to a screeching halt. Nonetheless, with any migration, there is always the possibility that code will break; that has to be born in mind.

Answer 7

I think a really good reason is the provider frameworks set up in ASP.NET 2.0 and later. The ability to get whether a user is logged in or a list of roles that a user has without worrying about the underlying mechanism that's used to check those things is a big benefit.

Answer 8

Edit and continue? Also generics and nullable types makes life a little easier!