Greetings and Salutations,
I am looking to embed CLIPS in a .net application (via C#) and I am using two DLLs; CLIPSNet.dll and CLIPSLib.dll
When I try to run the program, it appears that the CLIPSNet.dll is assimilated successfully, but when it reaches to the CLIPSLib.dll, I get errors complaining about the architecture the DLL was compiled in (x86 instead of the expected x64).
I found several threads from several years ago that usually ended with the suggestion to recompile the source and it will work fine.
I do not have the facilities to recompile the source code myself, and a colleague of mine tried to do it for me and he encountered numerous errors in the source.
If anyone in the community has successfully recompiled the CLIPSLib.dll in the x64 architecture, could I impose upon you to please provide a link to the DLL or please email it to me?
Thank you very much, in advance!
Cheers,
Chief_Ed
Related
I have a Program in C# under visual studio that was targeting the .NET Framework 4.5.2
It is linked with another C# project (a plugin ) that target 4.5.2. This plugin has a dll in its references, (32 bit).
The programm and the plugin build configuration are set to Any CPU
Now I changed the targeted Framework for both of them to 4.7.1.
When I launch the Programm, it fails to load the Plugin.
Looking at the dll with dependency walker it looks like it does not find two methods in the kernel32 library.
See the screenshot
I am a bit new to C# and I find it weird, and don't really understand what is happening. (How could those method have been found before and not now anymore)..?
If you reference a 32-bit DLL, you should not be compiling to "Any CPU". If you run this on a 64-bit machine, your process will run as a 64-bit process and will not be able to load the 32-bit dll. Compile at least the EXE as 32-bit. If one module in your process is restricted to 32-bit, then every module in your process needs to be 32-bit (and, if one module is 64-bit, then every module must be 64-bit).
The InterlockedExchange stuff is likely a canard sending you off in the wrong direction (see the note from #HansPassant above).
Don't host screen-shots on remote locations, that web-site is blocked for me, and likely for others as well.
Both Hans Passant and Flydog 57 answer are correct. Giving credit to Flydog57 since it was a bit clearer for a newcomer like me.
Problem I had was eventhough I activate the target Platform as x86 for the whole solution, some subproject stayed as AnyCPU. (They had no x86 Platform and I could not create one for abstruse reasons).
However, forcing everyone to x86 did it.
DependencyWalker was a bit confusing to be, as it keeps writing 64 next to the system librairies name. Coming from Linux world I interpreted it as Problem during the linking, but I understand better now.
Thank you.
Several weeks ago I have build a Native C++ .dll that wraps a third-party .dll to be used with C# P/Invoke in several applications to be deployed in WES7. I've been using Windows 10 as a dev box and everything works as expected. This week I finally got my hands on the box with embedded Windows and things are not doing that well anymore... I've tried to deploy three different C# applications that use the .dll I built alongside the third-party one but they all fail with a DllNotFoundException. Obviously both .dll files are in the same folder as my executable file for each project, but I keep getting the DllNotFoundException. My native .dll targets the Win32 platform, the embbedded windows is a 32-bit system, and all my C# apps are built to target the x86 architecture, so I've ruled that out. I've wasted the last hour messing around with the system32 folder to no avail, so I've run out of options. Any suggestions will be appreciated.
Edit: I just talked to a co-worker who works remotely and he had the exact same problem when trying to run our .dll under WES7. I'll update this question as soon as I have more info.
In the end, I happened to be dumb enough to deploy a DEBUG version in the target machine, which didn't have msvcp100d.dll and msvcr100d.dll. I used Dependency Walker to figure that out (apparently it was too hard for me to take a look at the project properties page drop-down) and deployed a release version in the target. It finally worked, but I had a different problem that leads to another question...
I'm building a dll(c# assembly which implements some interfaces) that's called by another app. the dll built on my machine works but the one built on our build machine does not work. I have very little control on that app and can not debug it, I can only see the output of it. Is there any way to check the differences of the dlls? I have used reflector, but it only shows limited info like classes and methods.
I also tried building it on other machines with vs2005, xps can create correctly, server 2008 and win7 can not.
could you guys help me with it? any help would be appreciated. If I was not clear, please let me know.
Thank you!
Since you didn-t tell us the error-symptoms of "does not work" here is my guess formulated as a question:
Does your dll reference other dlls that are installed in global-assembly-cache? do all build machines have the same version of the gac-dll installed?
This one is a long story: i have recently built a win32 application in Visual Studio that uses DirectX and I sent it to some friends to verify that it works on other machines. They all had .NET installed, but the app didn't worked for all of my friends.
In two cases there we're some "could not load file or assembly Microsoft.DirectX.DirectInput version 1.0.29..." errors when they tried to run the program.
I figured that they must have other versions of the .dll and, after some checking, i found out that my references we're to fixed versions. I changed the "fixed version" property to false to all of the directX dlls, but they still got errors when they tried to run the application.
Finally i tried to copy all the dlls in the same folder with the app and the directx errors were gone, but they instead got a "System.IO.FileNotFoundException the specified module could not be found" error at the line where the program tried to make a Direct3D.Texture from an image (the link to the image was correct).
If you can help me with hints for fixing any of the problems above, i would greatly appreciate it!
It looks like you're using Managed DirectX, and some of your friends probably don't have it installed. As far as I can tell, the redistributable package for MDX is not available anymore. (Not from Microsoft anyway, you might be able to find it somewhere)
Note that Managed DirectX is basically obsolete and in many cases XNA is a better choice.
If you're using ManagedDirectX than there's the Quick and Dirty way of fixing this problem. and thats just copying the ManagedDirectX dll's into the same directory. MS Says it won't work and it's definitely not very suitable for production envs. But it'll work in most cases.
DLL's are at least:
Microsoft.DirectX.Direct3D.dll
Microsoft.DirectX.Direct3DX.dll
Microsoft.DirectX.dll
Your issue might be resolved by now.
I too was experiencing the same issue for 2 days now and I finally resolved it. I tried out so many solutions that were suggested on the web but nothing worked for me. My project references another project which in turn was referencing Microsoft.DirectX.Direct3DX.dll. When I ran the project I got the exception: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.DirectX.Direct3DX.DLL' or one of its dependencies. The specified module could not be found.
It turns out that this dll was searching for 'one of its dependencies' and couldn't find them since I didn't have DirectX installed on my machine. So the solution for me was to install DirectX.
Refer the following link for DirectX web installer:
http://www.microsoft.com/en-in/download/details.aspx?id=35
I hope this helps others who face the same problem! :)
Ok i'm currently using LuaScript v5.1 in a Game engine i'm using. and the handy LuaInterface that comes along with it. i've tested it on a range of systems running a range of OS's.
LuaInterface seems to fail on 64bit Operating Systems.
Could anyone point me to a 64bit Compiled LuaInterface.dll, or is there any alternative to the LuaInterface that can be used, because LuaInterface is extremely useful and i dont think i would be able to write a more extensive interface by myself using lua51. (I'm not that good, sadly)
Any help or links would be greatly appreciated.
Thanks alot guys!
You can check out the LuaInterface source code from the Subversion repository hosted on Google Code. It contains Visual Studio project files for building it yourself. Welcome to the world of open-source software!
I just found some links that might help with your problem.
This shows how to modify compiled assemblies to force them to run 32 bit:
http://bchavez.bitarmory.com/archive/2008/04/29/badimageformatexception-errors.aspx
This shows how to compile to target 32 bit:
http://www.atalasoft.com/kb/article.aspx?id=10165
Read this article for a good understanding of 32 and 64 bit managed apps:
http://blogs.msdn.com/joshwil/archive/2004/03/11/88280.aspx
Another good link that talks about 32 vs 64 bit:
http://www.hanselman.com/blog/BackToBasics32bitAnd64bitConfusionAroundX86AndX64AndTheNETFrameworkAndCLR.aspx
You can use KopiLuaInterface. I uses KopiLua, which is written entirely in C# and provides all the well-known interfaces like LuaInterfaces. It even implements the same namespaces as LuaInterface, so you don't have to change anything except your references!
I just migrated my project from LuaInterface to KopiLuaInterface in under 10 minutes without changing a single line of code!
You can find KopiLuaInterface here: https://github.com/gfoot/kopiluainterface/releases
Just remove your LuaInterface and lua51 DLL files from your project and add the 3 DLLs from the KopiLuaInterface release, update your references and you're done.
NLua supports 64 bits and is available via NuGet.
NLua site : http://nlua.org
GitHub: https://github.com/nlua/nlua
NuGet: https://www.nuget.org/packages/NLua/