We have a plugin for IE based on spicIE, the purpose is to connect to some external devices.
To connect to those external devices, another company developed their token & DLLs. We need to have some ActiveX's and DLL's to do authentication by token.
The problem is that the plugin we developed for IE, in final part have a install.bat file, that runs a RegAsm and registers the DLL and after that plugin (or its changes) is viewable in IE.
When running the plugin from IE, our code can not find some DLL, required for authentication (name it x.dll).
Where is registered DLL copied? Is it really copied? I need to have x.dll in the folder where my plugin's DLL exists.
In a nutshell, RegAsm registers your .NET assembly to be COM-viewable. From MSDN: Once a class is registered, any COM client can use it as though the class were a COM class. The class is registered only once, when the assembly is installed. Instances of classes within the assembly cannot be created from COM until they are actually registered.
Without seeing your code in ActiveX, if I understand you correctly, your ActiveX is dependent on some COM DLLs, which is why you are running RegAsm against a .NET DLL.
Run RegDllView to find the details of what is registered and then check if you are indeed instantiating that object which was in fact registered.
Also, if you still have problems, try instantiating the object in VB6/Visual Studio 2010 etc. or equivalent in early binding to see if you have any problems. Examine the error on instantiation.
Related
I created a test project from .net as a class library, I checked the register for com interop option and it works from visual foxpro.
then I tried to put a reference to a .net dll that I need on this project, it is not strong typed to put it directly on GAC).
I have comvisible class with a method on the test project that calls a method on the .net referenced dll and when I call this method from visualfoxpro I get the error that
"Could not load file or assembly or one of its dependencies ..."
I tested to have the referenced dll on debug folder (that I compile and then test) and from the client app's folder that I'm testing to consume the com dll in foxpro and in none of them the com dll found the referenced dll.
I have another posible folder to put the dll to be found? some code that I need?
When I recompiled the project, it start to work, seems that for some reason the auto publish to COM registry not occurs automatically.
if someone have this problem,
test to use
regasm nameOfLibrary.dll /tlb:nameOfLibrary.tlb /codebase on the .net dll
it loads on the COM registry the dll without put it on the GAC (some warnings about versions, search for that)...
also another option is to make a "registration free activation" that free of the need of registering the COM with regasm to consume the dll later.
I built a .net COM dll (debug x64) on one machine. I have it all setup and working there (I can see it in C:\Windows\Micorosft.NET\assembly and OLEVIEWER).
I took the dll to another machine (along with it's .h and .c file generated from MIDL). I register the dll into the GAC by following these steps http://codeingaddiction.blogspot.com/2011/06/how-to-add-strong-name-to-existing-dll_16.html - create key pair, generate MISL, rebuild assembly from MISL with the key, and then adding it to the GAC. It seems to be in the GAC, and I can try searching for it with gacutil /l MyDllName. However, in my client application, when I link against it, at run time when invoking CoCreateInstance I get REGDB_E_CLASSNOTREG (HRESULT). I can't see the dll in C:\Windows\Microsoft.NET/Assembly nor in OLEVIEW.
Have I missed out any steps, or done something wrong?
Thanks
The reason you are getting the error REGDB_E_CLASSNOTREG is because your .net COM DLL is not registered. Any .net assembly needs to be registered for it to be exposed as a com class to the clients. We need to use regasm.exe to register the .net assembly.
I have a question concerning a COM C# component being created from a native C++ application.
The C# component is referencing an assembly which contains the COM interface.
So project A(.dll) contains the COM interface, project B(.dll) contains the COM class that implements this interface.
This C# COM component is then registered using regasm from some folder on my system, say for example:
C:\TestComponent which contains A.dll & B.dll, B being the one registered using regasm.
When my native C++ application (COM server), which is installed in another path, is trying to create an instance of the C# COM class from project B this fails complaining that A.dll can not be found.
If I copy (only) A.dll to the installation directory of my native C++ app, everything works perfectly.
Any ideas on how to tell my native C++ app that it needs to find the A.dll in a specified directory or in the directory where B.dll resides?
Kind regards,
Dwight
Having dependencies in a COM server is always a problem, whether it is an unmanaged server or one written in C#. Just like Windows, the CLR will only look in a few select places for a DLL. Which are the GAC and the directory where the EXE resides. With an option to also look in subdirectories of the EXE directory by using a app.exe.config file.
Knocking off the candidates here: you'll want to avoid giving the client EXE a .config file, you don't control its location nor configuration, it is somebody else's program. Same problem with the EXE directory.
Which leaves the GAC.
Also the location that Regasm.exe prefers, just omit the /codebase option when you register after you put the assemblies in the GAC. And a very good way to solve the DLL Hell problem that's so strongly associated with COM, the GAC can store different versions of your DLLs.
As far as I understand, you only registered B.dll. That is the reason, the COM System has no knowledge, where A.dll reside. I do not know a way to tell the application where it can found a, except of changing the workingdirectory or add the path to the A.dll to the system path variable or last but not least copy the A.dll into the system32 directory (but I hate that).
By the way, having a DLL proxy, like A.dll is, reside in the same directory as your application seems totally fine to me.
Ah one more thing. You can, if you now the path of the A.dll but did not want any of the above solutions, you can have a look into Loadlibrary.
I am writing a C# COM+ drop in for another COM+ dll. It has a very simple interface and I have successfully tested the drop in.
I am using 'component services' partly because the old system did and partly because it feel right.
Problem I have is when I register the legacy dll the path to the dll in the properties is the ACTUAL dll, also it just works.
When I register my drop in the path to the dll is mscoree.dll not my dll, and it seems hit and miss as to whether I have to add my dll to the GAC? I have tried code to add it to a cache automatically but it doesn't work?
Also, as I am using a WCF call with my COM+ call I am running into an issue as to where the configuration dll is currently it appears to be looking for settings in C:\Windows\system32\dllhost.exe.config
What I'd like is for it to look along side the actual dll? Am I missing something?
COM/COM+ is an unmanaged technology. It knows nothing about .NET managed code, so registering your .NET assembly directly in the COM registry could not possibly work. mscoree.dll is the .NET hosting library which loads the managed runtime and presents the unmanaged interfaces to COM which the COM registry requires. When an instance of the COM coclass that your assembly implements is activated, COM+ loads mscoree first, then mscoree has to load your assembly to hook up your implementation to the COM-callable wrapper which mscoree presents to COM+.
Where mscoree looks for your assembly in order to load it depends on how you registered it. It follows the normal path probing rules of the .NET Fusion loader, which means it will usually be looking in the GAC unless you have specified a codebase during registration (e.g. using the regasm command line argument /codebase).
Configuration settings for managed code are scoped by AppDomain, and by default the configuration file name for an AppDomain is obtained by adding the suffix .config to the path of the executable of the process hosting the AppDomain. Your component is hosted in COM+, so will execute in process which is an instance of DllHost.exe. So by default the configuration file for your component's AppDomain is going to be DllHost.exe.config. However, if you specify an Application Root directory for the COM+ application this will change the location where the AppDomain looks for its configuration, to [COM+ Application Root Directory]\[COM+ Application Name].config.
I'm getting a System.DllNotFoundException for a .dll which is in the same folder as the executable whenever my application attempts to use a function which exists in the DLL. The weird thing is that it is only occurring on one user's PC; it works fine on my dev PC and it works fine on one non-dev PC that I tried it on. Also, there are other DLLs in the folder which are being found and used correctly. The DLL in question is a native library which is referenced by my application via another DLL which is a c# wrapper for the native library.
My initial instinct is that there must be some other library being referenced by this DLL which doesn't exist on the problematic PC, but I cannot imagine what library this PC could be missing that the other non-dev PC has.
So my questions are this: is there a way to determine the dependencies of a given DLL file? Keep in mind that the DLL in question is a native library (i.e. not managed code), and I do not have access to it's source code. And if it turns out no dependency is missing, what else might cause such an issue?
For unmanaged dlls you can use Dependency Walker to find dependencies.
I would suggest using ILSpy to open the dll and view its dependencies first.