Posted
by
Cliff
on Thursday February 23, 2006 @09:20PM
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?"

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.

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

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

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.

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

Since Java is used for almost 100% of new projects (at least in Switzerland in large companies), it can hardly go up any further.Now Java/J2EE has replaced any other environment in the last years, obviously it is seen that in some cases there may be better solutions. Not each project is intended to last for 10 years, sometimes you just need some quick and dirty tool or prototype, for which a scripting language might be more appropriate. If it is a little tool with strong emphasis on GUI and office integrati

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.

You'll just instead have to deal with silly Sun upgrades when they break things every few releases. I've never seen a Java app that didn't say "use this particular version of the JVM or all hell will break loose".

Funny. Usually I've seen "Use this version of JAVA or NEWER or all hell will break loose."

Current Java is 1.5. All versions that are 1.X are backward compatible. JAVA 1.5 can run anything written for 1.x up until 1.5. If a program is later writter for Java 1.6, it probably won't run an a 1.5 JVM. I

If.NET is a framework, then Java definitely is a framework too. The only difference being that.NET has several different language syntaxes which use it's frameworks, whereas Java has only one (although there are bindings for other languages).

In fact, I'd argue that Java is a collection of frameworks - as is.NET

I think the point about java, is that when things like the Collections framework change, the old stuff is deprecated, meanin

Java was an experience in bad naming. The Java name was given to the framework, language, and security model. Really anybody could write a language to target the JVM, but Sun did not target that style as much as Microsoft did with.Net by targeting C++, C#, JavaScript(JScript), J#, and of course VB.

Funny. Usually I've seen "Use this version of JAVA or NEWER or all hell will break loose."

That probably the GP's point. You only ever see "use this version or newer", never "use this particular version". Sometimes, programmers have to rely on newer features introduced in a later version, but programs written for older versions won't fail, even on newer JVMs. That means that you might have to upgrade your JVM every once in a while, but you won't have to port any applications you have to the new JVM. They'

Azureus:
Note: Using an old Java version or having more than one installed may cause severe problems like 100% CPU usage!
The latest official Java is version 1.5 Update 6.
That sure sounds like telling you to use a specific version to me.

Really? To me, it seems that they're saying to use a specified version or later. They aren't saying to use 1.5-6, but just not to use one that isn't too old, such as 1.5-6.

The absolute prerequisite is a correctly installed Java 1.4.x or 1.5.x.
Yep, no dictating spec

Azureus:Note: Using an old Java version or having more than one installed may cause severe problems like 100% CPU usage!The latest official Java is version 1.5 Update 6.That sure sounds like telling you to use a specific version to me.

jasperreports:JRE 1.3 or higher

That's not sun updating something and breaking it, that's Azurues devs taking advantage of features in the newer java that don't exist in older java. When you try to use things that don't exist, strange things happen (like 100% CPU). You can inst

They admit their mistakes and *do* fix the framework and mark the old stuff as deprecated, so anyone that thinks you have to run frameworks side-by-side is smoking something.

I guess that leads to the questions "Why are both 1.1 and 2.0 in Windows update as installable options? Why doesn't the installation of 2.0 trump the installation of 1.1? (Why does it let me install both?) And why have I seen applications that require 1.1 installed, and not 2.0?" For example, BizTalk server 2004does not run with the.Ne [microsoft.com]

My problem is that.Net is a framework, while JAVA is a language. Grandparent just assumed the poster was using C#. With.Net they could be using J# (kinda java) or a number of other languages. I'm not endorsing anything, just saying it's kinda apples and oranges.

Not really. The comparison should not be between.Net and Java, but between.Net and the JVM. There are a vast number of different languages that run on the JVM - far more than for.NET. These include Groovy, BeanShell, python (Jython), ruby (JR

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.

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

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.

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.

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?

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

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.

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

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.

Bull. All of the work should go over smoothly. I ported several mid sized applications over, and they went just fine. you'll get some warning as you'll likely be using some depreciated classes, but you can continue to use them just fine.

We're using different definitions. Mid-sized projects take a few months. Large projects are the ones than span years.

The point behind this is that you cannot be using deprecated classes, because if you were, you'd still be targetting.NET 1.1

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

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.

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.

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

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.

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?

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.

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

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.

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

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.

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

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!

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.

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]

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

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.

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.

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

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

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

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.

Apparently, slashdot will also tell you to recompile,and that it all works. Funny, that.

And that does not match my experience so far. One webproject, was in 2003, another dev in my group openedthe project ( as part of our "when do we move" ) upin 2005, and had many problems. The conversion processdoubled up some of the namespace names( what was A.B became A.B.A.B ). Which was funny,because my experience in the past on conversion was thatthey mostly worked.