I'm getting a DLLNotFoundException in standalone builds on some windows machines, others work perfectly. Dll file is definitely in the plugins folder, copied it to the projectName_Data folder too but no difference.
Also attempted to add dll to streaming assets folder and set new path (Environment.SetEnvironmentVariable) as above but that didn't work either.
Using Unity 4.5.5 btw
Any help at all would be greatly appreciated!!!
What I found is that the error DllNotFoundException is, in some circumstances, very misleading. Unity is not to blame for this because when something goes wrong with dll loading, Unity simply doesn't have that dll in memory and tells you so.
As Keysosaurus says, Visual C++ Redistributable must be installed for your standalone version to work and in most cases this solves the trouble but there can be other reasons like third party dependencies.
In case you are using third party libraries then you must also copy all the needed DLLs or SOs to your executable's folder.
For example I am working with OpenNI 2 and when I build I immediately copy all files from C:\Program Files (x86)\OpenNI2\Redist folder to the folder that contains the .exe. Not doing this results in DllNotFoundException.
Also don't forget that DLLs (and SOs) must match the architecture you are targeting so if you are targeting x64 (64 bit) then your DLL must be x64 too and if you try to use a x86 (32 bit) DLL Unity will be confused and will not load that giving you the same error.
As a side note bear in mind that Unity 5 comes both in 32 and 64 bit versions. In order to run your game in Unity Editor, all third party libraries must be present in both x86 and x64 (in Unity's conventional folders) or at least the one that matches you Unity Editor's architecture.
I discovered that the problem was that players needed Visual C++ redistributable installed, which can be downloaded here:
https://www.microsoft.com/en-gb/download/details.aspx?id=40784
Related
I have two problems with DLL compiled with VS2015 XP toolset when called from non VS2015 exe.
First and most serious is that using in such DLL-s tls variables (like statics declared inside function results in GPE on XP/Server 2003R2). Works fine on Windows 7+ and/or when called from VS2015 exe. Looks like something in runtime isn't initialized when called that way.
The second problem is with side by side installation of W10SDK/runtime DLL. Everything works fine with EXE but doesn't load from DLL path. You have either to install runtime or to copy DLLs to exe directory.
Can anyone suggest a solution especially to the first problem (second is annoying but can be handled).
Found a duplicate for first problem with workaround
Crash in CAtlStringMgr::GetInstance under Windows XP
What concerns second one - solved it with writing a VS2012 DLL proxy that chdirs to proxy directory, loads the library and then chdirs back (and then calls through all calls to VS2015 DLL. But would be glad to find more elegant solution
When I try to register the 32 bit version of my C++ / ATL project with
regsvr32 project.dll
i'm getting this error:
LoadLibrary("project.dll") failed - The specified module could not be found
project.dll is my dll built using ATL on Visual Studio 10.
The 64 bit version registered fine.
What am I missing?
I have observed this exact same error, but the solution was not installing the redistributable. All the dependent DLLs were present on the system1 according to depends.exe.
In my case, the icon of KERNEL32.DLL was slightly red tinted. Depends.exe did not offer much explanation, but digging around revealed that one of the imported functions were missing from the DLL on the system. To see the imported functions, select the dependent DLL in the treeview and look for the import on the right panel. Order by the PI column to see the red icons of missing imports.
In my case, the missing function was a function that did not exist on my sad target operating system, Windows XP. Since my program did not directly depend on this function, I was able to get away with #defineing the following in my project:
#define WINVER 0x0501
#define _WIN32_WINNT 0x0501
Compiling with these macros made it so the function in question was not declared in the headers, and consequently not imported at load-time. Now I was able to use regsvr32. This of course is a very specific (and lucky) case. I did not depend on that import or any other newer APIs, so I could get away with retargeting the project. Were it not a system DLL, I would have needed to find a newer version which could easily lead to a need to update a whole sub-tree of the dependency graph. Or even worse, if I depended on the missing imports, some serious refactoring would be needed.
To sum it up, this error message2 can be caused by the following issues:
The DLL file was not found or could not be read. Check the command line.
Some dependent DLLs were not found or could not be read.
Some imports are missing from some dependent DLLs. If these are system DLLs, you are likely targeting a wrong version of Windows. If these are non-system DLLs, you need to install newer versions of them and all their dependencies.
1.: Apart from IESHIMS.DLL and WER.DLL which is apparently a bug in this old tool.2.: Or really, any problems in loading the DLLs on a particular system
The error description is misleading in this case. The system finds your DLL (project.dll) but one (or more) dependency of your DLL might be missing.
I just installed
Microsoft Visual C++ 2010 Redistributable Package
and now I can install the dll.
Although this works, I'm not too happy with this, because I don't want to have to install this package on a client in order for my dll to work by them.
I am using the namespace System.Windows.Forms.DataVisualization.Charting to create a Chart object on a form. This DLL is not a part of the basic Windows install, so I shall need to include it in my package when I distribute my application.
I am aware of the new version of GacUtil.exe and also that Gacutil.exe is only for development purposes and should not be used to install production assemblies into the global assembly cache. Let's just assume that I have no choice in the matter and have to do it this way due to the use of a proprietary package distribution system. =)
Edit/Update: In the 2.0 runtime, even though some PC's did not have GacUtil.exe present on the intended installation PC, I could drop GacUtil.exe (2.0 version) on the PC and I could then GAC whatever extra assemblies I needed. This appears to be a problem in the 4.0 runtime. Even though I have copied GacUtil.exe (4.0) to the destination PC, I get no feedback when running it against the needed assembly. End Edit/Update
Now, on my PC (the development PC), I can add the DLL to the GAC without any problems:
However, on a clean Windows 7 PC, with the same DLL and the same version of GacUtil.exe I get this:
Why the discrepancy? Does the new GacUtil.exe depend upon something that this PC doesn't have?
Ok, I ended up having two problems, one of them being a moot point in the end.
Problem #1: GacUtil.exe (for the 4.0 CLR) has Dependencies
When i copy over the folder in which GacUtil.exe resides, the problem of adding the assembly vanishes:
This ended up being a moot point, however, because even though the file was in the 4.0 GAC on the client machine, I still had the crash. I realized at that point that the problem was that I am not targeting the 4.0 GAC - I'm targeting the 2.0 GAC. The file I was trying to add to the GAC this whole time was a 4.0 version of the file. This was the piece I wasn't understanding.
Problem #2: There are separate 4.0 and 2.0 versions of "GACable" DLL's, and they are not backwards compatible
I simply went back to my development machine and grabbed the 3.5 version of the DLL in question (System.Windows.Forms.DataVisualization), added it to the 2.0 GAC on the client PC, and crisis averted.
You can run the 4.0 Gacutil from your own folder if you add a "1033" subfolder and include the file, gacutlrc.dll, which can be found in the same subfolder in the standard location.
I'm trying to add a .NET 4.0 .dll to the GAC. I am attempting to do this because it is published by a 3rd party company as both a 32 and 64bit .dll which I must use from different apps on different platforms in both formats.
At any rate, I am having trouble registering this dll to the GAC on a Windows Server 2008 environment.
I have tried copying gacutil.exe (and supporting file) found at "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools" on my local machine to the "C:\Windows\Microsoft.NET\Framework\v4.0.30319" folder on the target production server per the suggestions found here.
I then tried copying them to "C:\Windows\Microsoft.NET\Framework64\v4.0.30319".
Running from both locations indicated successful installation. And indeed, the registration appears successful:
C:\Windows\Microsoft.NET\assembly\GAC_64\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
C:\Windows\Microsoft.NET\assembly\GAC_32\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
However, running a console app that refers to the (64bit) version of the dll errors out with the following message:
System.IO.FileNotFoundException: Could
not load file or assembly
'ChilkatDotNet4.dll' or one of its
dependencies. The specified module
could not be found. File name:
'ChilkatDotNet4.dll'
So, I have now manually created the following GAC entries using mkdir and copy from a command prompt (which may or may not actually work. I have no clue what is so special about gacutil.exe):
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll (using the 64bit version of the dll)
C:\Windows\assembly\GAC_64\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
C:\Windows\assembly\GAC_32\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
After each "install" of the dll, I tested and received the same error. Any ideas welcome!
EDIT: the GAC issue above may not actually be the culprit. Turns out, even when I create a brand new Console App project and add the .dll directly (so that it lives in the bin), I still can't run it on the sever. Also, I've noted that Console apps are created targeting the .NET 4.0 Client Profile rather than the .NET Framework 4. When I try to run it targeting the client profile, it appears that none of the System.Web* libraries are available. However, I tried running a very simple test app targeting both and neither would run on the server while referencing the bad .dll.
Is there a special kind of install that was to occur to run .NET 4.0 Console Apps?
For anyone else who may have trouble with this in the future. It was not a generalized problem with the way I was registering the dll to the GAC or how I was referring to it from my projects.
ChilkatDotNet4.dll (and the other versions I'm sure) was built in Visual C++. So, the server it is being deployed to has to have the Visual C++ Runtime installed for the appropriate processor architecture.
For 2010 (.NET 4.0):
x86
x64
If you're running an x86 app on a 64-bit platform. Make sure to mark the application pool with "Enable 32-bit applications" = true.
I have a mex64 dll compiled on my machine. I used Matlab 2009b with VS2008 Pro to compile the dll. The dll works fine on my Matlab installation.
I want a colleague to use the dll so I sent it to him and he gets the following error message when trying to use the dll:
??? Invalid MEX-file 'filename.mexw64': The specified module could not be found.
My current assumption is that this is caused because he uses an older Matlab version or missing a dll that I have. I ran dependency checker and asked him to check that he has all the listed dlls.
I am still waiting for him to confirm his Matlab version.
What other reasons can cause this and can the Matlab version make a difference? (I mean R2009a when I have R2009B and not a huge version diff)
The other person has Matlab R2009a. Shouldn't the mex just work if I compile it on my computer and deliver it to him?
Does this only leave a missing dependent dll?
The issue is strange, but I can confirm it exists.
Using pre-built libraries for matlab that are correctly installed and in the path, I sometimes get the same error. If I type in the function name at the command-line, the function is visible and will auto-complete. However, the function will not initialize until I 'cd' into the directory with the .mexw64 library file.
>> AndorInitialize('')
Invalid MEX-file 'C:\Program
Files\MATLAB\R2011b\toolbox\andor\AndorInitialize.mexw64': The
specified module could not be found.
>> path
MATLABPATH
C:\Program Files\MATLAB\R2011b\toolbox\andor
C:\Program Files\MATLAB\R2011b\toolbox\andor\camera files
C:\Program Files\MATLAB\R2011b\toolbox\andor\m files
... etc
It turns out this is due to missing dependencies, which shouldn't be missing. To resolve the issue, use dependency walker (free, lightweight) to identify what's missing. The mathworks explains this.
http://www.mathworks.com/support/solutions/en/data/1-2RQL4L/
In my case, two DLL's weren't showing up properly, even though they were on my system and in the path. I copied the DLL's into the windows/system32 folder and the library functions now work correctly. What's particularly strange is that the same library worked on my computer a few days ago (prior to the moving the DLL's).
In general, MEX files should work across different versions of Matlab; in particular, they should be forward-compatible. You're right; sounds like a dll problem.
If you built it with Visual Studio, it may be linked to the Visual C++ Runtime. This is a set of libraries that is not installed on Windows by default. The "redistributable" for it can be downloaded here; having your coworker install that could resolve the problem. If that doesn't work, you can use Dependency Walker to check for other unsatisfied DLL dependencies.
Normally, configuring Matlab's "mex -setup" to use the Lcc compiler that's distributed with Matlab could be a way around this, but it's not supported for 64-bit Windows AFAIK.
Also, are you sure he has the 64-bit version of Windows?
Another possible source of the problem could be that you compiled in debug mode. The Visual C++ redistributables only support release mode.
The Dll was a wrapper for MySql access. We ended up using Matlab's ODBC and the MySql Connector.