I need to know CLSID of COM object which I just ran via CreateObject("xxx.xxx") how can I get it?
TIA!
Rafal
I don't think you can get that information directly from VB itself (e.g., as a side-effect or secondary result of calling CreateObject), but you can read the registry entry at HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xxx.xxx and then look at its CLSID key.
Related
How can i solve the next problem that i have. Im using WCF and it reference a COM.
Creating an instance of the COM component with CLSID {...} from the IClassFactory failed due to the following error: fffffdf8f Exception from HRESULT:0XFFFFFDF8F
Obviously the CLSID that appears is my COM. My COM is compiled in Power Builder 11.5.
It appears in production environment after a long time of using but at the beginning of the day it work perfectly.
Do you think I should use System.Runtime.InteropServices.Marshal.FinalReleaseComObject(COM)?
DllRegisterServer is called, when Windows or OLE wants me to register my classes under HKEY_CLASSES_ROOT\CLSID. But I don't understand why this function has to be implemented, because when Windows/OLE can make calls to my DLL, then my classes are already registered with their CLSIDs and their path to the correct DLL. Can somebody tell me, what I am misunderstanding?
You are confounding the chicken and the egg. In order for COM to help a client app to create objects and marshal calls, it needs to know where your COM server is located. The client app just uses a number, a GUID, to tell COM what object it needs. The mapping from a GUID to code in an executable file requires COM to know where that file is located first. And, if necessary, how to marshal a call on an interface from one apartment to another.
It is registering the server that provides COM with that knowledge. It writes keys in the registry that COM uses to find the file back. Like the CLSID key, its InProcServer32 sub-key provides the path to the file. Etcetera. Or the manifest embedded in the client app if it chooses to use reg-free COM.
Observing this with SysInternals' Process Monitor can provide a lot of insight. You'll see what DllRegisterServer() does and how a client app uses those keys.
For the peoples wondering about Title of Question
Example of COM object is Dynamic Context Menu ( which would be a DLL)
to register it-
First Make a Random GUID under HKEY_CLASSES_ROOT
Under That GUID make key named "InProcServer32"
set value of this key as full path of your DLL
This is called Manual Registration
people's with no knowledge of registry editing should also be able to register your dll too.
for that, you should write codes to make these GUIDS and InprocServer32 keys etc programatically Under the DLLRegisterServer() Function in your DLL
so that , people with no knoledge of registry editing will be able to type -
regsvr32.exe "full path of your DLL"
in command prompt for registring your DLL
when they type that command, regsvr32.exe will do nothing but call that DLLRegisterServer() in your DLL
and by calling this function, codes of writing registry keys such as making random GUID and InprocServer32 keys will be Executed ( which you have written )
so registry entries will be made and that is called Registration.
so , according to me regsvr32.exe was just created for the people who have less knowledge of how to edit registry.
We moved to .net 4 and the work with exchange doesnt work anymore.
I'm using interop.cdo dll and when doing sessionclass I'm getting an exception -
retrieving the com class factory for component with CLSID faile due to the following error: class not registered.
Is there a way to fix this with this dll or should I replace all the work with exchange?
If I do - what is the best way? I cant seem to find information about it.
Thanks
When I register my .NET Assembly with regasm.exe the registry key
HKEY_CLASSES_ROOT\CLSID{111E32AD-4BF8-495F-AB4D-6C61BD463EA4}\InprocServer32
is set to "mscoree.dll".
However, I am trying to mimic an existing COM-Server that was written in C. When registering this old COM-server the InprocServer32 is set to the full path to this component.
Unfortunately the existing system (a plugin host that I can not change) reads and use this value - an is confused by the "mscoree.dll" value.
My solution might be to patch this registry entry manually - but I would like to understand why regasm writes "mscoree.dll" into InprocServer32 .
The explanation is quite easy. When you use a native (unmanaged) COM server in-proc, it is loaded into the consumer process and the consumer process directly calls its functions.
This can't work that easily with a managed code COM-exposed assembly. In case of managed code an intermediate layer is needed that performs the managed/unmanaged interaction. mscoree.dll acts as this intermediate layer. So when the consumer calls CoCreateInstance() mscoree.dll is loaded and emulates the COM server by loading the COM-exposed assembly managed code and forwardind all calls to the latter.
I'm making some archeology, dealing with COM+
I managed to enlist a simple COM dll as a COM+ component, so far so good.
So I've got this 'foobar' com+ component, with it's interface, and the method I'd like to call.
My question is then rally simple: how am I supposed to make a call to this component?
Any .NET or VB6 answer is accepted (I have to check the component is OK, don't care about the client)
Thanks
Edit (06/03/09): Well, I'm confused. so as to work properly, my COM+ component needs it's dll to be registered. Why not? But then, how to be sure I'm making a COM+ call, and not a COM one?
Simplest VB.NET code snippet possible:
Dim myCom As Object
myCom = CreateObject("MyCom.ProgId")
myCom.Method(parms)
You need to replace "MyCom.ProgId" with the actual ProgId of your component - you can get this from the General tab of the properties of the component in the Component Services admin tool (sounds like you've already got a grasp of that)
myCom.Method(parms)
is simply a place holder for whatever method you want to invoke, with the parameters that method takes.
Here's a link to some examples of the VB.NET syntax:
http://msdn.microsoft.com/library/de...eateObject.asp
http://www.samspublishing.com/articl...le.asp?p=25857
http://msdn.microsoft.com/library/en...asp?frame=true
If all you are wanting is to check the component responds when called then use a quick VBScript rather than building something in VB6/VB.NET.
Dim o : Set o = CreateObject("Lib.Class")
o.YourMethod "someParam"
Watch your COM+ app in Component Services to see if the class requested spins up.
Adam's code in VB6 is similar:
Dim myCom As Object
Set myCom = CreateObject("MyCom.ProgId")
myCom.Method(parms
This example is late bound and carries with it some performance penalty.
You could call your method in an early bound manner, which avoids the penalty. In either VB6 or VB.NET, just add the COM+ dll to your references and you can call the object in this manner:
VB6
dim myCom as MyCom.ProgId
set myCom = new MyCom.ProgId
myCom.Method
VB.NET
dim myCom as new MyCom.ProgId
myCom.Method(...)
When you want to use COM+ for RMI then use this
Dim o As Object
Set o = CreateObject("Lib.Class", "MYSERVER")
where MYSERVER is the machine name where COM+ application is created and your DLL registered. Subsequently
o.YourMethod "someParam"
will be invoked remotely. If you are using only automation compatible interfaces, COM+ will successfully create a proxy for the RMI. Otherwise you'll need to provide the typelib on the client machine. This can be a separate TLB or the DLL itself.