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.
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 an MFC application that exposes a bunch of OLE objects for the application, and open documents.
I can connect to the server using the GUID of the application class (e.g.: in ruby for windows: WIN23OLE.new('{12345678-1234-1234-1234-12345678}')) but when I try to connect using the class name WIN32OLE.new('MyApp.Application'), it always fails with "Invalid Class String" error (HRESULT error code:0x800401f3). The same thing happens
There are no errors returned by the OLE initialisation in the MFC app, and once a connection is made by GUID, then it works fine.
I'm just really curious why the class string approach isn't working. Any ideas?
The class string is called a ProgID (short for programmatic ID), and it's really just a human-readable version of the ClassID. ProgIDs are stored in the registry under HKEY_CLASSES_ROOT, for example picking one at random from my registry:
HKEY_CLASSES_ROOT\Microsoft.XMLDOM
Under this key there is another key called CLSID:
HKEY_CLASSES_ROOT\Microsoft.XMLDOM\CLSID
And inside that key is a REG_SZ value which contains the ClassID:
{2933BF90-7B36-11D2-B20E-00C04F983E60}
So basically the way it works is that COM is going to try to find the CLSID in the registry under the specified ProgID. I'm guessing it's not there or it's inaccessible somehow. If you want to figure it out for sure, crack open REGEDIT.EXE and take a look to see if the expected registry settings are there. If they aren't, there's your answer about why it's not working (for some reason the registration of the COM component isn't creating the ProgID keys).
If the settings are there, I would recommend running Process Monitor (sysinternals.com) and set up some registry filters to see what is happening when the registry is scanned for that ProgID.
Here's a little more info about ProgIDs:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd542719(v=vs.85).aspx
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 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")
I have written a thumbnail provider following the interfaces specified on MSDN. However, I have been unable to figure out how to register it in a way that Vista actually calls into it. Has anyone gotten a thumbnail provider working for Vista? Sample code or links would be especially helpful.
The documented way to register your IThumbnailProvider is to create a registry entry at HKCR\.ext\ShellEx\{E357FCCD-A995-4576-B01F-234630154E96} and set the (Default) string value to the GUID of your IThumbnailProvider.
Your assembly will need to be registered first. If using .NET, that means you will need to use the RegAsm.exe tool to register it.
There is sample code available here: http://www.benryves.com/?mode=filtered&single_post=3189294