Either I don't understand COM objects, either it's all that confusing.
I frequently 'create' , 'dispatch' COM objects - either in Python, either in VB ( Obj = win32com.client.Dispatch('Visum.Visum') or Obj = CreateObject("Excel.Application") respectively).
That's easy, obvious and everything's fine.
But how can I:
a) connect to COM object which is already running
b) get list of running processes which are COM objects
in VB what is the reference, and additional info on: CreateObject command. In Python it's part of well defined, comprehensive library of win32com whereas in VB it's just single method without reference: http://msdn.microsoft.com/en-us/library/7t9k08y5(v=vs.80).aspx
Highly confusing (COM object,server? connection, dispatching, registering??)
Thanks for claryfying
Rafal
i2
First of all, I would suggest reading a good introduction to COM. Personally, i think that 'Essential COM' by Don Box is the best book about COM. Spending a few hours with it will save you many hours later.
That being said, let's move to your questions.
a) In order to retrieve an existing COM object from VB, you need to call GetObject function. This will only work for COM objects which are registered with Running Object Table. Excel does this, so there shouldn't be any problems with that.
b) as Hans Passant correctly noted, this question doesn't make sense. Processes and COM objects are completely unrelated things, except for the fact that processes host the COM objects. It is similar to asking 'which processes are instances of class X'. However, a process can host a COM object (or many of them). These object can be alive only temporarily, so what would you expect there? Besides, many COM classes are implemented within dlls, but created instances obviously are hosted within a process - so what would you expect there?
COM technology is something I didn't not use for a while, so sorry if some info might be wrong (anyway, I've got my book "Inside COM+ base services" with me!)
Briefly speaking, let's give a simplified definition of a COM object: it nothing else than a standard DLL with classes exposing a standard interface IUnkown with the following methods:
AddRef: to register a client consuming the COM object
Release: to unregister a client (usually unused objects stop running, but other might remain resident)
QueryInterface: to get the address of a function
QueryInterface is used to dynamically retrieve the address of a function (late-binding) which is powerful (you don't have to know the DLL at compile time) but time consuming. On the other hand, you can directly reference the addresses of the functions at compile-time because those DLL are registered in the system (all the informations are stored in the registry)
Creating a new object or getting the address of a running object is done through RPC (remote procedure call) which will load and/or play the role of a proxy
So to create a new instance of a COM object, you will call CreateObject (in VB) (Co)CreateInstance in VC++ (or even c#?), while to get an executing instance, you might want to call GetObject().
Getting the list of COM objects is not that easy (I guess not possible at all) because, as told earlier, a COM object is nothing else but a DLL: this means that the library will mainly load in the address space of each process which access is private. Even for out-process COM objects (opposite to in-process) which are object shared between many processes (i.e.: Excel is an out-of-process COM object: you don't load the DLL in your application's address space), they are loaded by a host (rpc.exe or a proprietary host)
Hope this helps
Serge
Related
I am working with an application GUI program and a console program, which call a COM object, which calls a worker DLL. Let’s call them ConsoleApp, GUIApp, COM DLL, and Worker DLL. The two Apps use CreateObject (VBasic) or GetProcID(C#) to activate the COM object and call it. In turn, the COM object calls the Worker DLL.
Problem: My goal is to register the COM DLL once, and then to continually develop the worker DLL without having to reregister the COM object all the time. Things work as expected when using the ConsoleApp. I can call it and see a debug message from the Worker DLL. When I change the message and recompile the worker, the next invocation of ConsoleApp shows the expected Mbox message.
But things do not work as expected with the GUIApp. To pick up any new worker DLL code, I must reregister the COM object (of course the GUIApp is not alive during re-registration). But that defeats the purpose of me trying to split the big COM+Worker DLL into two pieces to avoid re-registering the COM object all the time.
I have read many web pages (including here) on COM objects, but have not found answers that might work for my goal of having the registered COM object call a Worker DLL that can change during development.
Q. Is this the normal case that all DLLs referenced and called by a COM object are somehow bound to the COM object at registration time? (Answered above and below.)
Q. Is there any way for me to register the COM object once and have it call a DLL that I can work on in development without constant reregistering the COM (calling) object every time I change the Worker DLL code?
That's my ultimate goal if it is possible (and it seems to work as expected for the ConsoleApp).
UPDATE: RomanR suggested that I use ProcessExplorer to see which process is hanging on to the Worker DLL once GUIApp has been shut down. I could find the Worker DLL when GUIApp was alive but could not find it when GUIApp was shutdown. At the moment, the visible evidence is questioning my statement that the GUIApp never lets go of the Worker DLL. I will have to figure out a way of absolutely showing whether rebooting GUIApp picks up the new versions of Worker DLL.
The problem occurred because I registered the COM object direct from VStudio as part of the build (as Administrator). In the COM VStudio project, the reference properties for Worker.DLL specified Copy Local = True. Therefore, at the time of registration, the COM object was referencing the locally-copied version of Worker.DLL and not the future (later modified) copies of Worker.DLL that were stored elsewhere.
If I set Copy Local = False, I could register the COM object, but it would fail because it could not find the Worker.DLL at runtime.
The easiest solution was to 1) close the GUIApp to release the COM and Worker DLLs, 2) modify the Worker DLL with new code, 3) and copy the new Worker DLL into the COM project\bin\Debug folder where the Copy Local=True operation would put it. That way the registered COM object would pick up the most recent Worker DLL from the expected location.
Another solution (that I have not tried) is to modify the COM code to dynamically load and instantiate Worker.DLL from some dynamic location. That looks like a good approach too, although it does not give compile-time feedback on Worker DLL methods, etc.
I have written some code in VB that verifies that a particular port in the Windows Firewall is open, and opens one otherwise. The code uses references to three COM DLLs. I wrote a WindowsFirewall class, which Imports the primary namespace defined by the DLLs. Within members of the WindowsFirewall class I construct some of the types defined by the DLLs referenced. The following code isn't the entire class, but demonstrates what I am doing.
Imports NetFwTypeLib
Public Class WindowsFirewall
Public Shared Function IsFirewallEnabled as Boolean
Dim icfMgr As INetFwMgr
icfMgr = CType(System.Activator.CreateInstance(Type.GetTypeFromProgID("HNetCfg.FwMgr")), INetFwMgr)
Dim profile As INetFwProfile
profile = icfMgr.LocalPolicy.CurrentProfile
Dim fIsFirewallEnabled as Boolean
fIsFirewallEnabled = profile.FirewallEnabled
return fIsFirewallEnabled
End Function
End Class
I do not reference COM DLLs very often. I have read that unmanaged code may not be cleaned up by the garbage collector and I would like to know how to make sure that I have not introduced any memory leaks. Please tell me (a) if I have introduced a memory leak, and (b) how I may clean it up.
(My theory is that the icfMgr and profile objects do allocate memory that remains unreleased until after the application closes. I am hopeful that setting their references equal to nothing will mark them for garbage collection, since I can find no other way to dispose of them. Neither one implements IDisposable, and neither contains a Finalize method. I suspect they may not even be relevant here, and that both of those methods of releasing memory only apply to .Net types.)
Not sure what to recommend here. There is most definitely no memory leak here, the garbage collector releases COM reference counts. COM objects are not disposable but you can release them early with Marshal.ReleaseComObject(). The trouble with doing this explicitly is that it is normally very hard to track interface references.
In your code snippet for example, calling ReleaseComObject on the icfMgr won't have any effect. There's a hidden reference through the LocalPolicy member that will keep the interface reference alive. You'd have to call ReleaseComObject on that hidden reference as well.
I would not recommend making this a practice at all. Getting it wrong produces hard to diagnose failure, you're essentially back to the bad old days of explicit memory management. But it is somewhat manageable in your specific example.
You are exactly right: unmanaged code cannot be managed and thus needs to be managed by hand: disposed of. However, this greatly depends on what you are doing, but in many cases, it is sufficient to wrap the object instantiation around a Using-block. This only works if you use an object that implements IDisposable.
However, the way you currently create an instance of a COM object, you will not have the possibility to clean up easily. It depends on the object. When it doesn't need cleaning up (check the destructor of FwMgr), it doesn't need disposing either. However, most COM objects do need disposal.
So, how to add the IDisposable interface to a COM object that doesn't natively support it? It's a bit of work to do so manually, but you should create a wrapper .NET assembly. Luckily, the work has been taken out of our hands and Microsoft has created some tools and guidelines.
Some of this information is covered here too. You may want to also look up WeakReference as an alternative.
Note that COM and .NET do not talk well together, but they do talk. An excellent reference is .NET and COM The Complete Interoperability Guide by Don Box, SAMS Publishing.
EDIT:
In answer to your "memory leak" question: it is impossible to tell whether you introduced a memory leak, and how big it is. It depends on how often you call your COM object. Call it once per running process? Don't worry too much. Call it hundredths of times in an inner loop? Be very careful. Want to know for sure? Lookup the original documentation or source: if it releases handles, memory or other resources when it is destructed, then yes, you introduced a leak.
I have a VB6 DLL embedded in some ASP pages. The DLL hits a Codebase database, an obsure and obsolete database engine (a dialect/variation on dBase) that virtually no-one has even heard of. It takes Codebase nearly a second to initialise a new connection, which is unacceptably slow and so I've created a connection pool, managed by a VB class. The single instance of this class is created at the start of a VB module, i.e.:
Private m_codebaseManager As New CodebaseManager
My problem is that periodically the class initialization method is called again completely wrecking my pooling class and I've no idea why. Terminate does not fire and there's no sign of any crash occurring, so why on earth is initialize called? My understanding is that data in non-class modules persists for the lifetime of the DLL. Is that correct and if not, under what circumstances does a module 'restart'?
I would recommend removing the "New" from the variable declaration. Declaring a variable "As New" causes it to be checked every time it is referenced, and if set to Nothing a new instance of your CodebaseManager will be created.
A better solution would be to declare your variable like this:
Private m_codebaseManager As CodebaseManager
and then explicitly set it to a new instance when your application starts:
Set m_codebaseManager = New CodebaseManager
This means you can be sure you won't be creating any unintentional new instances of CodebaseManager. You'll probably then still have a bug but at least it will be an "Object or with block variable not set" error which you should be able to easily fix.
My understanding is that data in non-class modules persists for the lifetime of the DLL. Is that correct and if not, under what circumstances does a module 'restart'?
Sort of. Global state (module public/private vars) are apartment specific and is stored in TLS slots. VB6 supports apartment threading only, so each thread gets a "fresh" copy of the global state. Because ASP environment is multi-threaded so each thread gets a separate DB connection "pool".
If you need a real global state you have to use Application object to store it. If you put apartment threaded objects there (like VB6 ones) these can serialize you multi-threaded ASP environment and degrade performance. Use ADO objects or Dictionary objects or anything you are certain is free threaded.
Btw, you can let COM+ do the object/connection pooling for you. If OLEDB provider is a better one it can do connection pooling internally too (SQLOLEDB for MSSQL is an example).
But it's a DLL and not an ActiveX exe, so there's no Main() function and nowhere for the 'Set m_codebaseManager = New CodebaseManager' line to go except in global scope.
Is there possible to create a COM-instance in it's own, dedicated, host-process?
I guess some background is needed.
We have an end-user client which has it's central logical components inside an singleton-COM object. (Not propper singleton, but it uses global variables internally, so it would fail.) So that there should be only one instance per exe-file. Convenient while making the client.
However, I should now make a "client-simulator" to test the server-side. I therefore which to make 20 instances of the client-component.
If I could make each instance instanciate in its own exe-host, then the singleton-issue would be handled.
Regards
Leif
I have been struggling with this problem for a few days. I finally found a solution that works. My COM object is written using ATL, so my code snippet will be geared toward that, but the technical solution should be clear. It all hinges on how the class objects are registered. The REGCLS_SINGLEUSE flag is the key. I now have separate processes for each object instance.
In the ATL module, override the RegisterClassObjects() function as follows:
HRESULT RegisterClassObjects(DWORD dwClsContext, DWORD dwFlags) throw()
{
return base::RegisterClassObjects(CLSCTX_LOCAL_SERVER, REGCLS_SUSPENDED | REGCLS_SINGLEUSE);
}
From MSDN regarding REGCLS_SINGLEUSE:
REGCLS_SINGLEUSE
After an application is connected to a class object with
CoGetClassObject, the class object is removed from public view so that
no other applications can connect to it. This value is commonly used
for single document interface (SDI) applications. Specifying this
value does not affect the responsibility of the object application to
call CoRevokeClassObject; it must always call CoRevokeClassObject when
it is finished with an object class.
My theory is that because the registration was removed from public view, it causes a new process to be created for the subsequent instantiations.
This other question mentioned a description of how to use DLLHost as a surrogate process:
http://support.microsoft.com/kb/198891
I've never tried this myself, and I don't know off-hand if you can specify flags for the factories (which control if surrogates can be reused for multiple objects), but maybe you can tweak that via DCOMCNFG or OLEVIEW.
My COM days are long gone, but as far as I remember, there's no built-in way to do that.
It might be easier to rewrite your code so it supports multiple instances than to go the one-process-per-instance route with COM, but here's what you could do:
Use thread-local storage for your global variables and write another CoClass, where each instance owns its own thread through which accesses to the class with the global variables are marshaled. This would at least allow you to avoid the performance impact of DCOM.
Write your own out-of-process exe server (similar to windows' DllHost.exe) to host your COM instances. This requires IPC (Inter-Process Communication), so you either have to code something yourself that marshals calls to the external process or use DCOM (presuming your COM object implements IDispatch)
I searched hard, but was unable to grasp the whole idea. Can anyone tell me:
What COM actually is?
How do GUIDs work, and how are they used by COM?
How does COM resolve the issues of different DLL versions.
Or at least, point me to a good article somewhere that explains these concepts?
Thanks!
COM is "Component Object Model". It is one of the first technologies designed to allow "binary reuse" of components... Originally, it was the rewrite of what was, in Microsoft Office circa 1988-1992 time frame, referred to as Dynamic Data Exchange (DDE), a technology designed to allow the various Office applications to talk to one another. The first attempt to rewrite it was called OLE-Automation (Object Linking and Embedding). But when they got done they renamed it to COM.
How it works:
Essentially, before COM, when a client component wanted to use a component (written as a C++ library), it had to be compiled WITH the library, so it could know exactly how many bytes into the compiled binary file to find each method or function call.
With COM, there is a defined mechanism as to how these methods will be structured, and then the compiler produces a separate file (called a type library or an Interface Definition Language (IDL) file, that contains all this function offset data.
Then, as a user of the component, you have to "register" it, which writes all this information (Keyed off of GUIDs) into the OS Registry, where any client app can access it, and by reading the data from the registry, it can know where in the binary file to find each method or class entry point.
Your question is a little large for a full explanation here. A quick high-level introduction to COM can be found in the book Understanding ActiveX and OLE. A more detailed but still introductory introduction is Inside COM. The best book on the subject is Don Box's Essential COM.
A couple of quick answers:
COM is a binary interface standard for objects. It allows various programs to write to interfaces without all having to have been written in the same langauge with the same compiler. There are also related services available.
GUIDs are globally unique numbers that COM uses to identify interfaces.
COM doesn't resolve different DLL version problems. It only allows a single DLL to be registered for each GUID.
COM enables reusable software. Like building blocks, you can create COM objects (or now Assemblies in .NET) to provide functionality to a larger piece of software. I have used COM to provide DB integration for Excel and MS BizTalk. Software like MS BizTalk use COM/Assemblies to extend the processing capabilities of a standard process; you can insert a COM into the message workflow to do more processing than is implemented by Microsoft. COM also allows use of Component Services providing built in object pooling, security, and control interface.
Wikipedia has a good definition of GUID. Note that Microsoft has a formatting that is not necessarly used in the rest of development community.
COM by itself does not resolve DLL version issues. It enables you to extend software incrementally if you use the COM versioning capability. So if you have an application that uses a COM to convert XML to Text (for example) and you want to enhance, you can create a new version (2.0) which you can roll-out slowly as you update the source application to use the new COM. This way you could (if need be) have a switch statement that can still use the old COM if required by system limitations, or use the new one (they would be different DLLs).
COM is a lot of different things. I recommend Don Box's book, Essential COM as a good way to learn.
At a bare minimum, a COM object is an object that exposes a single interface, IUnknown. This interface has 3 methods, AddRef, Release, and QueryInterface. AddRef/Release enables the object to be reference counted, and automatically deleted when the last reference is released. QueryInterface allows you to interrogate the object for other interfaces it supports.
Most COM objects are discoverable. They are registered in the registry under HKEY_CLASSES_ROOT with an identifying GUID, called a CLSID (class ID). This enables you to call CoCreateInstance to create an instance of a registered object if you know a GUID. You can also query the registry via a COM API for the CLSID that backs a ProgId (program id), which is a string that identifies the object.
Many COM objects have typelibs that specify the interfaces and methods the object supports, as well as IDispatch which has a method, Invoke, that allows you to dynamically call methods on the object. This enables the object to be used from scripting languages that don't support strong typing.
Some objects support being run in a different process, on a different thread, or on a different machine. COM supports marshalling for these types of objects. If possible, a standard marshaller can use the object's typelib to marshal calls to the object, but custom marshallers can be provided as well.
And there's a whole lot more to COM objects, I'm barely scratching the surface.
10,000 foot view:
COM is the communication mechanism for software components. Example, you can interact with COM interfaces (COM interop in .NET) to use functionality not exposed through a common interface (.NET assembly).
GUIDs are explained fairly decent on Wikipedia http://en.wikipedia.org/wiki/Globally_Unique_Identifier
I always understood LIB files to be object files for the C++ linker. They contain the code for all objects in a cpp file. The compiler optimizes when it links disregarding portions of the object file that it doesn't need.
Someone please clarify as I am sure I butchered some of this.
COM is Microsoft's Component Object Model, a binary-compatible interface for programs written in various languages to interoperate with each other. It is the "evolutionary step" between the OLE and .NET technologies.
If you want to learn about COM from the C++ perspective, take a look at Don Box's Essential COM, or ATL Internals by Rector and Sells.
The group microsoft.public.vc.atl is probably the best place to ask questions you can't get answers for here. It's primarily an ATL newsgroup, but it seems to be the newsgroup with the most traffic for general COM questions as well. (just be prepared for the usual newsgroup curtness & impatience)
COM is a method to develop software components, small binary exe, that provides services for applications, OS and other components. Developing custom COM comnponent is like developing Object oriented API. GUID is a Global unique ID and used to identify a COM component uniquely.
You can refer a very good book by Dale Rogerson for more details. Inside COM