I want to use reg-free com so that I don't have to register my legacy com component. However, I would like to be able to put the com dll in a location which is not in or below the directory of the client exe, e.g. ....\lib. I'm not able to do this in the server manifest file as it doesn't allow relative or absolute paths.
Does anyone know if there is a way round this?
UPDATE:
I only found relative paths to work on XP. However, I can use absolute paths on Windows Server 2008 using the Activation Context API so that's cool. My problem now is that my COM component has a static dependency on a managed database driver but currently it's not finding it. From what I've read about manifest files I hoped I could simply add another element to the COM reg-free manifest pointing at this dll as it is in the same directory as the COM dll but I can't get it to work. So, in summary, I have an exe in one directory which uses Activation Context API to reference a COM manifest/dll in another directory (that is not a subdirectory of the exe directory) which it finds and loads correctly. But I also have a managed database driver dll in the same directory as the COM dll and I want to know how I can get this to load using manifest files - if it's possible.
I've achieved this by running the exe with the parent directory as the current directory.
i.e with this folder structure
parentdir/
parentdir/myapp/
parentdir/somedependency/
Then with "parentdir" as the current directory, you can run your exe as
".\myapp\myapp.exe"
and myapp.exe.manifest can contain a reference to something in "somedependency" as
<file name=".\somedependency\somecomassembly.dll" />
This works on Windows Server
Related
The process executed with the extension does not find the path to the referenced dll.
It was normally used when it was executed with ".exe".
However, after running with the extension registered in the registry, trying to use the dll results in an error that the dll file cannot be found.
If you look at the content of the exception that occurred, the dll in the path of "C:\myfolder\myDll.dll" try to find to "c:\Windows\system32\myDll.dll".
How do I do anything other than put it in the System folder to ensure that the extension-enabled process recognizes the path in the dll ?
It is not possible to put it in the system folder, so another method is needed.
p.s ) When i open a process by right-clicking an icon in the taskbar while the process is floating, the newly opened process also generates the same invalid dll path error.
I fixed it.
it cause that "System.Environment.CurrentDirectory" and "AppDomain.CurrentDomain.BaseDirectory" were different.
so when Application start, Check each directory and change it if it is different.
my case in WPF, System.Environment.CurrentDirectory was Windows System folder.
I am using heat to harvest the COM dll and tlb files (let's call them MyLib.*, developed in VB.NET) to do the COM registration. Everything was working fine, when I install MyLib.dll and MyLib.tlb into my application's installation folder, i.e., INSTALLDIR. However, since we want to allow different versions of our SW to be installed on the same machine, and if they are using the same version of COM component, only one copy of the dll (I think each version of our SW should have its own tlb, please correct me if I am wrong) should be installed, we now want to install MyLib.dll into another folder, specifically PROGRAM_FILES\Common Files\SHARED_FOLDER_NAME, so now if one version of our SW is uninstalled, the MyLib.dll will not be removed and can still be used by other versions.
But here comes the problem: my COM registration is just simply not working any more after I install this dll into this another folder, and it keeps saying that can't find file specified when I am calling the COM function which indicates registration failure. In the WIX installer project, everything is the same except this folder for MyLib.dll.
Here is the registry structure after installation:
Firstly I have HKCR\CLSID{MYCLSIDs}, each of them represents one of my COM class. in the sub-key named "InprocServer32", I have Assembly, Class, CodeBase, RuntimeVersion, threadingModel. And the CodeBase is either common file folder (not working) or MyApp's installation folder(working), which is the different locations I put the dll. I thought there would be another sub-key TypeLib under {MYCLSIDs}, since Access only sees the TypeLib and I think there should be some link from the TypeLib to the actual dll, however, at both cases this sub-key is missing but in the second case it is still working. Is there a problem of it?
Secondly I have HKLM\Software\Classes\CLSID{MYCLSIDs}, these keys are of course the same structure as described above.
Thirdly, the HKCR{MYPROGIDs}, these are just ProgIDs of my classes
Fourthly, HKCR\Typelib{LibID}, which includes the information from tlb file, and this ID is from the Assembly GUID of COM component project.
Finally, the HKEY_CLASSES_ROOT\Interface{InterfaceID}, there is sub-keys named ProxyStubClsid32 with value {00020424-0000-0000-C000-000000000046}, and the one named TypeLib and the value is my LibID.
As I mentioned, the only difference is the CodeBase, which stores where MyLib.dll is located. In order to verify that, I did two tests: after I install MyLib.dll into the shared folder, the COM calling fails. But if I replace all the CodeBase values for SHARED_FOLDER\MyLib.dll to INSTALLDIR\MyLib.dll, and copy MyLib.dll into INSTALLDIR, it actually works. Vise versa, after I install MyLib.dll into INSTALLDIR(in which case COM is working), I change the CodeBase values from INSTALLDIR\MyLib.dll to SHARED_FOLDER\MyLib.dll, and make a copy to SHARED_FOLDER, this time it fails. So it seems that it is exactly the installation location's problem, which is the opposite to my understanding of COM. And I don't think there is a permission issue for the SHARED_FOLDER(I could be wrong) since it is in a folder that my installer creates.
Please help, thanks!
It turned out that MyLib.dll is using some other libraries, which are still installed in the MyApp installation folder. And so in that case that MyLib.dll is installed in the shared folder, it tries to find those libraries in the same libraries, which of course fails. When I install those libraries in the shared folder too, it is working.
BTW I found fulogvw.exe very helpful when tracking down the assembly loading problem. For example in my case in the failed log it says can't load file xxx.dll in SHARED_FOLDER, the xxx.dll is some library that MyLib.dll is using, and I had no idea that MyLib.dll needs it until I see the log.
I am having a problem with a 32-bit MMC snap-ins (on a x64 server 2008 machine). The snap-ins have been successfully registered. When I launch the associated.msc file using the mmc (with 32 bit option), the name(s) of the snap-ins are displayed on the LHS but the RHS shows an error page that says the page could not be loaded.
Using procmon, I think that I have identified that the problem relates to the failure to locate a DLL that is also shipped with the product and used by the snap-in. This is located in a directory c:\\bin and this directory is specified in the PATH environment variable. However, the MMC seems to be looking only in the c:\windows\sysWOW6432 directory (i.e. the 32 bit version of the c:\windows\system32 on the 64 bit machine). I wouldn't mind this if it also went on to search the other directories specified on the PATH (which includes the c:\\bin directory).
I have tested this hypothesis and put the DLLs in the syswow6432 directory and things seem to work correctly from there on out.
I would obviously not want to put all the product specific DLLs in the system directory and would prefer to keep them within the product specific directory.
Can anyone explain the failure to locate the DLL on the PATH and a resolution.
Use the /codebase option of RegAsm.exe when registering your dependent assemblies. You can specify the fully-qualified path to your assembly which will be lazy-loaded when the snapin is selected from the MMC snapin tree.
On 64-bit MS operating systems, in the absence of /codebase, dependent assemblies/DLLs of 32-bit snapins are loaded from the SYSWOW64 directory while 64-bit snapins load dependent assemblies/DLLs from the system32 directory. PATH does not seem to figure into the equation, although, alternatively, you could probably use gacutil.exe to install your dependent assemblies into the GAC vice polluting SYSWOW64.
I have two use cases: 1) loading a temporary DLL during a custom action and 2) executing a temporary EXE from a custom action. The custom action DLL is unmanaged C++. I cannot figure out how to get this working correctly. Including the DLL is easy enough but LoadLibrary is failing as it cannot find the DLL. I also cannot seem to get the physical path of the extracted DLL in order to specify full path in LoadLibrary. Any help is appreciated. I'm using WIX btw for this work.
If you have included the dll and the exe in the Binary Table of the msi, the files will be physically present in the %Temp% folder of the currently logged in user which gets mapped to SUPPORTDIR property of Windows Installer.
You need to use MsiGetProperty to get the SUPPORTDIR and use that in the LoadLibrary.
One thing to remember - Windows Installer usually extracts files from Binary table to %TEMP%, however - the current work directory is often set to c:\windows\installer.
My suggestion - extract the temporary .dll from Binary table yourself when you need it. This gives you the control of when it's saved to. Just remember that you need write permission to the location, so usually some subdir of %temp% is the best choice.
I am trying to set up communication between Centura and a COM .dll. (Downloaded from http://download.resip.fr for a database import)
Centura requires a .tlb file to be able to communicate to this component. Normally I would use regasm /tlb to generate the .tlb but seeing as it is a COM .dll this is not possible.
I found that I could use tlbexp for .NET dll's: http://msdn.microsoft.com/en-us/library/hfzzah2c(v=vs.80).aspx
I tried this out, knowing it would probably fail (as I have COM .dll). I received this error:
TlbExp : error TX0000 : Could not load file or assembly 'file:///C:\Windows\system32\ResipBcb.dll' or one of its dependencies. The module was expected to contain an assembly manifest.
Using Dependency Walker I noticed two .dll's missing. I found ieshims.dll online but I can't find the wer.dll. See this question.
I don't know if the tlbexp failure has anything to do with this file that is missing?
To sum up, my question is:
How do I get a .tlb from this .dll? I can't seem to find any way to extract the .tlb out of this COM .dll.
Best regards
Clint Cambier
What you are trying to do only works for .NET assemblies, not native COM servers. The type library for them is almost always embedded inside the DLL. In Visual Studio, use File + Open + File and select the DLL. Open the "TYPELIB" node, right-click the resource (usually 1), Export. Save it to, say, a project directory, use the .tlb filename extension.
TblExp and regasm are only valid on .NET assemblies, what you have is most likely a standard non .NET COM DLL. So neither of those two commands are valid on this DLL.
Standard COM objects are registered using regsvr32. Try running that against your DLL and see if it registers correctly. If it does you should see it listed in Centura's ActiveX explorer.