.NET and COM+

[PerryJoshiGodrez]

I get the feeling that .NET has knocked the wind out of COM+. However I haven't read anywhere whether the .NET runtime will superceed COM+ or whether it will run side by side, on top of, etc.
More interesting; will the runtime have all the promised features that were not shipped with COM+

Perry
Brickend Consultants Ltd

[Ghannodahn]

.NET's component services are natural evolutions of COM technology. They support XML namespaces, rather than GUID's, natively use XML and HTTP protocols for connection and remote communication, self-registration, self-description (no need for MIDL), etc.

In addition, COM objects can reference .NET assemblies as though they were native COM, and .NET can do likewise with COM objects.

Ghannodahn Kirrel
Librarian, The Infinity Citadel
http://www.icitadel.com

[Mr Ben]

Rather than self-registration, no component in .NET needs to be registered. It inherently contains unique information within it's metadata which all components store internally.

Therefore, to distribute a component, you will need to sign it with a public key. A utility (SN.EXE) is supplied which generates the oublic key for you, along with thw associated private key which is required for signing the component. To make this component available to other components and applications, it needs to be added to the Global Assembly Cache which is just essentially a reserved area on your hard drive.

The uniqueness of the component is made up from a combination of the public key, the version and the culture (locale) of the component. When an application attempts to invoke the component, because it isnt registered, .NET takes several steps to locate the component :

1. Consult the Global Assembly cache
2. Use a developer supplied codebase hint (i.e. use a config file to point to the component you want to use via some supported protocol, i.e. http:// file:// etc.)
3. Search using a relative path (from the application and any folders below it)
4. Load will fail