We are working on a validation script for Kofax Capture 9.0 / 10.0 in VB.NET 3.5.
We know how to create a script using the Admin Module, and how to get it operational.
The problem is that we need to reference a dll, located on a remote machine. (GAC is no option) This dll holds abstract classes we need in each validation script.
Even when putting the dlls locally (copy local), the Validation Module (index.exe) immediately throws the "cannot find reference" exception, even though the project compiled perfectly.
I guess the basic question comes down to: where do we put the dlls, in order for the Validation Module to find them?
The simple answer is to put the dll in the same folder as the application because this is one of the places which .NET will probe when trying to find it. The Validation module is run from the Capture bin directory which will be something like "C:\Program Files (x86)\Kofax\CaptureSS\ServLib\Bin\". This would need to be done on each client using Validation.
If you have a more complicated scenario, you could look implementing the AppDomain.AssemblyResolve Event and using Assembly.LoadFile to get the assembly from a custom location, but the using the bin path is less complicated.
If you end up having further trouble, you can troubleshoot by using the Assembly Binding Log Viewer (Fuslogvw.exe) which can tell you more details about why the assembly failed to load and where .NET tried to search for it. Assembly loading can fail for reasons other than just the path.
For more detail on how .NET loads assemblies, see the following:
How the Runtime Locates Assemblies
Locating the Assembly through Codebases or Probing
We found a solution: add all library files as "links" to the project. (Add --> Existing File --> small arrow next to "Add" --> Add as Link)
This ensures the files are compiled when you build the project. The Kofax Validation Module can now find the files, whereas when referencing the file, it could not. Why it could not, remains a mystery...
Related
I've built a inproc com server dll which I can package as 1 file or many via the build utility py2exe. When I allow all the dependencies to remain external, I have no issues, but bundling as 1 file produces problems.
When the dll is utilized (either registering it or instantiating a com object from it), it immediately loads MSVCR90.DLL from the path c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6871_none_50944e7cbcb706e5\MSVCR90.DLL no matter what I do, I can't change that. There is no information that I can find (using Dependency Walker) to indicate what is causing that to load. It just happens magically...
Then, later on it loads that dll again via an explicit call to LoadLibraryA("MSVCR90.dll") (part of some py2exe black box?), but this time it does not look into the winsxs manifests / directory. Instead it looks to the system path and/or will respect a dll redirection. That's when the problem occurs. If I set the system path to start with c:\windows\winsxs\x86_microsoft.vc90.crt...\ it will load the exact same dll and be happy - but if ANY other file is utilized - inclusive of a copy of the EXACT same dll - but at a different path - then the whole thing blows up. It can't handle using two different files.
How can I fix this? Ideally, I've love to make the initial magic loading of the dll draw upon a private assembly, but no matter what I do with manifests or .dll.local etc it will not respect that until this second dll loading takes place.
Note that with the non-bundled dll (external dependencies) it always uses the winsxs MSVCR90.DLL.
I can "fix" my failure to use the dll by forcing the system path to load the winsxs copy, but that is pretty useless for a deployable com server!
The reason is that you DLL has a manifest that tells the module loader to search also in the SxS storage.
You have several choices
Build your DLL using static linkage. Not using any of the MFC-DLLs (see project settings)
Don't use a side by side manifest for the DLL and still use the MFC DLLs. But beware you have to ship those DLL with your DLL in the local path (see DLL search sequence docs)
Use a later build of VS. Later versions of VS don't use the SxS storage any more and there are no manifests for those DLLs any more.
For the 2. see this article in code project. There is an update for VS-2008 [here].
2
Build your DLL
I've got a new system. I am trying to connect to and run the system through a 64-bit Windows 7 PC. The company sent me a Visual Basic project for that. It uses .NET framework 4 and Windows Form Applications. The target CPU is x86.
In the References tab, next to three of the COM references there are "The system cannot find the reference specified" statements. When built, the project gives the namespace errors and warnings because of these objects. The other references work fine. I've then seen those .dll files in the debug folder. I think they are generated by the company before sending me. They also exist in the bin\debug folder.
I've removed the three from the references list in the project and tried the following separately:
1) In the project, refer to the .dll files that exist in the debug folder. (Seems a fake way, but removes all the errors when the project is built. When debug, it gives the "Retrieving the COM class factory for component with CLSID ... failed due to the following error: 80040154" error.)
2) Copy the .dll files in the debug folder to C:\Windows\SysWOW64 folder, then register through regsvr32 "name.dll" in the console as admin. This way, I get the ".dll was loaded, but the DllRegisterServer entry point was not found" error. (In the regedit window, the registry editor cannot find the ID's of those references that are seen in the project properties in VB.)
3) Do the item (2), but with the C:\Windows\System32 folder instead of SysWOW64. The same error when registering.
4) Changed the solution platform to x86 and tried the items 1,2, and 3. Still the same errors.
Do I have to register these dll files? And, am I supposed to register exactly these dll files that exist in the debug folder? Or are they supposed to be generated after build by referring to some 'missing' type libraries in the references tab? I don't have these type libraries, though.
All suggestions are welcome ASAP. Thanks in advance.
You have three Interop dlls for your project, correct? These dlls just allow you to use a COM dll without having to talk directly to the COM dlls yourself.
Referencing the dlls in the bin/Debug directory should be fine, since those are probably the correct dlls that the project was built with. However, you will want to move them to another folder before continuing.
What you need to get from the company that sent you the project is the original COM dlls and their dependencies, if any. Usually an interop dll is called Microsoft.Phone.Interop.dll where it is performing interop with Microsoft.Phone.dll. Microsoft.Phone.dll needs to be registered on your computer using regsvr32 and then you just need a reference to the interop dll.
I'm trying to get TFS team-build to reliably build a WPF C# app. This app relies on a VB6Lib.dll which we maintain, this VB6Lib.dll itself relies on other C# libs that we also maintain.
I've set up a build definition to build (in order):
VbDependencies.sln (all libs in this have com interop set, thus the VB6 can find their TLBs)
buildVB6Lib.proj (an msbuild file which calls "VB6.exe /make /d" to make the VBLib.dll on the build server, as part of this script I've been copying the VB6Lib.dll output to C:\tmp)
MainApp.sln (in my workspace, I've added a reference to C:\tmp\VB6Lib.dll)
Does this sound ok
?
On my dev laptop I usually build the VB6, copy its output to \tmp and then regsvr32 it there before adding a reference to it in my C# solution. It's this step that I'm not convinced my build def is doing.
Also, is there a way to get more useful output from the VB6 build, currently I get "Compile Error in File 'xxx.bas' Can' find project of library", but not which actual library it can't find.
You are correct in that the critical point in your build process on the development system lies in registering the COM object. However, one does not in general want to register the COM object on the build server, as this can cause all kinds of versioning issues and silent failures when the wrong COM object is registered or the registration fails.
The proper way to accomplish this is to generate an interop assembly manually and reference that instead of the COM object. This is accomplished with the tlbimp utility, for instance:
tlbimp ..\Libraries\VBLib.dll /out:..\Libraries\Interop.VBLib.dll
Run that command on your development system, then remove the reference to VB6Lib.dll and add a reference to Interop.VBLib.dll. You can then add the tlbimp command as a prebuild event in the referencing project so that the interop assembly is always build from the correct version, and you will never again need to have your COM object registered on the build system.
I was converting some .NET-3.5-based projects to .NET Framework 4.0 and ran into trouble with assembly-embedded string resources.
The code contains references to resource strings like Resources.ValidationFailedMsg. Resources here is an automatically generated class. It's fully-qualified name is MyAssembly.Properties.Resources (the assembly name is MyAssembly.dll and, to keep it simple, the root namespace of everything in it is also MyAssembly). The project's "Properties" folder contains Resources.resx, where the string ValidationFailedMsg is defined (e.g. "Validation failed!") and the Resources.Designer.cs file is generated from it.
Now let's run this thing. Here's what happens:
System.IO.FileNotFoundException : Could not load file or assembly 'MyAssembly.resources....
Excuse me, what file???
First, I understand the concept of binary .resource files and how there may many such files for many cultures, but let's get one, default culture to work first. From .NET 2.0 to 3.5- compatible versions of this project, all strings were embedded in the assembly itself, so the framework didn't even look for them anywhere except MyAssembly.dll. How can I make it look at the assembly and not look at anything else?
Second, I noticed a .resource file in the project's bin\Debug directory, but it's named MyAssembly.Properties.Resources.resources, not MyAssembly.resources, and msbuild doesn't copy it to bin\Debug or anywhere else where MyAssembly is referenced. Is this a useful hint to what may be going wrong here?
Third, I can open a new, empty project in Visual Studio 2010, add Resources.resx under properties, put a string there, reference it in the code as TestProject.Properties.Resources.String1, build, and it works like charm. But in the old project, even readding Resource.resx with its strings doesn't help.
Can you explain why .NET 4.0 compiles these string into one place and then looks for them in a different place, causing the FileNotFoundException? And what is the proper way to migrate a .NET 3.5-compatible assembly with such embedded string resources to .NET 4.0?
Mystery solved.
.NET (before 4.0) looks for the .resource file first. If the file is not found, it looks inside the assembly to find the requested resource.
Starting with .NET 4.0, if the .resource file doesn't exist, the framework fires an AppDomain.AssemblyResolve event and passes the resource file name in place of the assembly name. (Why AssemblyResolve? - this is probably a bug.) Only if this event is not handled, does .NET 4.0 look inside the assembly for the resource.
As it happened, the application had an AssemblyResolve handler registered. The handler was programmed to locate DLLs and never failed for years until the day of the .NET 4.0 upgrade, when it was asked to locate a nonexistent resource file.
I'm working with a 3rd party assembly to implement something in our in-house software. I can make the refence and work with the library without a problem, but when I run the program to test it i'm getting this error
"Can't load file or assembly "assembly file" nor either of its dependencies. The system couldn't find the specified file" (i'm from Mexico, exception is in Spanish so i had to tanslate it, sorry for the poor translation)
I have given read and write permission to the file, the folder, and for all users and still wont load it.
I saw that the assembly has the PublicKeyToken=null, does that have any to do with that i cant load the assembly????
I already asked the people who developes this assembly, but i'm not getting any response and I really wanna get this project finished
If this is a web application, is the DLL in the bin folder? If it is a deskop application, is it in the same directory as the executable? If not, you may need to set the "Copy Local" attribute on the dll to true in Visual Studio.
Assembly Binding Log Viewer:
The Assembly Binding Log Viewer displays details for assembly binds. This information helps you diagnose why the .NET Framework cannot locate an assembly at run time.
Plus to what Chris said, you have to ensure that if the 3rd party dlls need any other dlls then they must be also in the bin directory, (you can check this by looking at the original directory of the 3rd party dlls and copy all dlls that come with it)