r99tdigger
New Member
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.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.