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.
Related
I'd like to pass an IShellItemArray to an out-of-process COM object residing within an exe. I'd prefer to use existing interfaces before creating my own, so I thought I'd try having the out-of-process object implement IShellExtInit. Seemed like a good fit.
Anyway, it appears that attempting to create/query interface for IShellExtInit fails for out-of-process COM servers. I found some additional evidence indicating that it's not possible because that particular interface lacks marshaling support.
Is there anything that can be done to fix that, short of defining my own similar interface (with the oleautomation attribute)? Alternatively, are there any other existing generic interfaces, that work out of process, for passing an IShellItemArray? Thanks for any info.
IExecuteCommand is supported out-of-proc where IObjectWithSelection is the way the array is passed. Might only work on Win7 and later.
IDropTarget is also supported out-of-proc but it is more work (fake dropping a data object). It works back to at least WinXP if you care about that.
In powershell, when using new-object to instantiate, or get a reference to (or whatever you want to call it), a COM object I recall that the COM object needed to have a certain property to be able to expose it's functionality (through the registry I think is how it did it, via its Class-Id or something).
I can't for the life of me remember what the technical term for the "exposing" was, just that if the object/module/dll/assembly wasn't configured appropriately, the object wasn't available for instantiating with new-object (so that you couldn't just start instantiating objects within 3rd party software I assume is why an explicit setting must be made).
If anyone knows what this term is called it would be very helpful. Its the first step I'm taking in reusing a clients software functionality from a webservice, so I don't have to rewrite all over.
Much appreciated...
You have to register the COM server (binary) which creates a number of registry entries. The primary one PowerShell needs is the ProgID. Also, register a typelib should help PowerShell provide you with member information on the created object. You typically use regsvr32 for a native COM binary and regasm for a managed COM binary.
I have been stuck on this for a few days and I would ping this community for answers before I give up.
*I would like to pass a delegate from a client application to a server application across app domains using remoting.
*The delegate is definition is in an Assembly which is shared between the server and client.
* The delegate it self is an anonymous delegate for which the body is declared on the client side.
My problem is that when I pass the delegate over to the server, the server requires the assembly for which the delegate body is declared(one of the client assembly). Our software architecture prohibits loading the client assembly. In my head when I think about it I should be be able to pass the IL which defines the delegate over to the server, create a delegate using dyanmicMethod and execute it. If that is the case then why does .net require the assembly even when the delegate body contains simple types? Is there a way to remote an assembly without requiring the assembly where the body is declared?
PS: the reason I want to do is for performance. The delegate encapsulates multiple calls to the server. I am unable to modify the server APIs etc to do this.
Thanks fro any information
I don't think you can do this.
When you pass the delegate to the server, the server will need to be able to load the definition of the class that defines the delegate, so there is no way to get a client-only anonymous method to execute on the server side.
There is a discussion on how to work around this at this link. I don't know if you can reorganize your code to align with that pattern.
It would be an intriguing idea to send some IL over to the other side and execute this in place, but I have no idea if that is possible. Sounds like there would be an awful lot of security and other barriers to cross to get this to work.
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).
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.