The situation is that. I run Labview and from one via ActiveX pallet call my COM object method. And it works, I walk through my code with debugger.
But when I start to use (uncomment) code from side dll I see "class is not registered" error in Labview. My additional dll and its dependencies located in separate directory. So I tried to set PATH environment variable to this directory and after that run Labview. But is still doesn't work.
So the question is how to debug this situation? I looked through event logger but didn't found anything related.
P.S. I created my own synthetic application in C++ which calls the same method as Labview via COM too. And it works.
The problem was in hard defined base dll address. Labview used this address and COM dlls couldn't use that space.
I suppose report is incorrect ("class is not registered") because class is registered, but corresponding dll couldn't be loaded.
Related
I am working with an application GUI program and a console program, which call a COM object, which calls a worker DLL. Let’s call them ConsoleApp, GUIApp, COM DLL, and Worker DLL. The two Apps use CreateObject (VBasic) or GetProcID(C#) to activate the COM object and call it. In turn, the COM object calls the Worker DLL.
Problem: My goal is to register the COM DLL once, and then to continually develop the worker DLL without having to reregister the COM object all the time. Things work as expected when using the ConsoleApp. I can call it and see a debug message from the Worker DLL. When I change the message and recompile the worker, the next invocation of ConsoleApp shows the expected Mbox message.
But things do not work as expected with the GUIApp. To pick up any new worker DLL code, I must reregister the COM object (of course the GUIApp is not alive during re-registration). But that defeats the purpose of me trying to split the big COM+Worker DLL into two pieces to avoid re-registering the COM object all the time.
I have read many web pages (including here) on COM objects, but have not found answers that might work for my goal of having the registered COM object call a Worker DLL that can change during development.
Q. Is this the normal case that all DLLs referenced and called by a COM object are somehow bound to the COM object at registration time? (Answered above and below.)
Q. Is there any way for me to register the COM object once and have it call a DLL that I can work on in development without constant reregistering the COM (calling) object every time I change the Worker DLL code?
That's my ultimate goal if it is possible (and it seems to work as expected for the ConsoleApp).
UPDATE: RomanR suggested that I use ProcessExplorer to see which process is hanging on to the Worker DLL once GUIApp has been shut down. I could find the Worker DLL when GUIApp was alive but could not find it when GUIApp was shutdown. At the moment, the visible evidence is questioning my statement that the GUIApp never lets go of the Worker DLL. I will have to figure out a way of absolutely showing whether rebooting GUIApp picks up the new versions of Worker DLL.
The problem occurred because I registered the COM object direct from VStudio as part of the build (as Administrator). In the COM VStudio project, the reference properties for Worker.DLL specified Copy Local = True. Therefore, at the time of registration, the COM object was referencing the locally-copied version of Worker.DLL and not the future (later modified) copies of Worker.DLL that were stored elsewhere.
If I set Copy Local = False, I could register the COM object, but it would fail because it could not find the Worker.DLL at runtime.
The easiest solution was to 1) close the GUIApp to release the COM and Worker DLLs, 2) modify the Worker DLL with new code, 3) and copy the new Worker DLL into the COM project\bin\Debug folder where the Copy Local=True operation would put it. That way the registered COM object would pick up the most recent Worker DLL from the expected location.
Another solution (that I have not tried) is to modify the COM code to dynamically load and instantiate Worker.DLL from some dynamic location. That looks like a good approach too, although it does not give compile-time feedback on Worker DLL methods, etc.
i have create a c++ DLL with COM interface with Visual Studio 2013.
The DLL get's installed along with registration.
In the Ole Object Viewer, i can see typelibrary of this DLL with all
exported functions.
regsvr32 completes without any error.
Just within C# i can't use, because creation fails with error 0x80040154 -
class not found or not registered.
It is not a platform issue. The 64bit version is in system32 and the 32bit
version in syswow64 and they are registered there and typelibary information
in OLE Object Viewer confirms this.
But the class is not listed in the OLE Object Viewer tree.
Habe noe idea what's missing or wrong.
More over, i have a simliar VC++ project and this COM/DLL can be seen
in the view in the OLE Object viewer. It is compiled, linked
and installed in exactly the same manner.
I already compared all Compiler, Linker and MIDL settings, checked the .idl
file in the projects, the .rgs files... all seems to be the same, except
different names and guids.
So it is really strange: One is shown as COM object in the tree
of OLE Object viewer and can be used in C# program, the other not.
Please note: There is no compiler error in C# project using this DLL/COM.
There is a runtime error on creation 0x80040154.
Summary: i have to COM/DLL, both visual studion projects, deployed in the same
manner, the one can be seen in the OLE object tree and can be used in C#, the other not.
Are there any key points i could check and which are required for a successfull
listing as OLE COM object ?
PS: The only difference is the MSIL compiler version indicated in the type library view: The good COM/DLL has MSIL 7.xxx the bad one 8.xxx
but i don't know where at all to selected MSIL compiler. Both DLL/COM are built
by VS2013
OLE/COM Object Viewer shows the registration. When an application attempts to create an instance, there are further steps involved: registration points to server implementation, the library is loaded, class factory is located, class factory is called to created an instance. A failure in these steps results in instantiation failure nevertheless the registration itself is present and valid.
Your typical steps to troubleshoot the problems are:
Setting a break point in constructor of your COM class, in class factory construction, in DllGetClassObject exported function of your DLL, finally in its DllMain - to find out how close the system reaches trying to create an instance. Then step from there to get to the root of the problem.
Using Process Monitor to track registry/file activity around instantiation call and identify issues there (esp. if your DLL with COM server implementation is not even loaded).
If the class is not even listed in OLE/COM Object Viewer, then there is a problem even at registration stage. Your first troubleshooting attempt is to re-register manually and see if you have any registration error, or if it fixes the problem. There is a number of reasons for the registration to fail, a typical is that you have your COM class in your type library, however there is no implementation connected and referenced by OBJECT_ENTRY. With failed registration instantiation is expectedly not working because system cannot pick your implementation up and you see what you see: REGDB_E_CLASSNOTREG error code.
Found the problem: The typelibrary was not associated with object, because the typelibrary CLSID in .rgs file was different from that in .idl file, just by a space which was most likey introduced accidently.
in .rgs file:
TypeLib = s '{7DAA7049 -AAB2-4689-8635-FB6E03423F34}'
in .idl
uuid(7DAA7049-AAB2-4689-8635-FB6E03423F34),
Now i can use the DLL as COM in my C# project.
The COM/DLL was not listed in the object tree, because in the .rgs file was no name defined. This is a definition with name and this is the name of the COM/DLL in object viewer; the name follows to s which was previously empty (s'').
ForceRemove {4763F309-D922-227A-A1A8-CDFF29893BBD} = s 'myDllCom Class'
I have looked through countless threads on the error message
"the module was loaded but the entry-point dllregisterserver was not found make sure that is a valid DLL or OCX file"
I also tried regsvr32, and regsvr32 from syswow64...
I also tried registering it as name.ocx (per another threads suggestion).
Option Explicit On
Imports System
Public Class GenThis
Public Function rtnStr(Optional ByVal o As Object = Nothing) As String
Try
'do stuff
rtnStr = strTmp
Catch ex As Exception
Return "ERROR"
End Try
End Function
End Class
That is the class, being built on 2.0. When I add the dll as a reference in VS everything works fine. When I try to go in (same machine, Win7) to Excel Dev tab to try and add it there it does not exist. Also need to be bale to register it for our VB6 application.
I can't find any definitive answers or explanations on "what" this means. Can someone elaborate what is going on and what I am doing wrong?
Not all COM dlls are registerable. Sometimes the registration info sits in another dll. Programming languages use type libraries that may or may not be in the dll. Type libraries and registration is two seperate things.
.NET COM dlls aren't registerable in the normal way (it's the .NET framework that gets registered and it recieves calls and passes them to the .NET COM dll). For .NET use RegAsm, part of the .NET framework, which sets it up.
I am modifying an existing application in VB .NET.
In one routine, I have added a reference to a class in a newly-referenced class library project that is part of my solution, and now I get run-time FileNotFoundException messages when the program attempts to access this routine while debugging. The error tells me that the class can't be found, what's up with that?
To be clear: if I remove the lines of code relating to the new class, I no longer receive the exception messages. If I add them back in, here they come again!
I have referenced the class library in the project containing this routine.
The class library is building properly (other projects reference same library, and use it more extensively), and the project is referencing the class library's .dll file in my "debug" folder.
I get no errors from other routines that use this new class (thus far).
I get no errors in the Error List of the IDE.
What in the world could be happening here?
SH
This is a project reference, not a reference to an assembly (DLL), right?
Are the .NET frameworks the same?
Does the project you are referencing depend on some external assemblies not included in the other project, that might be called, producing the file not found?
I am trying to create an instance of a COM object. I have the class name that implements the interface and I get a CLSID by using CLSIDFromProgID(). So since I am getting a CLSID I thought everything should be fine from now on. However when I do a call to CreateInstance and pass in the CLSID, I get an error saying "Class not registered". Also I get this error only in some computers. It runs error free on several computers. I don't understand where the problem could be. Is my registry dirty? Does anyone know what is going on here? Thanks for your help!
I just want to add that this is a .NET COM class. The appropriate entries are in the registry and the DLL is in the GAC.
CLSIDFromProgId is simply looking up the ProgId's name in the registry and translating it to a CLSID, it doesn't have to look at anything beyond the registry or even check that something is actually implementing that CLSID.
When you call CreateInstance on the CLSID, Windows will look up in the registry to find out how the object should be instantiated (usually a exe or dll). It will then try to load the dll (or start up the exe) and create the object from it.
There is a lot of documentation in MSDN on the processes involved, for example see "COM Class Objects and CLSIDs", and if you do a lot of COM work it is worthwhile learning the process from first principals since it can save a lot of time and hassle when debugging this type of issue.
It's a two step process in the registry. You used the ProgID to get the CLSID. Then, when you call CreateInstance, COM then uses the CLSID to find the path to the dll. You can used regedit yourself to lookup the CLSID and see what that entry looks like.
Thanks for your answers. The .Net assemblies were registered properly and were present in the GAC. One application that absolutely confirmed this was Process Explorer. You can view the dlls that are loaded by each application. So from here I was able to see if the application that was instantiating the COM objects was actually able to load the DLLs or not. I found out that this was indeed happening. The problem was due to different Regional settings. We found that the application threw an exception when the region was not set to US. This issue was fixed. The error message "Class not registered" was not very helpful. Thankfully it was a quick fix.
Using shell32 as an example, you can create a new instance like so;
var shl = (Shell) Activator.CreateInstance(Type.GetTypeFromProgID("Shell.Application"));
This will aquire a refernce to an existing component;
var shl2 = (Shell) Marshal.GetActiveObject("Shell.Application");
Here's a reference to how to do the same in IronPython.
** Note, this used the progid, clsid would be nearly identical, just use Type.GetTypeFromCLSID({GUID}).