Slashdot Mirror

← Back to Stories (view on slashdot.org)

A .Net 2.0 Migration Strategy?

Posted by ryuzaki0 on from the software-growing-pains dept.

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

4 of 164 comments (clear)

  1. Migration by panic911 · · Score: 5, Informative

    I do have experience migrating several smaller .net 1.1 apps to 2.0, but nothing even close to this scale. I will give you as much information from my experiences as possible, and hopefully it'll be of some use to you.

    The WinForms upgrade wizard worked pretty much flawlessly for each application I converted over, the trickiest part was setting up Source Control, and it was more of a problem with the source control solution we used (SourceGear). Good source control system once it's setup, but a real pain in the ass until then. There were 3 or 4 fairly large projects and a ton of small ones that all converted without a problem.

    Not sure if you're using the web stuff or not, but that was where I had the most problems. The Web upgrade wizard is far from perfect. You should at least install the latest version of it from: http://www.microsoft.com/downloads/details.aspx?Fa milyID=7cecd652-fc04-4ef8-a28a-25c5006677d8&Displa yLang=en

    That version has fixed several issues I had, but also seemed to introduce a few new ones (or it was a cascading problem, that resulted in different errors when the originals were fixed). I've had to do a lot of tweaking on many aspx pages to get it to find the Code Behind and there were a couple projects that I had to re-assign all my event bindings with, for some reason, although that was with the old version of the conversion wizard so that is probably fixed.

    If SQL is being involed in this upgrade procedure, that was a much harder process to get migrated. Tables, Views and Stored Procedures migrate fine and the Reporting Services reports migrated over.. ok (though VS2005).. but the HUGE hassle is analysis service, if you use that, don't expect it to migrate very easily. DTS stuff was pretty easy to migrate over.

    Anywhere, theres my memory dump. Hope that helps in some way.

  2. Article on this topic by soccerdad · · Score: 2, Informative

    Not to plug my own work, but I recently posted an article that touches some on this topic. You can find it here: http://www.blognet.info/weblogs/entry.php?u=adhale jr&e_id=1560.

    I hope it helps someone...

    Donnie

  3. An On-topic reply. by popeyethesailor · · Score: 4, Informative
    Well, its not that hard. What broke a lot of things for us was the new Website template introduced in the ASP.NET 2.0 betas. To put it short, they changed the entire deployment model, and this pissed off a number of people. MS did a u-turn, and launched this. This made the migration work flawlessly, and you also get all the benefits of ASP.NEt 2.0 without code changes :) Read Scott Guthrie's blog frequently; there's good stuff there.

    Side-by-side installation hasnt been a problem either. Both frameworks can co-exist, with a few tweaks here and there. The language (C#) has gotten a bit nicer. More shortcuts, faster development, and overall superb IDE support(VS.NET 2005). The deprecated features have been done for a reason, and overall the changes make sense. While the performance is a bit better, I dont know if its enough to make a business case. If I can, I would wait a bit more, till a Vista release; especially if I'm doing WinForms apps.

  4. Re:necessary trolling by slashdotnickname · · Score: 2, Informative

    I have C code both in production and development that's over 10 years old at this point

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

    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.

    Take graphics, for example... programmable shaders were practically unheard of 10 years ago, but they dramatically speed up some type of graphics applications. I've recently "dusted" some great opengl code I wrote in college. It still works, but I upgraded it to use some new 2.0 features and it's much faster now