Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×

A .Net 2.0 Migration Strategy? 164

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?"
This discussion has been archived. No new comments can be posted.

A .Net 2.0 Migration Strategy?

Comments Filter:
  • Test test test (Score:4, Insightful)

    by Xtravar ( 725372 ) on Thursday February 23, 2006 @09:25PM (#14789591) Homepage Journal
    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.
    • Excellent plan.

      I would add holding off until more bleeding edge types
      have figured out where the really sharp edges are.
    • >>- a lot of functionality is different, and it's not even documented. It may compile, and it may run, but not for long.

      Specifics? we made the switch and found that the only real problems were some VS nonsense*, but overall, nothing broke completely, just a bunch of warnings about depreciated stuff. As far as failing down the road... you found it would compile and run for a while then stop? What did that? Because we just haven't seen anything like that.

      *The changes to web projects and VB.NET projec
  • It shouldn't be bad (Score:1, Interesting)

    by Anonymous Coward
    I recently migrated a 250k LOC web app with no code changes, and a few dozen smaller tools as well. Had to change two lines of code in one of those tools.

    The hardest part will be dependencies. If you have anything that won't (or can't) migrate to 2.0 then things get tougher. One of our tools was external, and it loads in external DLLs. It can't load a 2.0 DLL, so our DLL couldn't upgrade to 2.0, but our DLL consumed a shared DLL... that got messy. We worked around it (for the moment) by switching it to
  • by Anonymous Coward
    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.
    • The time and resources spent converting to Java

      You can use these tools [google.ca] to help you convert.
    • Indeed sometimes one gets the feeling that Sun, in the name of backwards compatability, is too conservative. People scream for new features. But in the long run, when you have large projects in a very large organization (with 1000's of developers) you can be glad that Java does not develop like C# does.

      Yes, Java made some design mistakes in the beginning, and even today we're still stuck with them. However, MSFT also was able to copy Java and introduce new design errors in .NET even though they had years of
    • Nice troll, but is completely useless in regards to the problem presented. The issue isn't which platform to use, the issue is the ease of migrating. I don't think that switching from .NET 1.1 to Java would be far more time consuming, and a bigger waste of resources, than going to .NET 2.0.
  • Get a couple of crackshot dev to compile your apps.
    Test the apps in a test bed envoirnment.
    Your 90% of your stragegies will come out off the problems you encounter in your test-bed.

    Second don't try to do too many things at once. For example, it would be tempting to move to 64-bit with 2.0

    MSDN and TechEd videos are good resources for code migation issues. Some resources you can checkout are
    Migrating ASP.Net [microsoft.com]
    Microsoft .NET Pet Shop 4 [microsoft.com]
  • I'd like some info on a .net migration from VB 6.0.

    Some background on this. Our VB 6.0 is not object oriented at all, and it was originally VB 3.0 that was ported to VB 6.0. The forms have code in them.

    I'd like to know if migrating from VB 3.0/6.0 to .net would be a total rewrite or what. I have analyzed some of the code and I know the biggest issue I see is the Variant types, but not sure what else, and if it is possible. This is a really large project.

    On another note, if anyone knows of a way to mi

    • It's pretty much a total rewrite. The old VB code isn't really object-oriented, and the new code will (should!) be. The new environment and development tools are vastly superior to VB 6, though. Totally worth the effort if your developers are reasonably good OO designers. If they're not, then VB6 is a good place to stay until they are.
    • Well, as far as using variant types, you can still use Object, and that will get you about the same functionality as the variant. A lot depends on whether or not this is a web application. If it's not you're lucky, because a lot of your code will probably be able to function. If it's a Web app, then you got lots of problems, because of the whole code-behind page fiasco. Also, you can use a lot of old VB code in the New VB.Net, to ease the transition, but plan on getting rid of it. You can still used re
      • Thanks, I didn't write the code. I'm stuck with it. Many of these coders don't know what the hell they are doing when they write code, so they wrote lots of bad code.

        Alot of the code uses Me which I heard is a nono in .net also. I ran a code checker and it found lots of problems.

        I guess we need to pull it into .net and see what blows.

  • Migration (Score:5, Informative)

    by panic911 ( 224370 ) * on Thursday February 23, 2006 @09:42PM (#14789662) Homepage
    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 [microsoft.com]

    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.
  • necessary trolling (Score:2, Insightful)

    by mrsbrisby ( 60242 )
    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
    • Not as familiar with C, but as for C++, they take great efforts to be careful about language and library changes breaking compatibility, check out Stroustrup's [artima.com] thoughts on the latest version of C++.

      You're marked a troll, but the advice is on the mark IMO. Ironically, Microsoft's code (I'm not talking about their .NET, but for example their Win32 API) is rather backwards compatible. And always take the trouble to steer clear of Microsoft-specific extensions where possible (i.e. managed C++ != C++). You ca

      • Not as familiar with C, but as for C++, they take great efforts to be careful about language and library changes breaking compatibility,

        Really? This program used to compile in G++:

        #include <iostream>
        int main(int argc, char *argv[]) { cout << "Hello World" << endl; }


        And yet, now it doesn't. Why? Namespaces.

        You can take 10 year old code, run it through Visual C++, and it runs on Windows XP.

        Actually, this is something to attribute to Microsoft. By breaking the C++ standard in so many places f
    • There are tons of people like you who still run on Windows NT and stuff still works. My VB app written in 1995 is still used in some organizations.

      No one is saying here that the poster's application is no longer working.
      The poster might have other consideration like to take moving to 64-bit.
    • I'm going to have to disagree with you on this. Not because I necessarily disagree with what you wrote, but because you missed the point of a .Net upgrade. .Net is not a language. It's a framework. As much as I hate frameworks (and hate them with a passion), saying "I have C code I haven't changed in 10 years" is completely beside the point. The class libraries have changed in the next version.

      So this question is more analogous to "I'm moving from Gtk 1.2 to Gtk 2.0. What's likely to break?". Try doin
      • So this question is more analogous to "I'm moving from Gtk 1.2 to Gtk 2.0. What's likely to break?".

        It's not similar to that at all.

        Try doing that without any code changes. Your fancy, schmancy C language doesn't help you at all.

        That's not the point. He's been writing this code for two years, and maybe they're just getting to the point where they can do something with it and BAMMO they need to start thinking about where they're going next.

        If you're looking for a good analogy it's something like this:

        Vendor
    • by iguana ( 8083 ) *
      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.
      • 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.

        You do of course realize that those bugs were already there.

        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.

        I think that's a little different.

        You at least know you're porting to a new kernel w
    • 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 data
      • 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 co
    • Yeah, every app should be done in C. Why bothering with C++, C#, Java, Python, Perl, PHP, ML, Haskell, Erlang, Lisp etc? what can be done in those languages can easily be done in C anyway...

      [/sarcasm]
      • The only thing that would be good about having only 1 programming language is that it would get us past the HR bots so much more easily. No more of this 5 years Java, 5 Years C++, 5 Years VB.Net. You could just say i've been a programmer for 5 years, and that would be enough. If you only have 3 years of Java, and they want 5 years, sometimes you don't get in, even though you have 10 years of solid development experience behind you.
      • Yeah, every app should be done in C. Why bothering with C++, C#, Java, Python, Perl, PHP, ML, Haskell, Erlang, Lisp etc? what can be done in those languages can easily be done in C anyway...

        Mostly right. Of the languages you listed, there are some gems:

        * perl4 code stills runs in perl5 interpreters. Perl6 promises to run perl5 and perl4 code.

        * Lisp too has remained unchanged [incompatibly] for decades.

        * Erlang was deliberately designed for language-feature durability

        Of course, C++, C#, Java, Python, and PHP
  • by Shag ( 3737 ) on Thursday February 23, 2006 @09:48PM (#14789686) Journal
    an IT department of over 300 people and 2 years of development


    Wait... and you're saying they got something done? That's not how it's supposed to happen!


    (cynic)

  • 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 [blognet.info].

    I hope it helps someone...

    Donnie
  • by $exyNerdie ( 683214 ) on Thursday February 23, 2006 @10:02PM (#14789731) Homepage Journal
    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...
    • You paid $2000 for VS.NET? What the hell is wrong with you?

      Enough fanboy crap. Java is good, and so is .NET. You can continue to run your 1.1 apps in the 1.1 framework, ON THE SAME SERVER AS your 2.0 web apps. Any 1.1 desktop apps will also run side-by-side with 2.0 apps.

      Switching to the newer framework without a need for its new features is the result of too much magazine-reading by the PHBs.
      • 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 on

        • Will MS patches and updates applied to MS systems ?
          Shoud be ... Will MS patches and updates applied to MS systems break older .NETs?

          Repeat to myself ... preview is my friend.
        • Which .NET?

          One would assume the one from Microsoft, since .NET is their name (pieces of .NET, like the C# language and the Common Language Runtime, have been standardized by ECMA).

          Will all .NETs run on Vista?

          If you mean, "Will the Mono and Rotor implementations of the ECMA-standardized bits run on Vista?" I'd assume so. And if not, they're open source so go make them work (yes, even Microsoft's Rotor is open source). Now if the question is whether .NET 1.0 or 1.1 will run on Vista, I have no idea

          • QUESTION: Which .NET?
            ANSWER: Microsoft's

            QUESTION: Will all .NETs run on Vista?
            ANSWER: Probably not, depending on the version of the Microsoft .NET you want to run, even though the answer to the first question implies there's no .NETs to choose from.

            QUESTION: Will .NET run on linux, or will MS decide to litigate MONO and others out of existence?
            ANSWER: Only if Microsoft wants to, but don't worry because you can trust Microsoft.

            QUESTION: Will MS change license terms again, making it illegal to
    • When I paid over $2000 to get Visual Studio 2002, little did I know that it only supported .net Framework 1.0.

      I paid over $10,000 to get Visual Studio 2002.

      I guess Microsoft thinks I'm five times better than you.
    • by popeyethesailor ( 325796 ) on Thursday February 23, 2006 @11:34PM (#14790143)
      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.

      • Another retarded slashdot comment/moderation. Newsflash for you:
        YOU DONT NEED THE IDE FOR .NET DEVELOPMENT!


        Hello!! You can do all your programming in Notepad or any text editor...Would you do that?? How can they sell those IDE's for outrageous prices?? Why would anyone pay for them? You think they are all dummies?
         
        • Hello!! You can do all your programming in Notepad or any text editor...Would you do that??

          No, you pick one of the better editors he suggested. Why on Earth would you do it in Notepad and what's your point?
          • Hello!! You can do all your programming in Notepad or any text editor...Would you do that??

            No, you pick one of the better editors he suggested. Why on Earth would you do it in Notepad and what's your point?


            The point is that VS is the best editor for enterprise/team development. The others are not better, they are inferior in comparison...
      • His comments are still valid, I like a lot of developers got up to speed (through betas, ms seminars etc) with .net 1.0 at launch our app was fully compatible and then watched my app break in 1.1. We Released a patch and started directly on rewriting in other languages.

        Vendor Lock-in is real and painful. If you use Microsoft's .Net it can be excruciating. The IDE is irrelavant to this topic. His points were that he shells out cash for an ide that is useless in as little as 18 months.

        My apps have a litt

    • Would you like some cheese and crackers with that whine?

      You don't _have_ to migrate. No gun is put to your head. It's not like they are going to make all computers uninstall 1.0 for 2.0. It's backwards compatible. That means, program in 2002 and .NET X.0 will work. It just means you don't get the nice new shiny features. If you want those AND the IDE, then they deserve their money. They have earned it.

      Now, had you said "I want to program in WM5!" then you might have a partially valid argument. But you'r sti
    • It goes back longer than that. Microsoft actually sold us a very broken C++ codebase with VC++ 6.0, which actually drove many to Visual Basic (as it was easier to do the easiest and most usual tasks), thus forcing entire codeshops to ride the MS bandwagon...

      Actually Stroustrup must sue Microsoft for giving C++ a bad name...
    • Just keep buying and paying $$'s...

      Or just be satisfied with .NET 1.1. It's not like it's just a tiny bugged framework anyway. We stuck around with VC++ 6 for ages, skipping both VS.NET 2002 and most of 2003, and just now catches on. Unsurprisingly, we had no trouble sticking with VC++ 6 for all that time, and I have no doubts we'll stick with .NET 2.0 for quite long.
    • Why would you move? Generally speaking a 1.0 application with run on the 2.0 framework, and if it doesn't you can install the 1.0 framework on the machine, and it will run side by side with the 2.0 framework, with the programs select the correct framework, of course this behavior can be altered by the administrator of the machine.
  • I thought the whole point of the .NET versioning system/GAC was that all assemblies will run under the correct revision of .NET?
  • We're in a similar boat, and taking it very slowly. For existing systems that don't fit well with new .NET 2 setups (some ASP.NET apps), for now they are running as .NET 1 apps. Fortunately, it's easy to host multiple sites with different .NET versions. We are gradually planning to update these as they come due for replacement/refreshing.

    All new development is using .NET 2, with APIs using either the old .NET 1 assembly or being updated as necessary. We have a couple of critical APIs that have been branch

  • by ErikTheRed ( 162431 ) on Thursday February 23, 2006 @10:24PM (#14789816) Homepage
    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.
  • As others have said, MS has put you in the position of having to migrate your production apps possibly well before you've recovered your costs. You might do well to ponder that, and make sure you're not setting yourself up to do it all over again in a couple of years' time.

    On the other hand, if it's job security you're after, you can always blame it on MS while taking your pay cheque for redoing work with which you'll quickly become expert.

    The only sensible approach IMHO is to run a pilot migration of a si
    • You complain that MS is forcing you to recompile and retest the code, and you spank Microsoft for this atrocity. Then you go on to suggest that a good alternative is to rewrite the entire application in another platform. The effort to recompile and retest under 2.0 is trivial to accomplish and a very small risk compared to the monstrous undertaking of completely re-writing the entire application. If you didn't sound so level headed, I'd think your comments were motivated by something other than reason.
      • Don't worry, lots of people don't think I'm level headed...

        The reason I'm suggesting the OP looks outside the J2EE/.NET duopoly is that he's been burned once, and may be at the start of a cycle where he'll be burned again in a few years' time. "Fool me once, shame on you; fool me twice, shame on me".

        I suggested running a pilot migration to 2.0 so he can ascertain the true costs of jumping from 1.1 to 2.0. If, as others have said, it's not a trivial step, then he'll find out during this migration; if it is
  • Hilarious (Score:2, Interesting)

    by JanusFury ( 452699 )
    Half the comments so far are advising the guy to ditch .NET ASAP so that he doesn't have to upgrade again.

    He doesn't HAVE to upgrade at all! He's voluntarily decided to upgrade to a new version of an existing product. How is this a negative thing? It could definitely be a bad idea, but I don't see anyone saying that.

    It's bad enough that people don't even read linked articles, do people even read the text of the story before posting anymore?
    • He doesn't HAVE to upgrade at all! He's voluntarily decided to upgrade to a new version of an existing product.

      Not only that, but for all the bitching about terrible Ask Slashdot questions, all the answers are answering the question they wished he would have asked instead of the one he actually did ask. Totally unhelpful!

      • So, your answer is don't upgrade? That's not really very helpful.
        • Huh? I don't think I said that. I was pointing out an answer to the question, "how should I go about upgrading to 2.0" of "you should have used something else/switch to something else" is not answering the question that was asked.
    • As a .NET developer I'd like to thank the slashdot community for their constant bashing of .NET. I think the lack of respect and interest in .NET has really helped drive down the supply of decent .NET developers thus contractor rates have been increasing nicely (since business really doesn't give a crap what the most techies prefer, they have are creating a massive demand for this work -> big demand/low supply = big $). Bob
      • As a .NET developer I'd like to thank the slashdot community for their constant bashing of .NET. I think the lack of respect and interest in .NET has really helped drive down the supply of decent .NET developers thus contractor rates have been increasing nicely (since business really doesn't give a crap what the most techies prefer, they have are creating a massive demand for this work -> big demand/low supply = big $). Bob

        Haha, nice one Bob. While the open source jihadists whine about Microsoft, you're
  • We just ported our large server-based application from CLR 1.1 to 2.0.

    The key problem we encountered was performance. A few things performed dramatically more slowly in 2.0 than they did in 1.1. In particular, we had some VB.Net code that was doing some things with late binding that were about 100 times slower than they were in 1.1. We had to track that down using a profiler and rewrite that section to use normal binding instead of late binding.

    The second thing that was slower was some aspects of the XML
  • An On-topic reply. (Score:5, Informative)

    by popeyethesailor ( 325796 ) on Thursday February 23, 2006 @11:01PM (#14789982)
    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 [scottgu.com]. 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.

  • I work for a company in a similar situation.. with a project that has about 150k lines of c# code.

    If you have many (or any) ASP.NET applications, I suggest using the (NEW, in beta) ms-supported "Web Application" plug-in. This works the same way as VS.NET 2003, and will make NO changes to your existing code base - making the migration as simple as just resolving some naming conflicts with the new classes introduced in 2.0. This plug-in is here [scottgu.com]

    For us, we actually switched to using a complete code-base
  • 300 people and 2 years of development

    If you have 300 developers, talk to Microsoft. You're dropping a half million a year just for MSDN licenses. They can afford to have a product expert hold your hand for week.
    • This assumes they all have MSND licenses. It is entirely possible to purchase Visual Studio and not get that overpriced help menu. It does have its merits, but from what I have used, it doesn't justify the cost. A google or two brings up the answer in the same amount of time.
      • I'm not sure on current pricing, but in 2003 purchasing Visual Studio Enterprise Developer Edition was $1800. MSDN Universal (which basically means every piece of software MS releases) was $2100.

        To me, for $300, it makes sense. There's a lot more than a "help menu" as you call it. Unlimited newsgroup support with guaranteed response times, as well as phone support.
      • I wasn't talking about the MSDN "help menu." As far as I know, the MSDN help system is absolutely free, and most of my google searches bring it up first anyhow.

        I was talking about the MSDN developers subscription. It's basically a developer's license to every piece of software MS makes (including all server software and operating systems), plus access to most beta software, plus free upgrades for a year, plus "real-ish" support.

        Given the price difference between the two, anyone who purchases a full versio
  • We are in the process of making the change from .Net 1.1 to 2.0, mostly due to a decision to migrate to Visual Studio 2005 Team. Thus far, the only issues we've run into is backwards compatibility with WSE2.0. We had to migrate to Web Services Enhancements 3.0 due to issues with IIS. Aside from that, we haven't had many issues other than a few test tools (AppSight)not yet compatible with v2.0.
  • by humblecoder ( 472099 ) on Thursday February 23, 2006 @11:47PM (#14790201) Homepage
    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.
    • like generics (which I think was also added to Java at some point as well, so again there is a double standard here)

      The difference being that you can generally upgrade JVMs without breaking backwards compatability. People started re-writing parts of their Java apps because they *wanted* to. Those who didn't need new language features could still upgrade the JVM for performance enhancements etc without rewriting any code. From what it sounds like, though, the problem is more with the .Net frameworks tha

      • You can run .Net 1.0, 1.1, and 2.0 code side by side without breaking compatibility. Instead of dealing with the version hell associated with subtle changes in API behaviors or optimizations (see MFC*.dll), they fork everything when releasing a new version -- logic being you can't break anything if you don't change it.
        • >You can run .Net 1.0, 1.1, and 2.0 code side by side without breaking compatibility.

          Are you saying that having only version 2.0 of the framework installed, I can run apps developed for .Net 1.0, 1.1 and 2.0? Or does it require to have multiple versions of the framework?

          And what if I have a 1.0 or 1.1 application and want to take advantage of one new feature in 2.0 in one (and only one) of my classes? Why should I have to convert the entire application?

          You might call it bashing, but it is not. B

    • Yes, but the entire pre-.NET VB approach just begged to be thrown in the trash can. It was a pooch. It sucked. It was a badly designed bunch of GUI grap thrown on top of the original Microsoft DOS BASIC. It was great for a learning experience, but life is so much better with a 'real' VB.NET, rather than the suck-ass VBx's of the past.
  • Hi,

    We're about to start using VS2005, but we've been using VB.NET for the last 2 years.

    I was wondering. Is it also wise to convert the 1.1 code over to C# and THEN move it over to VS2005? Or is this tackling too many problems at the same time?

    Y
    • My advice would be to convert to 2.0 first. Then convert one project at a time to C# (if your solution(s) contain more than one project). The port to C# is relatively straight-forward. The schedule risk lies in converting to 2.0. Plus you may want to incorporate some of the new features (generics, partial classes, etc.) of 2.0 when you convert to c#.
  • Delphi produces .NET 2 apps through VCL, and virtually all platforms - including Linux - have a VCL compiler. Essentially, write once, compile per platform. IOW halfway between Java (slow and no recompiles necessary) and .NET (native code and locked into the OS). So the options are probably: no upgrade, get MS to help you upgrade, or use VCL. There is no doubt that MS is taking the mickey out of us, but frankly when pople pay 500k in licensing for products they can download free, they seem somehow exonera
    • What version of Delphi are you using? The latest version of Delphi, Delphi 2006 is .Net 1.1 only afaik (http://www.borland.com/resources/en/pdf/products/ delphi/bds2006_feature_matrix.pdf [borland.com])
      • Well this is the thing: all non-MS companies follow behind by a number of months because MS protects the sales of their development tools in this way. Frankly I think that VS is only just catching up to Delphi 7 in some ways - both as IDE (equi-space controls feature as an example) and in terms of things like intraweb's RAD web development, but who can go without .Net 2 webparts? There are similar features in other languages, when it comes to MS platform the best choice should be an MS IDE and an MS laguage
  • What I did (Score:1, Informative)

    by Anonymous Coward
    I have a web app (about 4.5Mb of raw source) which was ported from .Net 1.1 to .Net 2.0 and SQL 2000 to 2005 at the same time. Process I used:

    Note: I don't use Visual Studio. I develop with Textpad and editors as most porting problems are to do with Visual Studio.

    - Create SVN branch.
    - Move build scripts from Nant to MSbuild
    - Move web forms to new code behind model
    - Build and run unit tests. Fix any incompatibility warnings (mainly System.Configuration.ConfiguraionSettings has been moved to ConfigurationM
  • by ndykman ( 659315 ) on Friday February 24, 2006 @01:41PM (#14794501)
    One thing I haven't seen discussed here is taking a strategy on which parts to move. This isn't "do it all at once" kind of situation. .Net 1.1 is still there, works, and having .Net 2.0 doesn't break that.

    There's a couple of strategies here. Firstly, you can go for low-hanging fruit. Many of the changes in .Net 2.0 are in things that use ASP, ADO, and so on. So, if you have core frameworks that are based on the core libraries, they probably can be very quickly ported to the new language. The optimum case is a recompile, retest and it's done. So, you can pick the stuff you think will mostly easily move to .Net 2.0, and port that.

    The other approach is to take a risk-aggresive approach. Take the most critical pieces you have (say, like a framework or a library that a lot of apps and so on use) and port those. Concentrate on that effort, because until those ports are done, you most likely can't move forward anyway. Repeat this approach until are well on the .Net 2.0 road. For a really hard-core approach, pick both most critical and hardest to do first.

    Given your large code base, I think it is best to get the old code working first, as tempting as it may be to use all the latest features of .Net 2.0. For example, you really may want to use those spiffy Web Part APIs on your portal, but get your old stuff running first.

    But, the key here is to pick those libraries, applications, etc. and work in stages. I don't think a big-bang migration will work very well here.

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...