I am using pywin32 to register a COM object. The COM object get registered and it is avaialable in the registry editor at Computer\HKEY_CLASSES_ROOT\CLSID{B7B60366-B784-451F-BD6A-E7E733DB4E63}.
The problem is that the path in InProc32 includes only pythoncom37.dll. The only way can make the object work is to rename the inproc folder, so that it searches for LocalServer by default.
I believe several problems in the behavior of this object are connected to it not being ran as inproc, hence I really want to get it to run as inproc.
Any Ideas why this is the case? What can I do to change it?
Related
I've been trying to implement following scenario:
Application [C++] uses CoCreateInstance on registered COM class (CReg/Reg.dll)
CReg class uses CoCreateInstance on regfree/SxS COM class (CFree/Free.dll).
CoCreateInstance returns REGDB_E_CLASSNOTREG.
Problem doesn't seem to be with manifests, because if I try to instantiate CFree directly via application, object is created with no problem.
I have checked and scenario above triggers Activation Context of CReg (I have checked with sxstrace) and even manifest of the CFree is loaded successfully (!) which should effect in correct regfree COM. If I change manifest of the CFree then Activation Contexts fails (which I believe is proof for me that it was correctly triggered and loaded before the change).
Is scenario with using registered COM [CReg] not possible to access CFree object? If it is possible, are there some special work in order to load it properly?
EDIT
With Joe's help, we worked out that the problem is where Free.dll is located.
Main application is (for example) in C:\Proj\App, both Reg.dll and Free.dll are in C:\Proj\Libs. Is there possibility to load regfree Free.dll which is in different location than application? Problem is that I can't place it in application directory or in application child directory (it has to be in external location).
I have tried to use ISOLATION_AWARE_ENABLED preprocessor definition on Reg.dll project, to trigger Activation context from Reg.dll directory. Manifest from Free.dll is loaded properly (sxstrace logs that) but CoCreateInstance call is still returning REGDB_E_CLASSNOTREG. This blog article points that it may be possible with this definition (but is not giving definite answer on this matter).
Anyone can help me solve this problem or at least point to the documentation that may give me an answer, whether it is possible or not, to load regfree dll from an external location?
I have inherited a classic ASP application and looking through the code I see a custom COM object reference
Server.CreateObject("DBaseManager.Recordset")
Now, unfortunately looking through to source code there are no .dlls provided so therefore the COM dll must still exist on the live server.
In order to get the code working on my Dev Server I need to get a copy of the dll so I can register it on my Dev server.
Does anyone have any recommendations about how I might be able to find the COM dll that makes the above call?
Thanks and best wishes
Mark
Registry search - under HKEY_CLASSES_ROOT, locate the DBaseManager.Recordset key. Under that key, there should be a CLSID key, with a default value containing a guid.
Now, search for that guid under HKEY_CLASSES_ROOT\CLSID. There should be a subkey under that key called InprocServer32 (if it's an in-process COM library), which in turn should have a default value giving the path to the DLL.
Of course, if the DLL in question is part of a larger product or SDK, merely installing the dll on your dev server may not be sufficient. You may have to locate and install the whole product/SDK in order for it to actually work on another machine.
I have a .NET COM DLL that I want to unregister. I do:
regasm.exe /u ConfigManager.dll
When I look with COM-ole viewer app I still see in type libraries section an entry for ConfigManager( specifies the path to ConfigManager.tlb there). How can I make sure I deregister for good any entries of ConfigManager.dll COM ?
I ask this because I have a nasty error where it seems that ConfigManager clients do not see some types from ConfigManager and want to make sure I deregister and register again ConfigManager
You just need a typelib registration utility. TypeLibs are not specific to .NET so you can find these kinds of ones anywhere.
Here's a simple one:
http://www.vbaccelerator.com/home/vb/utilities/Type_Library_Registration_Utility/VB6_Register_TypeLib_Utility.asp
I prefer to use TlbExp instead of the /tlb option of RegAsm to get a typlelib without automagically registering it. That way I can explicitly register (or unregesiter) the typelib.
I was using an application and it was working perfect. After some months of not using it, I tried to run it and it doesn't work. It shows a message box saying that it cannot instance a COM object.
Do any know how to track errors in COM objects?
You can use ProcessMonitor and try to find the registry key that may be incorrect.
The other option is to use http://www.moduleanalyzer.com, it intercepts CoCreateInstance showing all created COM objects and the return values.
Run Depends tool on COM object DLL to verify it has all the necessary dlls, re-register the COM dll/exe.
Any HRESULTS from debugging/logs? Any changes in apartment models?
You cannot change the apartment type once you've set one. So if the object cannot use one of the models and you try to CoCreate it, it will fail. That's why you never call CoInit from inside DLL main thread.
i worte a dll of com object
i registered it
where can i find this dll now in my machine
(when we register dll to where the nachine copy the dll)
and more question if i try to use this com object in powerShell everything thong work well
if i try to use it in javaScript i get exception
any idea??? why??
Registering a COM DLL does not copy the DLL. It just adds registry keys which COM uses to locate your DLL. For example, for every class a key "HKEY_CLASSES_ROOT\CLSID{your class ID}" is added. A lot of the time the path to your DLL is stored as the default value in a subkey such as "InprocServer32" (actual name depends on how your class is configured to be activated).
JavaScript cannot access COM objects, or even local files for that matter, because JavaScript is executed inside an isolated environment set up for security reasons.
As Richard Walters stated, registering a COM object does not copy it anywhere. Usually I am lazy and rather than looking up long GUIDs in REGEDIT, I search for the DLL's name using the Find feature.
Since you mentioned PowerShell, can I assume you are trying to use Javascript within the Windows Script Host? If so, knowing what the exception is might help. An example on how to do this though:
var xml = new ActiveXObject("Microsoft.XMLDOM");
xml.load("foo.xml");
Of course replace Microsoft.XMLDOM with information from your COM object.
The equivalent PowerShell would be:
$xml = New-Object -ComObject Microsoft.XMLDOM
$xml.load("foo.xml")