COM .net question
-
-
I have heard from several sources, both here and from guys I used to work with, that COM, per se, is not part of the new .net architecture. Is so, is there no component type technology available at all? If it is present, what is it? Stan Shannon
Traditional COM (as in AddRef, Release, QueryInterface) is gone, replaced by .NET components that are a million times simpler. Check out Cross language inheritance in .NET. Writing a component in .NET is as simple as writing a class, and consuming these components just as simple. cheers, Chris Maunder
-
Traditional COM (as in AddRef, Release, QueryInterface) is gone, replaced by .NET components that are a million times simpler. Check out Cross language inheritance in .NET. Writing a component in .NET is as simple as writing a class, and consuming these components just as simple. cheers, Chris Maunder
-
Traditional COM (as in AddRef, Release, QueryInterface) is gone, replaced by .NET components that are a million times simpler. Check out Cross language inheritance in .NET. Writing a component in .NET is as simple as writing a class, and consuming these components just as simple. cheers, Chris Maunder
Wow, this is good to know! I guess I managed to outlast COM, without having to ever learn it. I knew it was to nutty a technology to last...
-
Wow, this is good to know! I guess I managed to outlast COM, without having to ever learn it. I knew it was to nutty a technology to last...
That was pretty much my reaction too :) For more info, check out the article The .NET Framework and COM:
One of the primary goals of the .NET Framework is to make COM development easier. One of the hardest things about COM development is simply dealing with the COM infrastructure. Consequently, to make COM development easier, the .NET Framework automates virtually all of what developers currently think of as “COM,” including reference-counting, interface description, and registration. It’s important to note that this doesn’t mean that .NET Framework components aren’t COM components. In fact, a COM developer using Visual Studio 6.0 could call a .NET Framework component and, to the developer, it would look like a COM component, complete with iUnknown data. Conversely, a .NET Framework developer using Visual Studio.NET would see a COM component as a .NET Framework component. There is a caveat to this relationship: COM developers must manually do many of the things that .NET Framework developers can rely on the runtime to automate for them. For example, the security of a COM component must be written manually, and its memory can’t be automatically managed, and, to install a COM component, entries must be placed in the Windows registry. For .NET Framework components, the runtime automates these features. Components are self-describing, for example, and can therefore be installed without registering them in the Windows registry.
cheers, Chris Maunder
-
That was pretty much my reaction too :) For more info, check out the article The .NET Framework and COM:
One of the primary goals of the .NET Framework is to make COM development easier. One of the hardest things about COM development is simply dealing with the COM infrastructure. Consequently, to make COM development easier, the .NET Framework automates virtually all of what developers currently think of as “COM,” including reference-counting, interface description, and registration. It’s important to note that this doesn’t mean that .NET Framework components aren’t COM components. In fact, a COM developer using Visual Studio 6.0 could call a .NET Framework component and, to the developer, it would look like a COM component, complete with iUnknown data. Conversely, a .NET Framework developer using Visual Studio.NET would see a COM component as a .NET Framework component. There is a caveat to this relationship: COM developers must manually do many of the things that .NET Framework developers can rely on the runtime to automate for them. For example, the security of a COM component must be written manually, and its memory can’t be automatically managed, and, to install a COM component, entries must be placed in the Windows registry. For .NET Framework components, the runtime automates these features. Components are self-describing, for example, and can therefore be installed without registering them in the Windows registry.
cheers, Chris Maunder
-
Hang on - is this a positive comment about .NET in the lounge? :eek: cheers, Chris Maunder
-
COM is, however the ONLY route for interoperability between the managed (.NET) world and the unmanaged (unmanaged C++, VB6, Delphi etc. etc.) domain. About a year ago, we started designing more or less everything using COM simply to make it cheaper for us to take the .NET transition (notwithstanding the other benefits we have gained as a result). We are now in a position where we can ship a working system today. Tomorrow, we will have replaced some components with .NET ones, created brand new .NET features, fixed existing problems in the unmanaged code, and added new unmanaged features, and still be in a position to test and ship the end result as a seamless whole, with only a tiny amount of _necessary_ reworking (this is not to say that we haven't treated this as an opportunity to rethink and refactor!). .NET's component model is what COM would have been, had it been designed for the job COM ended up doing, and not an evolution of the old OLE technologies. It is indeed cool. :) Matthew Adams Development Manager Digital Healthcare Ltd
-
Hang on - is this a positive comment about .NET in the lounge? :eek: cheers, Chris Maunder