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.
Related
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.
I have made an application in openCVSharp.It works great. I have made the setup/installer to this app and have included all the dlls required, also as mentioned in the Readme file that comes along openCVSharp, i have included openCVSharExtern.dll . When i execute the setup in my PC, its installs the app fine and the app runs fine too. But when i install the app on someother pc, it installs fine, but when its run on that pc, it throws an exception P/Invoke and something about cxcore210.dll...
What am i doing wrong?
Thanks
When you reference the DLL in your project, are you referencing the DLL in the location that gets installed by the installer?
e.g. if the DLL is installed one directory back in a certain folder then it should be referenced on your PC when you build it, one directory back with the same named folder.
I'm just wondering if when you build the app on you PC you are referencing the DLL from a different location (which works find on your PC because it exists) but on another PC it can't find it.
I have an app that relies on several managed libraries. These managed libraries in turn rely on some unmanaged libraries.
When I deploy the app to a machine running XP, it runs fine. When I do the same on a machine running Vista, I get a DLL not found exception.
I've tried both a VS2010 setup project and an NSIS installer to do the deployment and it's the same in both cases.
Why might this happen? What can I do to get around it?
Update - Further details
Both installers check for the installation of .NET 4.0 and install it if need be
The Vista computer is 64 bit, but the installation gets directed to the x86 program files folder as expected
In both cases I have an admin account
The DLLs are kept in the same directory as the executable
As far as I can tell, the files are getting copied to the right directory
Update 2
The full error is at http://pastebin.ca/2046487
The DLL is Audiere.Net.dll, which is one of mine and is a managed library.
I'm not sure if that error means that it can't find Audiere.Net.dll, or whether it can't load it because one of it's dependencies can't be found.
Update 3 - Stuff from Process Monitor
After running process monitor (thanks Mehrdad!) there are several entries which don't have a status of "SUCCESS". Some of these are "NAME NOT FOUND" and some are "PATH NOT FOUND". (It's even querying the PDB files, which I had thought were only used by a debugger.) It's really hard to see which entries might be the one leading to the actual failure. Anyway, I've uploaded the log (filtered to have a relevant path) in case it means something to anyone.
Update 4 - Added .pdb files
So I kinda got desperate and included the .pdb files to the output of the installer. I thought it would be useless, but it actually resulted in a more useful error. Rather than simply saying DLL not found, I now get a BadImageFormatException. Googling this tells me that this is a common problem for binaries compiled on x86 but being run on x64 (as the Vista machine is).
The suggested remedy is to force it to target x86, but Audiere.Net.dll already was. Could the fault lie with the library that it wraps?
Maybe there's some sort of redirection that's not actually letting your app install in the intended folder?
We'd need a bit more detail, but are you installing for the user or the machine? Are you an admin? Where is the DLL normally located?
Edit: Try using Process Monitor to monitor what file is actually being accessed.
If you are running a .Net application, do both computers have the proper Framework installed?
You mention that Audiere.Net.dll is targeted at x86, but what about your executable?
You can obviously recompile your program or use Corflags (part of the framework) to view the current setting on your exe.
Corflags ssd2.exe
Or to set or unset the flag
Corflags ssd2.exe /32BIT+
Corflags ssd2.exe /32BIT-
(Note, if your app is signed with a strong name it won't work unless you use /Force to remove the signature)
The solution turned out to be quite straightforward: one of the unmanaged DLLs needed to be recompiled for x64.
Key steps:
Check process monitor for likely sources of error. Look carefully at the error report that Windows offers to send when the app crashes.
Include the .pdb files for managed libraries. This seemed to result in more informative error messages.
These error messages not only specified which managed library was causing the error, but also indicated that it was a x86/x64 issue. (BadImageFormatException)
Following some sound advice, check that all of the unmanaged libraries are targeting x86. (Mine were, but it's good to be sure.)
Recompile the unmanaged dependencies of the troublesome managed library on an x64 machine.
Write an install script that copies the appropriate (x86 or x64) version of the DLL.
Profit!
Specifics:
The problem I had seemed to be with Audiere.Net.dll, but was actually caused by a problem with libaudieresharpglue.dll.
I use NSIS for installers. To accomplish the architecture specific DLL, I used a header called x64.nsh.
Usual reason is that the dll in question depends on other dlls which are not on the Vista machine (or possibly there but not registered.)
We ran into something simlar and found we needed to download the c++ Redistibuatable Package to get the program to run on windows 7 using 3rd party dlls.
I recall running into a similar issue with SQLite wrapper.
The source of the problem is the 32/64 bit issue of course, and it's the same scenario as the SQLite wrapper is a managed wrapper which makes it processor dependent.
I am guessing that while you're managed lib (Audiere.Net.dll) is compiled for 32 bits, you main application (ssd2.exe) is not.
The installation folder is determined by the configuration of the setup, but if the application project is not strictly configured to compile as a x86 project (usually targeting the default Any Cpu environment) then the application will launch as a 64 bit process, regardless of the installation path. This can be easily verified by looking at the process in task manager on a 64 bit machine, all 32 bit processes have an additional *32 on a 64 bit windows machine (they won't have it on a 32 bit machine).
EDIT: or more easily by looking at the project properties->Build-> Platform Target :)
Anyhow - you should change the project settings for the project that builds ssd2.exe to target x86 and you should be ok.
We built a project in c# that uses a .dll which we use p/invoke to access functions within the .dll. It works on our development machines, we can create an installation version of our software which runs fine but if we load it on other xp machines and windows 7 machines which aren't dev machines it reports an error that the .dll that it is trying to p/invoke cannot be found. The error is repored as the 'the application has failed to start because its side by side configuration is not correct.'
What are we doing wrong?
Thanks, Ron.
Try installing the VC++ redistributable.
Also check that the dll is in the path. It does make a difference, I swear!
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.