views:

828

answers:

10

I am a .Net developer that has been tasked with upgrading a classic asp website to asp.net. The website is currently running on luck and bubble gum but there is not enough time or money to stop progress and do a full rewrite. Of course I will still need to be able to deliver new features while I am upgrading.

What strategies should I use to make a smooth gradual change to asp.net? Should I convert to a single tier .net solution and then refactor to a proper multi-tier solution or should I design my business and data layers now? Should I go straight to 3.5 or is it easier to just get to 1.1 and upgrade to 2.0 or 3.5 after?

A full conversion would probably take 3-5 months. There is also some existing 1.1 code, which is why I am considering using that as a jumping off point.

+1  A: 

How long would a complete conversion/rewrite take? It's also going to depend on how you've structured your original project.

I can answer that you should just target v2.0 (3.5 if you want/need it's features) from the beginning. There's no need to subject yourself to 1.1 of the framework.

hometoast
+1  A: 

Was asked here

Eduardo Molteni
A: 

You may want to look at the new ASP.NET MVC framework. The level of flexibility is amazing and the coding style is slightly more akin to the ASP classic approach, albeit with much better separation of church and state.

Codewerks
A: 

Take a look at Snitz Forums (www.snitz.com) - they are currently in ASP but the port to ASP.NET is almost complete. Both code bases are available for you to look at so you may get an idea of how it has been done there to help you.

Guy
A: 

I would avoid going into .NET 1.1 since Microsoft is ending support for v 1.1 of the .NET Framework on 10/14/2008. The extended support runs through 10/8/2013 but is typically expensive to purchase. Any bugs or security holes will not be addressed and are your problem.

http://support.microsoft.com/lifecycle/?LN=en-us&x=11&y=10&p1=1249

Paul

+4  A: 

Having been a longtime classic asp programmer, and now an ASP.NET dev, I would take the time and architect it properly in the 2.0 framework (3.5 if you want/need the features).

My last job we had a large handful of very badly build classic asp apps that we were rebuilding, and the "nuke and pave" approach was the most successful. Use the existing classic app as your functional spec and wireframes, and build your tasks and tech specs off of that.

boykster
+8  A: 

Don't throw away your code!

It's the single worst mistake you can make (on a large codebase). See Things You Should Never Do, Part 1.

You've invested a lot of effort into that old code and worked out many bugs. Throwing it away is a classic developer mistake (and one I've done many times). It makes you feel "better", like a spring cleaning. But you don't need to buy a new apartment and all new furniture to outfit your house. You can work on one room at a time... and maybe some things just need a new paintjob. Hence, this is where refactoring comes in.

For new functionality in your app, write it in C# and call it from your classic ASP. You'll be forced to be modular when you rewrite this new code. When you have time, refactor parts of your old code into C# as well, and work out the bugs as you go. Eventually, you'll have replaced your app with all new code.

You could also write your own compiler. We wrote one for our classic ASP app a long time ago to allow us to output PHP. It's called Wasabi and I think it's the reason Jeff Atwood thought Joel Spolsky went off his rocker. Actually, maybe we should just ship it, and then you could use that.

It allowed us to switch our entire codebase to .NET for the next release while only rewriting a very small portion of our source. It also caused a bunch of people to call us crazy, but writing a compiler is not that complicated, and it gave us a lot of flexibility.

Also, if this is an internal only app, just leave it. Don't rewrite it - you are the only customer and if the requirement is you need to run it as classic asp, you can meet that requirement.

Michael Pryor
I have no idea how this answer got so many upvotes (probably solely from you bringing up writing your own compiler for it) I couldn't disagree with this more unless there is absolutely zero way possible in time constraints to rewrite it. Keeping bad code around is like a festering wound, it will only get worse if left untreated (unless it's absolutely 100% complete and will never have a change EVER which is doubtful in software) Besides I would go out on a limb and say a majority of the responsibilities of that old code could be replaced with a proper ORM solution and domain model.
Chris Marisic
@chris Hello straw man! You say the code is "bad". Why is working code "bad"?
Michael Pryor
Because it probably doesn't follow any type of domain driven development principles, it probably has UI logic intertwined with business logic, it also probably has a custom coded DAL built on either datatables (i'm not sure if they're old enough for that even) or stored procs, etc. Most likely no inversion of control was applied and so on. Most modern software design patterns didn't exist during classic ASP (or weren't used then atleast)
Chris Marisic
A: 

easiest way to do it is to just jump in head first. get some asp.net books and dive into visual studio. Do the examples, play with it, build something fun for yourself. You'll learn by doing.

DanWoolston
A: 

I'm also working on a gradual migration from classic ASP to ASP.NET. Our first phase is migrating some common logic from an ASP include to a .NET assembly that is exposed to COM Interop so they can be called by both classic ASP and ASP.NET. I've written some tests using ASPUnit to verify the behavior after migration to the .NET assembly (with the added benefit of safer refactoring). Once the core logic is in .NET, we can begin creating new pages in ASP.NET and migrating individual ASP pages to ASP.NET at our own pace.

I would recommend .NET 2.0 or 3.5 over 1.1. ASP.NET MVC looks like an attractive upgrade path.

Mike Henry