I am having a similar problem.
I have developed a c# app that is Pinvoking a dll which is dependent on some other dlls. On dev machine it is working fine. Even when i copy the debug folder, which contains all the dlls and exe file, to a different location it works fine.
When I copy the same folder to another machine, it gives the dll not found exception.
The interesting thing is that the error message gives a path to the code file present on the dev machine. Not sure how this information is known at the target machine?
I have tried both the debug and release versions, but release version just crashes, and the debug version gives the exception message.
I have tried the dependency walker but could not figure out if there is any missing dependent dll causing the error.
I have tried to install VC++ run time redistribution package as well but it did not work.
I am using VS2013 on Win 7 64bit on dev machine. The target is Win 7 64bit.
Dlls are related to tesseract OCR and copied from here.
Related
I use SQLite and works fine on the developer machine (or machine with Visual Studio).
But it does not work on PCs without VS. I "installed" the SQLite manually (32 bit version, added to the references, Copy Local: True). I get "System.IO.FileNotFoundException" System.Data.SQLite.dll exception.
The System.Data.SQLite.dll is in the output folder.
But I can not get it to work only if I install the SQLite with this: https://system.data.sqlite.org/downloads/1.0.105.2/sqlite-netFx46-setup-bundle-x86-2015-1.0.105.2.exe
Dev PC: x64 Win 10, application: x86 only
Please let me know if you need any other information.
Check which dependencies has your executable file (and, maybe, System.Data.SQLite.dll) with Dependency Walker or similar program. Then put these libraries you found into executable's folder one by one, until your executable will work.
You need to make sure the 64 bit C++ runtime DLLs are getting installed. They'll often be on the developer's system but not as often installed by your installer on the target system. Even though this is a .NET assembly, it appears to have C++ underpinnings.
I'm trying to use the VTK with C# to read and write VTK/VTS files. I created a basic app, and I installed the 64-bit VTK .NET wrapper package which is called ActiViz.NET.x64 (v5.8.0).
The package installed without any problems, and I could access the Kitware.VTK namespace, but as soon as I try to create a VTK object, I got an unmanaged DLL loading error.
An unhandled exception of type 'System.DllNotFoundException' occurred in Kitware.VTK.dll
Additional information: Unable to load DLL 'Kitware.VTK.vtkFiltering.Unmanaged.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
I don't think that the exact code is relevant here, but I got the exception at the following line:
vtkStructuredGrid structuredGrid = vtkStructuredGrid.New();
I'm using Windows 10 x64, Visual Studio 2015, the target .NET Framework is 4.6.2 and I have ParaView 4.1 and 5.2 installed. The DLL in question is in the bin directory of the app, but I also tried to copy it to the Windows/System32 directory, the result is the same.
Is there a way to figure out what exactly the problem is with the dll loading?
If you go to the ActiViz product page you can see the following in the FAQ:
Does ActiViz 64 work with Visual Studio?
Visual Studio is a 32 bits
application, therefore 64 bits control does not work and you need the
32 bits version of ActiViz when using the designer within Visual
Studio. Usually, the 32 bits version is used to design and the 64 bits
version is used for the final compilation.
I also use VTK/ActiViz (C#) on Visual Studio, and it works fine when my program is targeting x86 platforms. However, if I target x64 platforms, the winforms control for the render window disappears, but I can still build the executable. So do this:
1) Install Activiz.NET.x86 from NuGet & target x86 platforms;
2) Create and debug your App;
3) Make a backup of the solution folder;
4) Install Activiz.NET.x64 from NuGet & target x64 platforms;
5) Don't open the designer because it will be buggy (all RenderWindowsControl disappear);
6) Build the solution (Release x64).
So, first I wanted to know where exactly is my process looking for the missing DLL. I used Sysinternals Suite and its Process Monitor.
I referenced VTK in my .NET library which I used in my self-hosted app. The self-hosted app was the start-up project, so the runtime looked for the missing DLL in the app's directory, not the library's, where it actually was.
After I copied the missing Kitware.VTK.vtkFiltering.Unmanaged.dll to that directory, Process Monitor confirmed that the DLL was read successfully, but I still got the same exception as before.
I compared the library's and the app's bin directories, and I figured that only the Kitware.mummy.Runtime.dll and Kitware.VTK.dll were copied there automatically.
I copied all the other VTK DLLs to the app's bin, and then it finally worked.
The exception's error message wasn't detailed in the first place, but I think it is more likely a problem with the ActiViz.NET package.
You should copy all dlls from Activiz Installation bin directory even you don't need to use in your code.
C:\Program Files (x86)\ActiViz.NET 5.8.0 OpenSource Edition\bin
Managed .Net DLL's is a wrapper for unmanaged VTK libraries. Mummy.dll is for this job.
I have a small application that includes two third-party DLLs, pjsipDll.dll and sipeksdk.dll. Both of these DLLs are set to True for Copy Local. When I publish the application and install it on a second computer running Windows 7, it loads the sipeksdk dll fine and then that dll tries to use something from pjsipDll and it errors out saying:
"Unable to load DLL 'pjsipDll.dll': The specified module could not be found."
If I install this clickonce deployment on my development computer it works fine.
I looked in the deployment directory in on both computers, both DLLs are present, all the files are the same. On both systems I'm running as an administrator.
Any ideas on what I might be missing?
Thank you,
Stateful
It's funny how you fix the problem after posting on StackOverflow. It appears I was using incompatible builds of the DLLs. I found an older version of each that were known to work together and everything started working.
I compiled my executable that used the Access Database Engine libraries on Windows XP 32bit.
Running that on the Win7 x64 OS gave me an error that the OLEDB components were not registered.
I tried to install the AccessDatabaseEngine x64 and it fixed the problem.
However on another machine with Win7 x64 and office 2007 32bit installed, it wouldn't let me install the AccessDatabaseEngine x64 and so I was left to compile the project on that target machine (in VS2010 c#) with the Env as x64 and target CPU as x86. This fixed the problem.
My question is, why does this work? What's the reasoning behind this?
Thanks.
The answer your question what you are stating means that there for one is a different OS but should not matter.. the real issue here is that there are 2 different versions of Microsoft Installed.. you would have to either
GAC the version or Reference the version of the Target Machine
Set Copy Local of the .DLL in the working version to the Target version.. sort of like where your DLL's would reside in the Debug/Bin or Debug/Release folder where the bin folder resides..
I am working on Windows 7 64 bit and copied my working dll's over to a Windows 2003 server machine and my projects still work..
my other work around was to reference the Microsoft.Interop.Access .dll's from the Target machine into my Solution, recompile and Bam....!
My .NET 2.0 application imports unmanaged 32 bit dll.
The dll is loaded (first interop call happens) when user opens a file via a dialog within the application.
When I deploy the application via clickonce with target platform "Any", users on 64 bit windows get BadImageFormatException when trying to open files from the application (at the moment the unmanaged dll is loaded). I understand this is due to incompabible bitness of the 64 bit process and the 32 bit unmanaged dll.
I have redeployed the application using x86 as target platform. As I understand it, this should solve the bitness problem.
BUT
When I run the deployed application built for x86 on 64 bit system, I now get BadImageFormatException immediately before the application even starts. Tested on at least three 64 bit machines. On 32 bit machines, it works with no problem.
When I run the application directly from VS (or not directly, just a normal build, not going via ClickOnce), there is no problem on 64 bit windows when using x86 target platform. The application starts and user can load file - the interop call succeeds.
I have been debugging this for 2 days straight with no result - I have tried on different computers. It seems to consistentnly work on one of the computers I have tried. However, I do not have permanent access to this computer.
I have managed to build the ClickOnce deployment on my computer once and it worked on a 64 bit machine. This was single of maybe 100 tries! Nothing has changed, the only changed variable was that I did the successful build immediately after computer restart.
I did clean/rebuild/restart VS/restart windows MANY times. I have reinstalled VS 2008 and now also the whole OS, it did not help.
EDIT: I have just managed to get one good build (out of next 100 :)) and did comparison between the deployed directories.
The source of the problem is that ClickOnce generates the wrong target platform in the manifest of the main .exe:
<asmv1:assemblyIdentity name="app.exe" version="1.0.4.18" publicKeyToken=".token here." language="neutral" processorArchitecture="<b>msil</b>" type="win32" />
processorArchitecture should be x86.
So the question is how to consistently force VS to generate the correct processorArchitecture in the manifest when deploying.
Can anyone help please?
This was resolved by installing VS 2008 SP1 on 64 bit Windows 7. VS2008 SP1 on XP had the problem on two machines I have tried with.
I had this problem as well, using VS2008 SP1.
In my case I had a 32 bit DLL which had to be compiled as 32 bit and an application that was using it in the same solution.
Even though I specified X86 as the build target for the release build, when I published a 64bit application was compiled and included in the installer.
I found a slightly brutal solution to the problem:
Go into the configuration manager and remove all possible configurations except the one that you want it to build (Debug and release versions).
After doing this I found that the clickonce installer was generated with the correct application.
I hope this helps someone else, I have been battling this problem on and off for months.
I'd suggest to use Reflector to open the main exe deployed by ClickOnce and see the dependencies to make sure you are not deploying the 64 bit version of the dll by mistake.
You must resolve to run 32-Bit Applications in IIS 7. See http://www.fishofprey.com/2009/04/badimageformatexception-in-iis-70-on-64.html
Sometimes the ClickOnce publishing process seems to cache old files from previous Any CPU or x64 builds. Doing a Clean and Rebuild All didn't fix this problem for me. I needed to delete all of the bin and obj folders from my projects and reopen Visual Studio.
We ran into this problem and determined that the subdirectory of the user profile to which ClickOnce deployed our application must have become corrupted, because we were able to deploy the application successfully with ClickOnce when logged in as a different user on the same machine.
We were able to solve the problem simply by deleting the subdirectory of C:\Users\<user>\AppData\Local\Apps under which ClickOnce was deploying our application. In our case, this was C:\Users\<user>\AppData\Local\Apps\2.0.