CODEWITHSUNDEEP
c#asp.netasp-classicwindows-server-2003
Caveatrob
Caveatrob

Reputation: 13277

Migrating Classic ASP progressively to .NET on Windows Server 2003, 64-bit

I've got a rather large ASP site using VBScript exclusively (no COM components) running in a 32-bit space on IIS in 64-bit Windows Server 2003. You can see a rough sketch of the architecture here:

overview of programming architecture

I want to start migrating that to ASP.NET, but my immediate need is to have the database access in a place where I can start using it with other C# and .NET apps residing on the same server (compiled for 32-bit with VS2008).

My thought was to create C# .dll's and then call them from the ASP code with interop, and as I migrate, I'll have the data portions already done.

What's the performance hit for Interop? I probably have around 200 people, at most, hitting the app doing database submissions within a couple hour time frame. I have no capacity or performance issues with the current setup.

I've got a SQL Server (2005) box on the same subnet that I connect to from this one; it's also 64-bit Windows Server 2003.

Is this a feasible strategy? Are there better ways to go about this given my architecture?

A huge problem right now is that the ASP app uses hundreds of stored procedures; I inherited it at a point where development was done in overlapping pieces, where a simple operation against a user, for example, may be done with different procs across different pages. A big goal is to centralize the data access to a component and abstract out the implementation within the database. So, if I add or change a field, the ASP app won't have to know its name; it will just access via the same property on the object.

Upvotes: 1

Views: 371

Answers (1)

Eric J.
Eric J.

Reputation: 150108

I took a very similar route migrating a very large billing application from VB6 to C#. It's an entirely feasible and reasonable approach.

I would focus on migrating the business logic and data access out of the UI into appropriate classes first, then begin moving parts of the UI from classic ASP to ASP.Net.

With 200 people over an hour or two, you will not notice the interop overhead.

Especially given that you have to deal with the UI directly accessing the database using multiple code variants, it is probably worth investing some time in putting automated tests into place for the existing code. Make sure that you follow a test driven approach for the new code that you write. If you don't invest significantly in automated testing, you risk the application breaking in hard-to-detect ways as you re-architect it in phases.

Upvotes: 2

Related Questions