The Underscore Archives

>
> I think the product I'm managing is going to be facing the 1.1 ->  
> 2.0 move.
> What are the issues with migrating a large .Net v1.1 project? And  
> what are
> the benefits, aside keeping up with MS's plan to keep on making money?
>


At the Day Job, we have a couple of large apps we succeeded in  
migrating to .NET 2.0, and one we failed to do.

First off, the good stuff. Simple 'migration' is usually a no- 
brainer. The language is backwards-compatible, when people talk about  
migration, they're usually referring to moving VS2k3 to VS2k5 project  
files and the like. There's a tool for this, it comes with the IDE,  
it pretty much works. VS2k5 has numerous benefits over 2003 -  
integrated unit testing, code coverage and performance tools,  
refactoring tools, extensibility, etc.

The next decision is whether you change to the .NET 2.0 'way'. If  
you've got a ASP.NET 1.1 web app, for example, you probably have  
about a million user or server controls doing stuff like headers,  
footers, etc. .NET 2.0 way is using master pages. Or you might have  
nasty old .NET 1.1 grids, binding to DataSets, DataTables and  
DataViews - you've now got the option of doing more declarative  
binding in the page, using ObjectDataSource and friends. Lower down,  
you have generics, proper delegates, nullables, partial classes, and  
so on.

Why change? Because the .NET 2.0 way is better than the .NET 1.1 way.  
Mail me off-list if you want more gory detail :) It's also supported,  
and there are likely to be future migration paths. As far as I can  
tell, MS have basically thrown away .NET 1.1. However, there are  
clear routes from .NET 2.0 through to 3.0 and beyond.

So what were the characteristics of the apps we successfully  
migrated? First off, all of our apps are web apps, so we're talking  
ASP.NET. They're all also Oracle-based.

Basically the successful apps were the smaller (and younger, better- 
designed) apps. This probably sounds obvious, but the less 'weird'  
your app is (fewer complex custom server controls, best use of stock  
framework features) the more likely you are to be successful. The  
primary reason that the app that failed failed was a key control was  
sufficiently complex it proved difficult to port reliably. The app  
also depends on extensive, proprietary, non-standard Oracle data  
access code. (This is a salutary lesson for developers who like to  
add layers to make up for perceived deficiencies in the framework -  
don't do it. It makes migration hard.)

And if you can't migrate? Well, you don't really need to be firing up  
VS2003. You can compile .NET 2 stuff from within VS2005 - grab the  
MSBuild .NET 1.1 targets installer off t'internet, change one line in  
your .csproj files, and VS2005 will happily use the 1.1 compilers. We  
even have .NET 1.1 integrated into Team Foundation Server's (lump of  
shite, don't go there. It's better than Visual Source Safe in the  
same way that having one leg broken is better than having both legs  
broken) nightly build process.

I think Rick (nR) also mentioned that .NET 1.1 apps run happily  
alongside .NET 2.0. This is true, we've had no problems in this area.

I don't know what your ongoing relationship with the product is gonna  
be - but I don't know anyone who enjoys using .NET 1.1. Consider  
future recruitment needs. You could end up with a bit of a white  
elephant if you don't migrate.

What else? Well, I've said before that .NET 1.1 was an alpha release  
of 2.0. 2.0 is *much* better.

Of course - you could also rewrite the lot in Python ;)

Cheers,
Dan

--
Dan Fairs <dan.fairs at gmail.com> | http://www.stereoplex.com/