By the "traditional" way I mean registering the DLL in registry.
There seems to be another method to set up it by going to mmc->Component Services->COM+ Applications and adding the .tlb file.
I have a COM library that supports both methods. When it installs, it registers itself in the registry as a COM component and it works fine. However, when I added the .tlb file using the Component Services method, the behavior seems to be different and it starts giving out errors.
I suspect it has something to do with marshaling and inter-process object transfer? (Sorry, I'm really a noob in the COM area)
Can anyone point me to a good resource to clear my understanding?
COM+ (Component Services) provides a lot of infrastructure out of the box; for instance COM+ provides transaction, security, object pooling and some other services.
When you register a COM component under COM+ it will run "Out Of Process"; in this mode you are guaranteed to have a proxy between your COM server and its clients.
The best place I can think of for learning more about COM+ is the official MS site: http://msdn.microsoft.com/en-us/library/ms685978(VS.85).aspx
Agree with the previous post.
One thing to add: actually registering the type library (.tlb file) is normal for COM as well, not only for COM+.
The type library is generated automatically by IDL compiler. It contains a description of your interfaces and objects.
So that you can "import" your COM component into some project, and the definition of the interfaces and objects are visible.
Related
In its simplest form, COM allows you to instantiate C++-like classes from DLL in your application. Basically it's a glorified wrapper around LoadLibrary and some conventions regarding the interface. This is called using an in-process component.
But COM also supports out-of-process components. If you instantiate a class from such a component, COM starts a new process. Your objects live in said process, and are marshalled transparently over to you, so you don't care too much about where they live. They might even be on a different computer (DCOM). You can also fetch objects from already running applications. A well-known example is controlling MS Office via a script. This is called Automation (formerly OLE Automation, and there is a bit of confusion around what exactly this term encompasses).
There are a couple of nice articles explaining how (in-process) COM works low-level (e.g. COM from scratch. I'd like to know how it works when your component is out-of-process. Especially, what IPC does COM use beneath the hood to communicate between the processes? Window messages, shared memory, sockets, or something else? MSDN lists COM as an IPC method by itself, but I'm guessing it has to use something else underneath. Are different IPC methods used in different cases (instantiating an OOP component from C++, accessing an Excel document from VBScript, embedding a document in another via OLE)? It seems like it is all the same underlying technology. And lastly, how does marshalling fit in the picture? I believe it is neccessary to serialize method parameters for transmitting between processes, correct?
According to this MSDN article, it's RPC.
When you instantiate an OOP component, the COM subsystem generates an in-process proxy. This proxy is responsible for packing parameters and unpacking return values. It also generates a stub in the server process, which, expectably, unpacks parameters and packs return values.
Interestingly enough, the whole marshaling process can be customized, by implementing IMarshal.
DCOM was originally added as an extension to COM, precisely for cross apartment calls. Note cross apartment calls are not always from process to process. A process can have many apartments (0 or 1 MTA and/or 0 to n STAs, etc.) . There is at least one apartment per process, etc.
DCOM, some kind of a "middleware", needed a technology for all this low-level work: data representation, caller/callee convention, memory management, wire marshaling, session handling, security, error handling, etc. so Microsoft naturally used the in-house implementation of DCE/RPC: MSRPC. Note that as Microsoft says on its site,
"With the exception of some of its advanced features, Microsoft RPC is
interoperable with other vendors’ implementations of OSF RPC."
There was some tentative work to have all this implemented by other vendors, but they were basically killed by the rise of the internet and HTTP.
Also, note this RPC uses Windows Messages for STA apartement messages. I suggest you read carefully this document (not available any more on Microsoft site, shame on them :-) for more details:
DCOM Architecture by Markus Horstmann and Mary Kirtland - July 23, 1997 .
See also this interesting case study about a DCOM/RCP issue that should tell you a lot of how RPC over Windows message works under the scene: Troubleshooting a DCOM issue: Case Study
I have created a COM local server(exe) sample project using ATL wizard in VS2008.
but when I use cocreateinstance to create the COM object, I am getting an error "E_NOINTERFACE".
As I know that "regsvr32" can be used to register com components and their respective interfaces but those are for in process com dlls, so do we need some extra steps apart from just launching com server exe before we make a call to cocreateintsance.
Any help will be greatly appreciated.
Regards
Ashish
When you have a local server your client will run in a different process. If you have a server with a custom interface instead of IDispathch you need to marshal the interface. The interface marshaling is done in the proxy/stub. This is implemented in a DLL what will be loaded in the client process as well as in the server process.
Create and/or register the proxy/stub DLL.
Suppose I introduced a COM interface and don't want any third party to use it. I have full control over the sources of the COM component and the IDL file that holds the interface definition. My COM component will need marshalling stuff fro that interface, so I'll need to either implement IMarshal or provide a typelib or provide a proxy/stub.
Obviously if I provide a typelib anyone can inspect it and find what my interface is and how it can be used. That's not what I want.
What if I use proxy/stub? Will it expose the interface and let anyone inspect it or will it keep the interface details covert?
Unfortunately this is not possible. The idea of COM is that clients can discover the components and the interfaces.
In a previous job I worked on a digital rights equipped application and there we deliberately did NOT use COM just to make it more difficult for people to tap into our application. We had to build our own component infrastructure (in addition to other security measures).
When a COM+ application is created the wizard offers to choose between a library and a server application.
A server application is activated in a separate process and this can be used to cheaply interop 64-bit consumers with 32-bit in-proc COM components.
What's the use of library applications that are activated right in the caller process? Why use them instead of plain old in-proc COM servers?
There are several:
Performance - it is a bit faster as you don't have to go through the message automation (marshalling and unmarshalling)
Isolation - if many different Applications are using the Library, then each will have it's own copy. This point is most important when dealing with the differences between an MTA (Multi Threaded Apartment) and a STA (Single Threaded Apartment Model)
THE IN-PROC Server (which is really an out of processes, out of the caller's process) is shared by all different callers (this is a great way to have cheap IPC/RPC)
Ok I am editing with a few more definitions, and a bit more references:
Context is really all the state around the use of an object.
causality is really a thread like concept indicating the use of an object in a context. ("A causality is a distributed chain of COM method calls that spans any number of contexts in any number of processes" - from ISBN: 0-201-61594-0)
Those to concepts are discussed in about 30 pages of chapter 2 from Tim Ewald's excellent book "Transactional COM+" ISBN: 0-201-61594-0
So taking a direct quote from the summary of chapter 2:
"An object can interact with its context using object context and with a given causality using call context. These two objects provide interfaces for interacting with COM+ runtime services. This style of coding, 'reaching into context' makes COM+ development very different from classic COM development."
Finally, Chapter 2 has a discussion "Why Library Applications?",
(which is different from your question, Why not just plain old COM?)
His arguments mainly indicate the same reasons from using a COM object,
1. Each application has it's own instance.
2. Load into non- DLLhost.exe process.
3. Much Less Overhead.
4. Simple Deploy of common Objects.
So the bottom line is that if you are not Distributed, and Not Transactional In Nature, there may be no real advantage to using COM+ over COM. But if you write a COM+ application and deploy it as a LIBRARY application, it will behave a little bit more like a COM component.
Hope that helps.
The main purpose is to benefit from COM+ application contexts.
CoGetObjectContext for IObjectContext or IObjectContextActivity will return E_NOTINTERFACE from pure in-process component, while it will successfully work in a COM+ library application (and a server application of course).
The security context is also available through CoGetCallContext for ISecurityCallContext.
It has nothing to do with performance or isolation.
As a site note, one way to check what's available to COM+ library applications is to run dcomcnfg.exe navigate to Component Services, Computers, My Computer, COM+ application, create a new library application and check what's still enabled (as opposed to a server application).
I have an ATL C++ in-proc COM component. This component is not for external use - I only need it for use in our application.
Once in a while users put it into COM+ and this leads to all sorts of weird errors - "Access denied", etc which I'd like to just never hear about. The best way would be to do something that would prohibit putting the component into COM+ so that it can only be used as an in-proc server. Is there a way to do this?
Do you implement only your own interfaces? If so, you should be able to mark them "[local]" in the IDL, and then strip the module of all marshalling information (type library, P/S), etc.
If there's no basis for marshalling available, COM+ shouldn't be able to register the module. COM+'s mechanism for interception relies on forcing objects into a remote context and getting in between the proxy and stub and their corresponding parties. So, if you remove every opportunity for marshalling, it shouldn't be able to intercept your interface methods.
Prevent registering your module is finalized and then use your DLL as described in this article Creating COM objects directly from the dll.