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?
Related
I have two completely different directories. Directory 1 contains my application and Directory 2 having few assemblies. During run-time when application launches, I will load the assemblies. By default, the executing Assembly's AppDomain will discover the assemblies in Directory 1 (application folder) or GAC. If the file is not there, we will get the error. But I have to extend the AppDomain's search directory to search in Directory 2 also. That is, AppDomain will search Directory1 (local bin), then GAC, then other defaults at last search in Directory 2.
I have tried :
1. By setting PrivateBinPath, but it is restricted only within ApplicationBaseDirectory.
2. By AssemblyResolve, but it is not directly referenced. The AssemblyResolve code never hits also.
Using the AssemblyResolve event is generally the correct way. If it is never hit, it is probably bound to too late. For instance, when the CLR encounters a method, it will compile it completely, resolving all its references. If such resolution fails, it will fail always. If you bind the AssemblyResolve event after any or all assemblies failed binding, the event will never hit.
To resolve this, make sure that the AssemblyResolve event is bound as early as possible. In an executable this is easy enough (first thing in the entry point of your application, or any cctor of a type you use there). In a library this can be harder, best practice approach is to use the module initializer, which is run whenever a module is loaded (most assemblies contain one module).
Since the module initializer cannot be set by C# or any other .NET language I know of, you have to resort to method weaving. I personally like Fody and as it turns out, there's a predefined Fody package called Fody Module Init for exactly this thing.
Just place, somewhere publicly in your library, the following code:
public static class ModuleInitializer
{
public static void Initialize()
{
// bind to the CurrentDomain.AssemblyResolve event
}
}
Fody also works with other languages (you don't specify which you use), but then you'll have to create the static ModuleInitializer class by hand.
Using this approach, you can be certain that the AssemblyResolve event will be called for any assembly that CLR's Fusion cannot find by itself.
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.
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 created a new project in Visual Studio 2013 (class library). There is no app.config. When I select add new item, there is no app.config in the list. Were is the app.config?
I have a ClassLibrary, which contains a number of NUnit Test classes. The problem is that there is lot of code like this throughout the application:
_ConString = ConfigurationManager.ConnectionStrings("GeniedbConnection").ConnectionString
Therefore when I run the tests I get a Null Pointer Exception. Is it possible to do this in the test classes:
ConfigurationManager.ConnectionStrings("GeniedbConnection").ConnectionString = "Connection String"
I get a Null Pointer Exception when I put the code on the above line into the test class. I believe it is because I am trying to set the variable before declaring it. Is that correct?
A class library doesn't contain an app config, since it isn't an app on it's own, but it can be an addition to an app. You will see an app config if you would create a winform application for example.
Class libraries are dll files that are frequently exchanged between different applications, these are often frequently used classes, that can speed up development, since you don't have to write code that you wrote once before.
MSDN Class Library
Edit:
You should use a UnitTest project and not a class library. Following question + answer will help you out, about using the .config file of your application: Use appliction config file from unittest project
UnitTest Project
If you add a reference to System.Configuration in your class library then you can use the following namespace to access the app.config of any applications which use it:
Imports System.Configuration.ConfigurationManager
...
Dim x As String = AppSettings("MySettingName")
I have a VB6 program that calls a VB6 DLL which in turn calls another VB6 DLL. When I execute the calling program there is an application error which I am unable to pinpoint so I researched how if it was possible to "see" the error in the dll.
I read Stackoverflow entry question about debugging VB6 dll
and followed the directions of Booji Boy to create a vbg. I also followed his directions and removed the two DLLs from he Reference list. The calling program takes a .txt file as input. When I executed the exe I received this error:
Error Number: 13Description: Type mismatch
The error isn't being generated by the application.
What does this mean? How can I debug this issue?
You must have all the source code for the EXE and the two DLLs. You add all the projects into single group file i.e. the VBG. You must have a reference in the EXE project to the first DLL. I have no idea why you have been told you have to remove them. You must have a reference in the first DLL project to the second DLL project. VB is clever enough to silently replace the DLL reference with the project reference. It is also clever enough to silently replace the project reference with the DLL reference if you remove a DLL project from the project group.
Make sure you have error handling set to "Break on All Errors" or "Break in Class".
The type mismatch error can occur from simple things like assign a non-numeric string to an numeric variable. It gets more complicated if you are passing object references around. If you see this error occurs on something like:
Set myObject = someOtherObject
... and it looks as if they should be the same type, this might get very complicated. But first, I'll let you do the debug.
You can use an open source project made in Visual Basic 6.0. It is called "Debuggy v2".This project has multiple roles:
-debugger
-disassembler
-Windows resource extractor
-file hex editor
-window sniffer
-API spy
all rolled into one. I may be useful for what you need.
When starting to work in a VBG a type mismatch can arise if the library references are inconsistent. One library may be referencing another IN the VBG; a second may be referencing the compiled version. Passing objects between them can result in this error.
Concrete example:
VBG contains code for: A.DLL, B.DLL, C.DLL
A references B in the VBG
C references B which is compiled
Code in A calls code in C passing an object defined by a class in B.
Type mismatch
C should have referenced B in the VBG.