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?"
Is there a reason to migrate to .Net 2.0? Or is this a decision that was just made "because"?
No experience with this yet, brave adventurer... let us know how you get along! Specifically, let us know if you make mistakes that get you fired.
At work we're currently in the midst of migrating our app to .net 2.0. As trivial as it should have been, a *lot* went wrong - a lot of functionality is different, and it's not even documented. It may compile, and it may run, but not for long.
.net 2.0 and enhancing the product.
All I can say is... 1. get it compiling, 2. get it (apparently) working with some shallow QAing, and 3. pass it off to QAers, because they know what to test better than you do. Only after should you even consider utilizing features of
Buckle your ROFL belt, we're in for some LOLs.
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 use a private version of the 1.1 shared DLL until we can get a 2.0 version from the external tool vendor.
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.
1.1 and 2.2 are almost the same and are compatible for most normal uses.. It shouldn't be too hard to move over.
Get a couple of crackshot dev to compile your apps.
.NET Pet Shop 4
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
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 migrate Vax Basic to C that would be great too.
Only 'flamers' flame!
Does slashdot hate my posts?
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.
a milyID=7cecd652-fc04-4ef8-a28a-25c5006677d8&Displa yLang=en
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?F
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.
Papers, please?
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 web
project, was in 2003, another dev in my group opened
the project ( as part of our "when do we move" ) up
in 2005, and had many problems. The conversion process
doubled 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 that
they mostly worked.
emt 377 emt 4
MS hasn't made 1.1 obsolete. Lots of people are still developing for it today. And moving to 2.0 is VERY easy. There are some new features, new components and such, but it's like 99.9% backwards compatible. just use the new stuff if you want to (generics, nullable types, whatever). And it's funny how you say they'll sell us a replacement, when the .net framework and the SDK (which is all you need to use .net apps and create them) is totally free, and that it even runs on mono or can be compiled to java bytecode. There's no plans to obsolete .NET anytime soon either. It's all FUD, lies and damn fucking lies from a clueless and frustrated java fanboy.
And it's not like java guys have no issues to overcome or problems ever... You're NOT sabing any time by going java. You're just using a slightly lesser platform and spending more time to get the job done.
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.
Wait... and you're saying they got something done? That's not how it's supposed to happen!
(cynic)
Village idiot in some extremely smart villages.
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
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...
I thought the whole point of the .NET versioning system/GAC was that all assemblies will run under the correct revision of .NET?
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 branched, with the .NET 1 version in maintenance mode and active development in the .NET 2 tree (bugfixes being backported as necessary).
For actually updating .NET 1.1 setups to 2.0, we are following Microsoft's advice: start by porting each component, and then port the application itself. It can be a little tedious, but most of the time it goes pretty quickly. It helps a LOT if you've been anal about keeping things loosely coupled in APIs, I think it could be a lot more painful with tons of closely intertwined libraries - but that's true of any setup.
Finally, fear the ASP.NET project conversion wizard. It does horrid things sometimes!
Lead developer, http://wisptools.net
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.
.NET even though they had years of experience to learn from (but alas they suffer from the not invented here syndrome), and they do not make a problem to make incompatible changes.
.NET.
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
Which is the reason that all larger enterprises use Java and don't even think of
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
This article, "Converting Our Application to ASP.NET 2.0", may be of some use:
e jr&e_id=1560
http://www.blognet.info/weblogs/entry.php?u=adhal
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.
.NET 2.0 (if you decide to go that way), but that other 10% might be a real pain to deal with. Get all the MS expertise you can afford for the pilot, because they'll act as conduits for exchanging info between yourselves and other MS customers who are going through the same thing.
.NET 2.0. Having worked for years in large enterprises, I know there's "enterprise apps" and "department/workgroup/... apps" - I'd be inclined to treat the latter as a separate category of deliverable, and look outside .NET and J2EE for your development. For smaller Web-based apps, tools like Ruby on Rails look particularly compelling - agility and speed of development are key, and the technology isn't going to "go away" as with .NET 1.1 because it's open source and you can use it as long as you want.
.NET or J2EE, particularly for smaller/less critical apps.
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 single app/server, and see what resources are required, what problems crop up and how you can remove them for other migrations that follow, and how long it actually takes. I'd expect 90%+ of your code to cleanly migrate to
Once you've done a pilot and gotten that data out of it, you can estimate what's required to migrate your other apps.
Personally, if I was in your spot, I'd take a close look at what your apps do and see if there isn't a better/more agile solution than just shifting to
If you're e.g. going with a SOA approach to your development, it shouldn't matter what toolsets you use; just use what gets the job done best. That's not always going to be
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 can take 10 year old code, run it through Visual C++, and it runs on Windows XP. But that's the way it should be. Customers don't want to muck with migrations every 1 or 2 years, they want some decent ROI.
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?
using namespace slashdot;
troll::post();
"Which is the reason that all larger enterprises use Java and don't even think of .NET."
.NET project starts in that group are on their way up, eh?
Which is why Java project starts in Fortune 500 companies are on their way down while
Go ahead and keep on wearing those blinders, fanboi!
(FWIW, I work in a mixed shop, so don't go calling me one.)
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 parser, in particular InferXMLSchema.
The key suggestion I make to you is to do performance testing. Put your application under load and baseline the performance under 1.1, then compare with the same load test under 2.0. Use a profiler to track down the differences if they are major. In our case, the performance difference was major enough that we needed to rewrite certain small parts of the code. Afterwards the performance between 1.1 and 2.0 was about the same.
But this is key: do the performance testing! The difference can be huge.
The upgrade is totally worth doing, though, especially if you're doing socket communications and leaking memory.
Just a ripoff? Okie. It's more like Java done right - a better language AND framework (yes, the APIs and all).
.NET definitely has the edge, no doubts about it. Most of the best java frameworks have already been ported (NHibernate, NAnt, etc - dozens of them), add a bunch of .Net only frameworks (the EL isn't bad at all), MUCH better dev tools (VS2005) including some wicked 3rd party tools like LLBLGEN Pro, VisualAssist X, Reshaper, dotTrace, Resharper, PromptSQL, etc. Same for 3rd party tools (dev express, dundas , infragistics, etc). Documentation and support wise, java is behind as well. MS has newsgroups, MSDN(!), XML feeds, starter kits, very useful MSDN blogs, forums, tons of communities (such as codeproject), gotdotnet, application architecture mag, etc. etc etc (this could be like 1200 pages long).
And only idiots like you pretend windows is horribly buggy as some early win95 beta on shitty hardware. Basically nothing you say has a basis in reality, but feel free to believe it.
As far as the frameworks and tools go,
Only incompetent idiots like you can't produce something that can't be used in a serious production environment in C#. You're only proving your ignorance.
Have fun relying on Sun's constant misguided failures for a platform. It failed at pretty much everything they tried (being popular on the desktop, on the web, making java the best platform, EVERYTHING they do ends up in a failure [except perhaps solaris]). And Java jobs are on the decline here (unsurprisingly).
"Which is why Java project starts in Fortune 500 companies are on their way down while .NET project starts in that group are on their way up, eh?"
.NET.
.NET fanboy.
In terms of enterprise applications, it's hard to go up when you're being used almost everywhere like Java, however, it's not hard to go up if you're being used almost nowhere like
P.S. Just because you work in a mixed shop doesn't mean that you're not a
I am not entirely sure why you would want to migrate your existing applications to .NET 2.0. They work fine side-by-side, just as you can multiple JVMs on the same machine. ASP.NET 1.1/2.0 applications are a joy to manage side-by-side on Windows 2003/IIS.
.NET 2.0 platform, I would guess you have some technology-fever. This just doesn't make "cents". Presuming you have healthy culture where good employees are compelled to stay, you've already made significant investments in their skills, the same skills they used to build your existing applications. You've made huge investments in developing and stabilizing these existing applications.
.NET 1.0/1.1 applications. In these cases it may be that migrating some application to .NET 2.0 will result in positive ROI. You can only answer this question yourself, and "we reeeely want to use VS2005" is not a factor in cost/benefit analysis. The real question is "can we get the new required functionality faster if we start (nearly) from scratch in .NET 2.0 than by enhancing with existing app"?
.NET from .NET 2.0, I recommend you start developing an SOA strategy. I know, it's just a buzzword, but the principle of interoperating with legacy code in a uniform manner (say, web services) is a solid one.
.NET 2.0. Good choice! This is an amazing platform for productivity and flexiblity. My suggestion is to send your developers to some top-notch trainers--DevelopMentor and Franklin's Net come to mind.
.NET 2.0 is about productivity. It makes some things that were ++un-easy in prior versions ++easy.
If you are considering migrating these apps so that every line of code you write from date X will target the
You may take issue with this, knowing that you have on-going initiatives that require extending your current
Now, if you want to reuse the business logic you've developed in previous versions of
Now, turning to the transition question, I presume you would like to do new development and initiatives in
Make no mistake,
P.S. To all you Java guys who like to presume you know everything because you... grrr, nevermind. Think of it like moving a web application from Struts to JSF. That's the kind of "migration" he's faced with here.
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.
but out of 300 people doing development with this environment for 2 years, how did it land on you to figure out how to migrate it?
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
For us, we actually switched to using a complete code-based web application (no aspx or ascx files at all), which has turned out to be the EASIEST transition - we can compile our code in both 2003 and 2005 with no problems (until we start taking advantage of the 2.0 features, of course).
The only real problem would be when switching to the new 'Web Site' ASP.NET model, which is just ridiculous as doing the conversion just messes up all of your existing code and it's pretty much guaranteed not to work without manually fixing it up.
Hope this helps!
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.
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.
If you think
I see a lot of people saying things along the lines of "thats what you get for sticking with Microsoft". I think this is a somewhat unfair statement.
.Net 2.0 makes 1.1 obsolete. I know that programmers are attracted to all the "new and shiny stuff" like lemmings to a cliff, but if logically speaking, unless there is a true BUSINESS REASON for porting an application, why not just leave it where it is. It is not like Microsoft is suddenly going to pull the plug on 1.1. It'll still work just fine and dandy. In fact, you can run a 2.0 and a 1.1 application pretty much side-by-side, so there really isn't any issues here.
First off, it's not like
Second, it's not like Microsoft is the only one coming out with new revisions every few years. This is pretty much the same strategy employed by most software makers, including the open source folks. Some people have brought up Java as this great and wonderful language. I am not a Java expert but I know that Java has gone through several iterations and during that time, many of their libraries and frameworks have changed. Functions have been deprecated. Libraries and their API's have been rewritten. New features have been added. I am not saying that this is a bad thing, but it is strange that people throw Microsoft under the bus, while giving Sun a pass.
I think the migration path from 1.1 to 2.0 is fairly simple from what I understand. There are various tools and wizards to convert over some of the changed libraries. For the most part, though, the core language hasn't changed. It is only the associated libraries. I say for the most part since there have been certain enhancements to the language, like generics (which I think was also added to Java at some point as well, so again there is a double standard here).
I think if one were going to debate that Microsoft has too much software churn, a better example would be the change from VB6 to VB.Net. In that case, there was a much bigger change which very little migration path, other than interoperability and re-writing code. From my point of view, VB6 was totally toss into the trash can there. In contrast, the path from 1.1 to 2.0 really isn't that big of a deal. Microsoft took a lot of flak for the VB6-to-VB.Net debacle, so maybe they learned their lesson.
------
www.moneybythenumbers.com
Repeat to myself
3 things about computers: they're alive, they're self-aware, and they hate your guts.
Keep one .NET developer to maintain the crap you've already written. Feed him well for 6 months and he'll stay. After that he'll quit anyway, which is perfect, since you won't need him anymore.
QUESTION: Which .NET?
.NETs run on Vista? .NET you want to run, even though the answer to the first question implies there's no .NETs to choose from.
.NET run on linux, or will MS decide to litigate MONO and others out of existence?
.NET on anything but MS licensed systems? .NET doesn't apply to Mono (unless they change it like you asked).
.NET?
.NET to the ECMA for review, leaving the current ECMA-standardized bits orphaned. Ironic that Microsoft might use their "embrace, extend, extinguish" tactic on one of their own things.
.NET 1.x if the operating systems running it are no longer supported? The example for 10+ years of support is for "Self-help online support," which is just like the support you can get for MS-DOS or Windows 95. If you consider that generous product support, it sucks to be you.
ANSWER: Microsoft's
QUESTION: Will all
ANSWER: Probably not, depending on the version of the Microsoft
QUESTION: Will
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 run
ANSWER: Microsoft can do this, and should, because all non-MS licensed systems are pirate systems. But don't worry, because the Microsoft run-time EULA for
QUESTION*: Will MS patches and updates applied to MS systems?
ANSWER: What's that got to do with
* -- The question was malformed in it's original post.
Regarding the ECMA, you say, "anybody is free to implement the ECMA standards (see Mono)," but don't you mean just the "ECMA-standardized bits"? Microsoft might not submit any changes made to newer versions of
As for the support, what good is the support for
3 things about computers: they're alive, they're self-aware, and they hate your guts.
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
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 exonerated - but frankly all capitalist entities are there to milk their clients. so....
I love how you were modded as flamebait, but reading the replies shows a distinct lack of flames! Clearly your post is going to cause trouble; it already hasn't!
Since Java is used for almost 100% of new projects (at least in Switzerland in large companies), it can hardly go up any further.
.NET comes to mind as well. I have nothing against that. Lateley we have seen the approach that one tool (J2EE) had to be used for any task as forced by centralized architecture departments. Now I think they have seen that this was wrong, and one has to use the right tool for the job. However, for any large and long term project, there still is no real alternative (nor is one needed) for Java.
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 integration, of course
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 ConfigurationManager)
- Move nasty collections to Generics and adjust test cases.
- Build and run unit tests. Success.
- Alter deployment scripts in MSbuild.
- Test deploy and run tests
- Deploy to live.
IT'S EASY IF YOU BUILD YOUR SOFTWARE TO BE UPGRADED. This is something that most companies do not do.
Took 6 working days in total with ONE developer.
I work for a very large bank. We're currently using all 3 flavors of .NET here, and look at applications on a case by case basis for which ones need to be upgraded. First off, do you have an urgent need to migrate from 1.1 to 2.0? Why can't you keep applications on the 1.1 framework? It isn't going anywhere anytime soon. It will be supported for a long time(probably longer then the life of your apps).
When it makes sense, we will move our applications to the new framework, but not just to move them. All new development here is being done with the 2.0 framework, however we can get variances to develop for 1.1. Applications that are written in 1.1 and have new business requirements are also analyzed. If the requirement is small, we'll simply continue with 1.1 and make the changes in the 1.1 framework, if the changes are large enough, we'll make the changes and port to 2.0. We have no black and white answer as to what constitues migrating, it's left up to the individual business units to make that decision.
2.0 was available (as beta) for sooooo long. Of course, you'll compile your old code, but you won't rewrite it to take advantage of generics / new framework classes...
Why can't I publish ASP versus ASP.NET benchmarks? When you sign the EULA on .NET you sign away rights to publish any benchmarks. Microsoft is hiding the reality.
The real answer is that .NET isn't worth the migration. It's less secure, not significantly faster (and unless you pay attention is not scalable), and more difficult by an order of magnitude to program.
And Microsoft doesn't use .NET for developing the major applications. When I see Microsoft Office written in .NET I will consider .NET a possible development platform.
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.
.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.
.Net 2.0 road. For a really hard-core approach, pick both most critical and hardest to do first.
.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.
There's a couple of strategies here. Firstly, you can go for low-hanging fruit. Many of the changes in
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
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
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.
I'm migrating code from 1.1 to 2.0 now that uses legacy MTA COM objects to do a lot of its work, and it's been a colossal pain in the neck. Any event handlers that access form controls now throw exceptions unless they're specifically commanded not to, since the controls aren't thread-safe. It also becomes somewhat harder to debug concurrency issues when one of those zillion Invoke() calls that now litter your code decides to deadlock, since things that weren't waiting to join() other threads now are, and it's out of your hands.
Given that this comment is almost 24 hours after the posting and it doesn't trash Micro$oft or take sides in the great Windows vs Linux vs Apple vs Newton vs Software Patent debate, chances are that no one will see this...
...but why has no one asked the simple question of "why?"
Why is there a need to port from .Net v1.1 to v2.0? If you've spent the resources of 300 people over 2 years to develop the first version, why are you going to throw that away and re-write for a newer version of a framework?
Isn't IT suppose to *save* money through efficiency and productive (etc.) gains? Well, unless your a "consultant" that question wouldn't make sense.
Synchronize your calendar and mobile phone via text messaging.
1) dozens of additional compile warnings as .NET 1.1 APIs have been marked [Obsolete].
/g
Makes it harder to find genuine problems.
2) StackOverflowException: it now kills your app without leaving a stack trace, and it's very difficult to find it. (if you are not the author of the code)
If you have a test suite, your problems are easy to solve.
Hey, I got rid of web project files as soon as I started using subversion and got in to continuous integration with cruisecontrol.net and nant... It's a stupid idea to have special "web projects" anyway, those are simply class libraries that get created outside what should be a single consolidated solution tree and compile to /bin instead of /bin/debug, and that force vs to load the project by calling the web server, which of course just has to be running when you load the solution. All of it very silly and unnecessary.
.net project includes a solution with no less than 30 projects in it, which is no mean feat to mantain, let me tell ya. About 10 of those are web apps, imagine having all of them as "web projects" and loading the solution that for each one, had to go to the webserver to retrieve whatever it needs... or if I need to change virtual paths on the site, oh the pain! Been there, done that, got the tshirt, web projects out the window.
If you want to do a single quick dirty page just to test something, it's useful, but if you're doing a project that includes several class libraries with and without asp.net, just do everything in class libraries and configure the virtual dirs yourself. Much neater and nicer.
Just for the record, so you won't think I'm running my big mouth without actual experience on this, my latest
shana
We've just taken the plunge after having our 2003 subscription lapse. The MSDN versions has changed somewhat, but i think the professional version is ~$2,500 full price. The top Enterprise one goes for $10k. We settled on the enterprise developer version for ~$5k since it had some stuff we wanted. Upgrade prices are 2/3rd of full I think.
Freedom of speech doesn't come with bandwidth.
Hi, im a 2nd year undergrad computer science student.
I hear that java is all the rage, and ms is evil. I dont understand what the cli is or what a runtime is, but
its your own fault for using ms products you useless tool!
use java because sun microsystems are really 'sticking it to the man'...
why not just use some php and javascript for your big enterprise apps? framework? i need no stinking framework!
angst >> wisdom, any day lol
marketing
After all, I am strangely colored.