> > My question is how does this translate to ASP.NET. I have read many
There's a whole help section on COM Interoperabilit y 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/vaconCOMInterop erability.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 Interoperabilit y 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.