We have a Com+ VB6 DLL used in our asp classic application. After upgrading to IIS 6.0 and Windows Server 2003 it seems to be causing us problem. How should we replace it with .NET (2.0) functionality?
Assume re-writing the asp classic pages is out of the question.
EDIT: If rewriting it as a com accessible assembly, won't this leave the same issues with Com+?
This depends a lot on exactly what the COM component is doing, but the simplest option would probably be a COM library in .NET.
That would likely require the least amount of changes to the calling client (asp classic app). If you setup the API to match your VB 6 COM api, it should be pretty much a drop in replacement.
Migrating to a webservice or some other option might be cleaner in some cases, but would require more changes to your application. Without more information, it's impossible to determine whether this would be worthwhile or not.
It really depends on how the com dll is being used. I'm assuming that you need to keep the classic asp application otherwise you'd rewrite the whole thing.
You don't want a webservice if the com dll is working with the session or http context of the site. I would move the com code over to a .NET Library Assembly, register it with interop (tlbimport/tlbexport) and use the interop assembly in your classic asp app to talk with the new .NET library.
I'm assuming that your VB6 component is using some COM+ services. If so, then I would rewrite the VB6 component in .NET as a ServicedComponent and then register it with COM+ using Regsvcs.exe.
If your VB6 components are accessing a database (or making other long running out of apartment calls) then, as an added benefit of migrating your VB6 component(s) to .NET, you may see the elimination of performance issues when there are many concurrent requests to your components. For a great description of how and why see the Avoid Long Running Method Calls from a Single-Threaded Apartment (STA) section from the article Preserving Application Performance When Porting from MTS to COM+.