Slashdot Mirror


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?"

12 of 164 comments (clear)

  1. Test test test by Xtravar · · Score: 4, Insightful

    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.

    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 .net 2.0 and enhancing the product.

    --
    Buckle your ROFL belt, we're in for some LOLs.
  2. I know this is trollish, but switch to Java by Anonymous Coward · · Score: 1, Insightful

    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.

  3. necessary trolling by mrsbrisby · · Score: 2, Insightful

    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.

    1. Re:necessary trolling by iguana · · Score: 2, Insightful

      No matter the technology, porting to a new platform is a chunk of work. Even in C.

      I work in embedded systems. I don't care how "standard" C is--it's only the source code that's standard. When we move to a new processor or the compiler upgrades, we spend weeks chasing subtle bugs out of the code. Never mind complex stuff like trying to port our stuff to a new RTOS or trying to integrate thousands+ of lines of purchased source code into our product.

    2. Re:necessary trolling by mrsbrisby · · Score: 2, Insightful

      As I programmer myself, I realize you're talking about code that's pretty self-contained and algorithmic in nature.

      No, I'm not.

      Other coding projects, though, need to interface with hardware and other commercial software (like databases) all of which evolve over time... and if you want to take advantage of any new advancements they might provide then your code will have to evolve as well. Sometimes you don't even have a choice (a database company might drop support entirely for an old package) so updating code is part of the job.

      I have no difficulty interfacing with hardware or commercial software in C. I have no problem _writing database servers_ in C.

      And not to put to fine a point on it, but if your database company dropped support for something your business depended on, you made a horrible mistake in picking that database company.

      Yes, upgrading is wrong. If your vendor makes you upgrade, it's because THEY made a mistake by shipping buggy code, or YOU made a mistake by picking them. Whether the upgrade is better or worse than the previous version is for ME, the user, or the developer to decide, and not my vendor.

      In any event, you missed my point: C# and .NET is an immature moving target. A company or an individual that puts so much of themselves into such a beast gets what they deserve when Microsoft says "nononono, we didn't mean that, here's what we REALLY meant. just in time for people to start deploying" and deprecates all your hard work.

      I am not saying that there is never a place for C# or .NET or C++ or anything even remotely similar to that. I'm saying that if you have to build out a bunch of technologies that are supposed to last, and "ah" suprise- what's to stop Microsoft from doing this again in two years?

      Why not just avoid the whole mess?

  4. MS lifecycle and support by $exyNerdie · · Score: 4, Insightful

    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...

    1. Re:MS lifecycle and support by popeyethesailor · · Score: 4, Insightful
      Another retarded slashdot comment/moderation. Newsflash for you:

      YOU DONT NEED THE IDE FOR .NET DEVELOPMENT!

      The .NET Framework SDK has always contained all the compilers, build tools, and everything one needs to get started. And there's a complete free software stack of .NET development tools, including Nant, NProf, Ncover, Testdriven.NET, Nunit, SharpDevelop, CruiseControl.NET, Log4Net, Subversion and a dozen others I've missed. I've regularly seen people sticking with emacs and the above tools, for their entire development work.

      And guess what, if you need a nice,shiny IDE, MS is giving portions of the IDE too! The Express editions get most of the functionality, except for some enterprise features. The cost of development tools should negligible, in a large-scale organisation atleast. VS.NET 2005 is worth the money, IMHO. Its not a VB6 world anymore, guys. There're legitimate reasons to bash MS, but this is not one of them.

    2. Re:MS lifecycle and support by pallmall1 · · Score: 2, Insightful
      Java is good, and so is .NET.
      Which .NET? Will all .NETs run on Vista? Will .NET run on linux, or will MS decide to litigate MONO and others out of existence? Will MS change license terms again, making it illegal to run .NET on anything but MS licensed systems? Will MS patches and updates applied to MS systems ? Will newer .NETs be able to control previous MSOffice applications and functionality, or will they all have to be "upgraded" as well? ...and on and on.

      All of the above questions have one thing in common. All the answers come from Microsoft. All decisions are made by Microsoft, and not by the developer.
      --
      3 things about computers: they're alive, they're self-aware, and they hate your guts.
  5. Do people ever learn? by ErikTheRed · · Score: 3, Insightful

    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
  6. Re:Agree fully - Riiiight by Anonymous Coward · · Score: 1, Insightful

    "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?"

    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 .NET.

    P.S. Just because you work in a mixed shop doesn't mean that you're not a .NET fanboy.

  7. Response to the trolls by humblecoder · · Score: 3, Insightful

    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.

    First off, it's not like .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.

    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.

  8. Re:You *ARE* trolling by marcovje · · Score: 2, Insightful


    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.