A .Net 2.0 Migration Strategy?
An anonymous reader asks: "I work for a large organization where we use .Net 1.1 as our sole development language. We have many frameworks, applications and web sites that are developed in .Net 1.1, and these developments are by no means trivial since they are the result of an IT department of over 300 people and 2 years of development. It is my responsibility to develop a strategy to move to .Net 2.0, this includes the existing applications, new developments, integration, QA, live and development environments. Does any one have any experience in this (preferably at this scale) and can any one recommend any reading material that would help?"
At work we're currently in the midst of migrating our app to .net 2.0. As trivial as it should have been, a *lot* went wrong - a lot of functionality is different, and it's not even documented. It may compile, and it may run, but not for long.
.net 2.0 and enhancing the product.
All I can say is... 1. get it compiling, 2. get it (apparently) working with some shallow QAing, and 3. pass it off to QAers, because they know what to test better than you do. Only after should you even consider utilizing features of
Buckle your ROFL belt, we're in for some LOLs.
Seriously. If you were a Java shop, you wouldn't have to worry about crap like this.
Microsoft has suckered your company into embracing a system designed to go obsolete so that they can sell you a replacement every few years. The time and resources spent converting to Java (and come on, C# and Java are very similar) would be saved in the long run by never having to deal with these silly MS upgrades ever again.
I hate to say it, but you get what you deserve!
I have C code both in production and development that's over 10 years old at this point, and at no point do we have to find a "upgrade strategy" as the foundations set up by K&R were good 30 years ago, and they're still good now.
Meanwhile, you're looking at how to deprecate a big chunk of your company's development value after only two years- and although you haven't said it, I wonder if you've even gotten your value back from all that work?
I'd say to find out how you can make sure you won't do this again in another two years. Start migrating to something else- anything else.
That's what you get for using Microsoft app platform. By the time you will move everything to .Net framework 2.0, they will have 3.0 released and you will have to go through this all over again. When I paid over $2000 to get Visual Studio 2002, little did I know that it only supported .net Framework 1.0. When v1.1 came out, Microsoft said you have to buy Visual Studio 2003. Now that v2.0 is out, Miscosoft says you have to buy Visual Studio 2005. Your VS2002 or 2003 won't take .net framework 2.0 and they don't give you a tool/patch to make it work. Just keep buying and paying $$'s...
One of the major potential benefits of using class frameworks and object-oriented programming is to free code from heavy dependencies on underlying infrastructure through abstraction. And yes, I know it's not mandatory or anything, but the potential is staring you in the face and so it's silly not to take advantage of it. With .NET (and MFC, etc before it), Microsoft can't do too good of a job of this because to do so would take you off the Windows / Office / Servers / Visual Studio upgrade treadmill, from which they derive their income. There are plenty of libraries and frameworks out there that will allow you to build for Win9x (still!), NT/XP/Vista/2Kx/.net, OSX, Linux, etc. that offer exceptional stability between versions.
Yes, Microsoft has some decent tools out there (Visual Studio has come a long way since the first version), but their behavior here has been consistent for the two decades or so that Windows has been out - you will wind up doing some significant porting and testing between versions of their tools, because compatibility between versions is not a priority for them. Selling you upgrades it the priority. Adding value is not a priority - they'll give just enough additional value between versions to make enough people jump, thereby forcing even more people to jump to maintain compatibility with the first set. It's an endless treadmill. If you (or your company) chooses to spend the immense amount of time and money to run on this treadmill, that's perfectly fine with me. I'll just sit over here accomplishing far more per dollar of CapEx and per man-hour.
Help save the critically endangered Blue Iguana
"Which is why Java project starts in Fortune 500 companies are on their way down while .NET project starts in that group are on their way up, eh?"
.NET.
.NET fanboy.
In terms of enterprise applications, it's hard to go up when you're being used almost everywhere like Java, however, it's not hard to go up if you're being used almost nowhere like
P.S. Just because you work in a mixed shop doesn't mean that you're not a
I see a lot of people saying things along the lines of "thats what you get for sticking with Microsoft". I think this is a somewhat unfair statement.
.Net 2.0 makes 1.1 obsolete. I know that programmers are attracted to all the "new and shiny stuff" like lemmings to a cliff, but if logically speaking, unless there is a true BUSINESS REASON for porting an application, why not just leave it where it is. It is not like Microsoft is suddenly going to pull the plug on 1.1. It'll still work just fine and dandy. In fact, you can run a 2.0 and a 1.1 application pretty much side-by-side, so there really isn't any issues here.
First off, it's not like
Second, it's not like Microsoft is the only one coming out with new revisions every few years. This is pretty much the same strategy employed by most software makers, including the open source folks. Some people have brought up Java as this great and wonderful language. I am not a Java expert but I know that Java has gone through several iterations and during that time, many of their libraries and frameworks have changed. Functions have been deprecated. Libraries and their API's have been rewritten. New features have been added. I am not saying that this is a bad thing, but it is strange that people throw Microsoft under the bus, while giving Sun a pass.
I think the migration path from 1.1 to 2.0 is fairly simple from what I understand. There are various tools and wizards to convert over some of the changed libraries. For the most part, though, the core language hasn't changed. It is only the associated libraries. I say for the most part since there have been certain enhancements to the language, like generics (which I think was also added to Java at some point as well, so again there is a double standard here).
I think if one were going to debate that Microsoft has too much software churn, a better example would be the change from VB6 to VB.Net. In that case, there was a much bigger change which very little migration path, other than interoperability and re-writing code. From my point of view, VB6 was totally toss into the trash can there. In contrast, the path from 1.1 to 2.0 really isn't that big of a deal. Microsoft took a lot of flak for the VB6-to-VB.Net debacle, so maybe they learned their lesson.
------
www.moneybythenumbers.com
Just a curious question, where do you get your opinion/facts/observation from?
( ) because you actually ported a larger app (say 200kloc or so) from 1.x to 2.0,
( ) from comparison of superficial announcements and specs?
No offense intended, but portability on paper is way different than in practice.