Transition from ASP/COM+ to ASP.NET model

[Mike]

I have been developing ASP applications for quite a while now. Most of the
apps that I deploy are a typical n-tier setup. ASP GUI on a web server,
Business and Data Components written in VB6 running in COM+ on a separate
server with the SQL database residing on its own server.

I don't really use COM+ for the transactions but more for the DCOM
capabilities and as a way to control the running program. If I need to
compile out a new version of an component and the website is being used I
can just stop the component and then compile it out. Otherwise VB won't let
me compile it out because the component is in use.

My question is how does this translate to ASP.NET. I have read many
articles but have never come across an answer that answers this question for
me. I guess I'm wondering what the best practices are with is comes to
deployment.

Should a lot of the business and data logic I write be contained on the
webserver in the Code Page Behind? Or should I separate it out into like I
am currently doing? If I deploy it like that and need to update components
can I compile over the version out there even if its being used or will I
get an error because the dll its trying to update is in use?

I know there is a right or wrong answer, I'm just looking for the most
accepted way of doing it as a starting point.

Mike

 

[Tammy]

I have been developing ASP applications for quite a while now. Most of the
apps that I deploy are a typical n-tier setup. ASP GUI on a web server,
Business and Data Components written in VB6 running in COM+ on a separate
server with the SQL database residing on its own server.

Wow, RAD!! Been there and loved every minute of it.

I don't really use COM+ for the transactions but more for the DCOM
capabilities and as a way to control the running program. If I need to
compile out a new version of an component and the website is being used I
can just stop the component and then compile it out. Otherwise VB won't let
me compile it out because the component is in use.

You can register your COM+ app as Server application instead of a Library
application. This way, your app runs in its own DLLHOST.EXE process instead
of running inprocess with inetinfo.exe. It's easier to shutdown the
component in Component Services this way so you can recompile. Also, you
can designate your IIS virtual directory to run High (Isolated) protection.
Your virtual directory will also run in its separate instance of DLLHOST.EXE
that you can find in Component Services. You should avoid running both the
virtual dir and the component in their own DLLHOSTs for performance reasons
(cross-process marshalling, etc). What I used to do is run the virtual dir
in High(Isolated) and run the COM+ app as a Library application. If you
need to replace the dll, simply Unload the virtual directory inside IIS
Manager to release the dll.

My question is how does this translate to ASP.NET. I have read many
articles but have never come across an answer that answers this question for
me. I guess I'm wondering what the best practices are with is comes to
deployment.

Have a look at the Duwamish example on MSDN:
http://msdn.microsoft.com/library/d...ml/vtgrfarchitecturaloverviewofduwamish70.asp
It's even better if you can download the whole solution so you can see the
Enterprise template they use. My team and I generally stick to this
methodology, now. Start with a solution, add a Web project, add another
project for the Business Facade, add another project for Business Rules, add
another project for Data Access and maybe other common data objects. Add a
database project to house our stored procedures

Should a lot of the business and data logic I write be contained on the
webserver in the Code Page Behind? Or should I separate it out into like I
am currently doing? If I deploy it like that and need to update components
can I compile over the version out there even if its being used or will I
get an error because the dll its trying to update is in use?

No. Use code-behind to separate presentation code from the aspx page - i.e.
no more "<%%>" tags and "<script runat=server>" tags . Use code-behind also
to handle postback events and to call Business Logic layers through the
Business Facade layer. Example, have the code behind call BusinessFacade to
call DataAccess to request a DataTable, then set a DataGrid's DataSource to
the DataTable and call DataBind(). The important thing is to keep
BusinessFacade the public interface, i.e. code-behind should never directly
call the DataAccess layer.

I know there is a right or wrong answer, I'm just looking for the most
accepted way of doing it as a starting point.

I don't think there is a right or wrong answer. It starts to become an art
after a while, then it becomes a matter of style. Two sets of code may do
identical things but one may look more elegant and perform better than the
other.

 

[Empire City]

My question is how does this translate to ASP.NET. I have read many

There's a whole help section on COM Interoperability in Visual Basic and Visual C# in the Visual Studio 2002 help section. Here's the local link:

ms-help://MS.VSCC/MS.MSDNVS/vbcn7/html/vaconCOMInteroperability.htm

I think it's somewhere in MSDN also. I included the mIN page below.

Have a look at the Duwamish example on MSDN:

Excellent advice!

I don't think there is a right or wrong answer. It starts to become an art
after a while, then it becomes a matter of style. Two sets of code may do

I don't exactly agree with this. There are good standards and there are no standards. Emulating the multi-tier design of Duwamish is a good standard. You'd never adopt it as a style if it was not a good thing. MS had their geniuses spend hours on coming up with it. It's practical and elegant, although it's not really that big of an application. For high performance web sites it's designed well as stated in the documentation. If your application also needs back end WinForms, I think the Fitch example fits although I haven't totally gotten into it. Northwind seems a bit outdated at first glance. I read somewhere that MS will soon publish a full blown shopping cart as a example to emulate which far exceeds what Duwamish does. Could Duwmaish be improved? Probably! Wouldn't it be great if it were an open source type thing like the Apache.org RFQ where everyone always can tweak it to perfection.

I like the database design of Duwamish also. Using that PKey int 4 for all primary keys is good for relations and quick access.

--

Visual Basic and Visual C# Concepts

COM Interoperability in Visual Basic and Visual C#
When you want to use COM objects and .NET objects in the same application, you need to address the differences in how the objects exist in memory. A .NET object is located in managed memory - the memory controlled by the common language runtime - and may be moved by the runtime as needed. A COM object is located in unmanaged memory and is not expected to move to another memory location. Visual Studio and the ..NET Framework provide tools to control the interaction of these managed and unmanaged components. For more information about managed code, see Common Language Runtime.

In addition to using COM objects in .NET applications, you may also want to continue to develop COM objects using Visual Basic .NET or Visual C# ..NET.

The links on this page provide information about the concepts and implementation details for interoperating between COM and .NET objects.

In the Visual Basic and Visual C# Documentation
COM Interop
Provides links to topics covering COM interop in Visual Basic, including COM objects, ActiveX controls, Win32 DLLs, managed objects, and inheritance of COM objects.
COM Interop Part 1: C# Client Tutorial
Shows how to use Visual C# to interoperate with COM objects.
COM Interop Part 2: C# Server Tutorial
Describes using a Visual C# server with a C++ COM client.
COM Interop Wrapper Dialog Box
Discusses the assembly wrapper that Visual Studio can build for COM object references in Visual Basic and Visual C# projects. This wrapper is generated if the project system cannot find a registered interop wrapper for the COM component.
Additional Information
Interoperating with Unmanaged Code
Briefly describes some of the interaction issues between managed and unmanaged code, and provides links for further study.
COM Wrappers
Discusses runtime callable wrappers, which allow managed code to call COM methods, and COM callable wrappers, which allow COM clients to call ..NET object methods.
Advanced COM Interop
Provides links to topics covering COM interop with respect to wrappers, exceptions, inheritance, threading, events, conversions, and marshaling.
Type Library Importer (Tlbimp.exe)
Discusses the tool you can use to convert the type definitions found within a COM type library into equivalent definitions in a common language runtime assembly.

 

[Empire City]

My question is how does this translate to ASP.NET. I have read many

There's a whole help section on COM Interoperability in Visual Basic and Visual C# in the Visual Studio 2002 help section. Here's the local link:

ms-help://MS.VSCC/MS.MSDNVS/vbcn7/html/vaconCOMInteroperability.htm

I think it's somewhere in MSDN also. I included the mIN page below.

Have a look at the Duwamish example on MSDN:

Excellent advice!

I don't think there is a right or wrong answer. It starts to become an art
after a while, then it becomes a matter of style. Two sets of code may do

I don't exactly agree with this. There are good standards and there are no standards. Emulating the multi-tier design of Duwamish is a good standard. You'd never adopt it as a style if it was not a good thing. MS had their geniuses spend hours on coming up with it. It's practical and elegant, although it's not really that big of an application. For high performance web sites it's designed well as stated in the documentation. If your application also needs back end WinForms, I think the Fitch example fits although I haven't totally gotten into it. Northwind seems a bit outdated at first glance. I read somewhere that MS will soon publish a full blown shopping cart as a example to emulate which far exceeds what Duwamish does. Could Duwmaish be improved? Probably! Wouldn't it be great if it were an open source type thing like the Apache.org RFQ where everyone always can tweak it to perfection.

I like the database design of Duwamish also. Using that PKey int 4 for all primary keys is good for relations and quick access.

--

Visual Basic and Visual C# Concepts

COM Interoperability in Visual Basic and Visual C#
When you want to use COM objects and .NET objects in the same application, you need to address the differences in how the objects exist in memory. A .NET object is located in managed memory - the memory controlled by the common language runtime - and may be moved by the runtime as needed. A COM object is located in unmanaged memory and is not expected to move to another memory location. Visual Studio and the ..NET Framework provide tools to control the interaction of these managed and unmanaged components. For more information about managed code, see Common Language Runtime.

In addition to using COM objects in .NET applications, you may also want to continue to develop COM objects using Visual Basic .NET or Visual C# ..NET.

The links on this page provide information about the concepts and implementation details for interoperating between COM and .NET objects.

In the Visual Basic and Visual C# Documentation
COM Interop
Provides links to topics covering COM interop in Visual Basic, including COM objects, ActiveX controls, Win32 DLLs, managed objects, and inheritance of COM objects.
COM Interop Part 1: C# Client Tutorial
Shows how to use Visual C# to interoperate with COM objects.
COM Interop Part 2: C# Server Tutorial
Describes using a Visual C# server with a C++ COM client.
COM Interop Wrapper Dialog Box
Discusses the assembly wrapper that Visual Studio can build for COM object references in Visual Basic and Visual C# projects. This wrapper is generated if the project system cannot find a registered interop wrapper for the COM component.
Additional Information
Interoperating with Unmanaged Code
Briefly describes some of the interaction issues between managed and unmanaged code, and provides links for further study.
COM Wrappers
Discusses runtime callable wrappers, which allow managed code to call COM methods, and COM callable wrappers, which allow COM clients to call ..NET object methods.
Advanced COM Interop
Provides links to topics covering COM interop with respect to wrappers, exceptions, inheritance, threading, events, conversions, and marshaling.
Type Library Importer (Tlbimp.exe)
Discusses the tool you can use to convert the type definitions found within a COM type library into equivalent definitions in a common language runtime assembly.