I'm writing a small DLL component that needs to access two third party components to combine data, one of which is 32 bit only and the other is 64 bit only. Both are registered with a TypeLib and are Automation compatible, so marshalling should not be an issue.
If I understood the documentation correctly, then there is no way to force loading in a surrogate unless the component also has an AppID and the DllSurrogate key; since both are third party components, I'm somewhat reluctant to modify their registration.
Is there a way to activate an object in a component without an AppID in a surrogate process from a DLL component that ideally does not have any extra dependencies, or can anyone explain to me why this would be a bad idea?
Yes, you can load a (for example) 32-bit only DLL in a surrogate, and access it from a 64-bit process, in the following manner. This will work provided there is a marshaller available, which there generally will be for a component with a typelib because they usually use the standard marshaller. It will not work if the object requries a custom prox/stub because 64 bit versions won't exist, or you wouldn't have this problem in the first place.
First you need an AppID. If the DLL already has an AppID, you should use that. You can find out by checking under the CLSID key for the CoClass you are interested in.
The example used here is the Capicom.HashedData and Capicom.EncryptedData classes. Capicom is 32-bit only.
You should use the 32-bit version of Regedit to do this, as it is a 32-bit component. If you have a 64-bit component you want to access from 32-bits, use the other one. (This is because of the registry virtualisation for the 32-bit compatibility layer- using the the matching bitness version of regedit takes care of this issue for you, by making sure you edit the correct virtualised version of the registry).
Windows Registry Editor Version 5.00
;;; Capicom AppID - just using the Capicom.EncryptedData CLSID
;;; Use default surrogate = empty string
[HKEY_CLASSES_ROOT\AppID\{A440BD76-CFE1-4D46-AB1F-15F238437A3D}]
"DllSurrogate"=""
;;; Capicom.EncryptedData
[HKEY_CLASSES_ROOT\CLSID\{A440BD76-CFE1-4D46-AB1F-15F238437A3D}]
AppID="{A440BD76-CFE1-4D46-AB1F-15F238437A3D}"
;;; Capicom.HashedData - use same AppID for all!!!!!
[HKEY_CLASSES_ROOT\CLSID\{CE32ABF6-475D-41F6-BF82-D27F03E3D38B}]
AppID="{A440BD76-CFE1-4D46-AB1F-15F238437A3D}"
Save to a myComponent-dllhost.reg file, and away you go.
c:\windows\sysWow64\regedit.exe "myComponent-dllhost.reg"
You should now be able to access Capicom.HashedData and Capicom.EncryptedData from 64-bit script/COM hosts.
Notes:
This only works for basic OLE Automation types. Any object compatible with Windows Scripting Host scripts in VBScript or JavaScript should be OK.
You only have to add the AppID to directly creatable objects. That's basically those with an InprocServer32 entry. Objects which are generated from factories or which are only available as child objects do not have to have an AppID added.
If there is already an AppID all you need to do is add the empty-string "DllSurrogate" entry. That's it!
this will NOT affect normal clients of the DLL. As long as the bit-ness matches, they will continue to be loaded in-process as before. The only difference it will make is that it will become possible to instantiate it out-of-process from a client of a different bitness.
Related
When I register a .NET assembly enabled for COM interop using the REGASM tool, the tool creates a separate registry key for each component version. For example, I get:
HKEY_CLASSES_ROOT\CLSID\{myCLSID}\InprocServer32\1.0.0.0
HKEY_CLASSES_ROOT\CLSID\{myCLSID}\InprocServer32\1.1.0.0
etc.
Each of these registry contains roughly the same structure values as it is under HKEY_CLASSES_ROOT\CLSID{}\InprocServer32, except that the entries point to different locations, depending on the component version. The HKEY_CLASSES_ROOT\CLSID{myCLSID}\InprocServer32 apparently contains the latest registered version, and that's what COM consumers will normally use, of course, and they ignore the rest.
This structure apparently allows different versions of the component coexist on the same computer (I know it is against the originally specified COM rules). I would like to use it, but I could not find any documentation about it anywhere in the Microsoft documentation or Googling for it. Does anybody know? I am looking for something like CoCreateInstance/CoCreateInstanceEx with the version specifier.
Thanks
My setup that I created using Inno setup mainly registers some DLLs.
Now I would like to add some conditional behavior. A certain path shall be taken if another DLL is installed/registered on the system.
Is it possible to use Inno setup to detect whether a certain DLL is registered in Windows?
The DLL I want to check is not from me. The only thing I know is its name, but I don't know about any COM objects or CLSIDs.
There's nothing like "DLL registration" as such. Only COM objects are registered. So you have to know, what COM objects the DLL does register; and then check for those.
Only other thing you can do, is it to traverse whole HKEY_CLASSES_ROOT looking for an entry with the DLL. But that may take tens of seconds even on a fast machine.
I have created a basic COM DLL with ATL on VS2012. It's called testCOM.dll and it only has one class called CSimpleObj. CSimpleObj has just one method called addValues which adds two values.
I've registered the DLL with Windows 7 64-bit. In VBA, I manually add a reference to the DLL and the below code works properly
Dim Obj As New testCOMLib.SimpleObj
MsgBox Obj.addValues(1,2)
And it give a message with number 3.
Now If I run the vbs which includes:
Dim Obj
Set Obj = CreateObject("testCOMLib.SimpleObj")
It constantly gives an error and is not able to create the object. But if I use the "Excel.Application" ProgID (as an example) for the CreateObject method, it works fine.
I think there is an issue with registering the DLL. I've checked the registry, and the keys for the COM and the type library is already there.
What should I do?
There are three basic requirements to get your COM server to be usable from VBScript:
You need to implement IDispatch so late binding is supported. Not usually a problem with ATL, it implements it by default when you use the wizards.
Your registry script (.rgs) must write the ProgId to the registry. Notable is that you didn't report finding it (look for HKCR\testCOMLib.SimpleObj with Regedit.exe to verify). Its CLSID subkey must match the CLSID in the registry so COM can find your DLL. The ATL Simple Object wizard has a trap, it fills in all the fields when you type the short name. Except for the ProgID field. So very easy to forget.
On the 64-bit version of Windows, you'll execute the 64-bit version of cscript.exe by default. It will not be able to find your 32-bit COM server. You'll need to either build the x64 version of your server or you'll need to use the 32-bit version of cscript.exe, located in c:\windows\syswow64. Not usually a problem with VBA since it tends to be used from a 32-bit version of Office.
The SysInternals' Process Monitor utility is very useful to diagnose these kind of problems. You'll see cscript.exe searching the registry for the keys that your server registered. And probably not finding them, you were however not explicit enough about actual error message you got.
I have a vb6 program that needs to use MSOLAP80.dll to display its pivot tables properly. But because MSOLAP90.dll has some compatibility issues with this I cannot use MSOLAP90.dll and still have the pivot tables display.
I have registered MSOLAP90.dll and then registered MSOLAP80.dll again and everything seems to be fine. I however don't know if both are actually registered or if MSOLAP80.dll is the only one registered, because I have no reference point as to what is new in MSOLAP90.dll. Is it possible that both are registered and the program is just using MSOLAP80.dll and if there are programs that need MSOLAP90.dll then it will know to use that one?
I guess I am just confused about how registering DLL's work and if it is possible to have both of these registered at the same time. Can somebody help with an explanation?
If you want to know for sure which one is registered, you can:
Look at the References dialogue for a type library which matches your DLLs' paths.
Open up RegEdit, and search for MSOLAP80.DLL or MSOLAP90.DLL (uncheck "Match whole string only").
If you find references for both DLLs, then you are safe because you can bind to a specific version. If you find a reference to the wrong DLL, then unregister the wrong one, and register the right one.
COM originall only allowed one version of a set of CLSIDs (which uniquely identify classes), IIDs (which uniquely identify classes' interfaces) at any one time. It is possible to have more than one reference to a LIBID (which identifies a type library - a resource embedded in the DLLL) but they have to have different versions.
From Windows XP onwards, it became possible to do side by side DLL access in which an executable can access a specific version of a DLL, overriding the value in the registry. You need to embed or have a .manifest file in the same folder as the EXE file.
Unfortunately, the documentation for this seems to have disappeared from MSDN, and is only referred to by a couple of Knowledge Base articles:
http://support.microsoft.com/kb/828629
http://support.microsoft.com/kb/843524
I have a native app that has an .OCX file that needs to be registered for it to be used in a .NET application.
Now currently there's different versions of this .OCX on the machine. Can someone please explain how this can affect the registration of this new (updated) .OCX file registration?
And how does my .NET app know which object to create from which .OCX file?
COM servers are required to change their CLSID guids if their interfaces are no longer compatible. So if your supplier did it right, you should be able to register both of them and get the right one when you use the right reference in your project.
Like any rule, this one got violated often and is presumably the reason you started this question in the first place. The back-up plan is to use registry-free COM, you write a manifest and add it to your program so it always uses the local copy of the COM server DLL instead of the one that was registered. Find out how to do this by googling "regfree COM", I see many relevant and useful hits at the top.
I believe COM class registrations include the entire path to the "server" providing the COM component. If the two versions of the .OCX have different class GUIDs, then there should be no issues.