I am writing an application in C#, which is cross platform. It uses DllImport for several different libraries. It is also both x32 and x64.
It seems to work right for my own compiled .dll/.so. I put the x32 shared libraries in the x32 sub-folder, and the x64 shared libraries in the x64 sub-folder.
On windows via .net framework I call SetDllDirectory("x32" or "x64") depending on the current
runtime. On mono, either through windows, linux or mac, I use a DllMap, in RandomLibrary.dll.config. It works fine for files that are located in the x32 or x64 directories.
However, I also use DllImport for libraries that I didn't write, such as FreeType2. On windows, I just shove the built libraries in the two sub-folders. However on linux I would rather use the libfreetype6 library that you can install via your friendly local package manager. I can hardcode the DllMap link to /usr/lib/x86_64-linux-gnu/libfreetype.so.6, but I assume that the freetype file will change depending on what distro you use.
Is there any easy way where it can just find libfreetype.so regardless of what distro I am using?
Using DllImport("libfreetype.so.6") for Linux should be enough, as the system should be configured to handle it correctly. Make sure you have the correct packages installed.
If it doesn't work you may have a misconfigured system: post the errors you get, the LD_LIBRARY_PATH env var value, the contents of /etc/ld.so.conf and the files in /etc/ld.so.conf.d/.
The output of
/sbin/ldconfig -p |grep freetype
would be useful as well.
Mono have a thing/procedure specifically for this, it is called DllMap. You can specify which unmanaged libaray gets loaded on which platform. Eg:
<configuration>
<dllmap dll="foobar" os="linux" wordsize="64" target="linux/amd64/libfoobar.so" />
<dllmap dll="foobar" os="linux" wordsize="32" target="linux/i386/libfoobar.so" />
</configuration>
I've not tried the above myself - The dllmap docs seem to hint that the target value isn't a path but I can't be sure.
Another approach would be to have a simple shellscript or batch file. On linux the shell script could easily work out the architecture by calling arch and set LD_LIBRARY_PATH accordingly. I generally prefer a shell wrapper around my mono programs ( seeing MyProgram.exe on the console feels ugly )
Lastly you might have more fun if you pinvoke into dlopen or LoadLibarary to pre-load your shared libraries.
When your managed app starts you decide what architecture you are and then use dlopen() if on linux or LoadLibaray() if on windows.
Related
I have a .NET application that calls a C++ API using P/Invoke. The C++ dll has a dependency from a third-party dll. That third party dll calls LoadLibrary to dynamically load libeay32.dll, an OpenSSL dependency.
After doing several tests I found out that the .NET application works correctly in Windows 10 but fails in some deployments using Windows 7. The cause of the failure is because the .NET process is not loading libeay32.dll. I tried placing libeay32.dll in the same directory as the process and in the System folder (having in mind the Dynamically load search order) but the failure persisted in Windows 7 32 bits only. Furthermore, if I called the API dll from a C++ console application it worked without issues in all platforms. To solve the problem I called LoadLibrary in the .NET application, before making the P/Invoke calls to the C++ API, and it worked in all target platforms (Windows 10/7 32 and 64 bits).
Why would LoadLibrary fail to load libeay32.dll in Windows 7 but not Windows 10 if called from the C++ dll dependency of the API called using P/Invoke?
Edit
Some notes from comments:
All the compiled assemblies are targeted for x86 architecture.
Before posting the question, I verified that no dependencies files
where missing, using dependency walker.
Likely because the dll is depending on some files that are missing. Use dependency walker and see what files it requires. Check on both systems. The tool will show you in red the missing files. Do not blindly copy the files.See what they are, what runtime or setup is required to deploy them, and deploy them properly.
.Net applications can be built with AnyCPU as their target and run in both 64 and 32 bit modes, but if you choose AnyCPU for your target the operating system will choose one based on it's preference. What this can mean if you have native dependencies is that the library that you're depending on can't be loaded because you're running in the wrong bitness. If you can constrain the application to the bitness you're expecting it might work better.
I have a problem with using c# .dll files into my ElectronJS app on linux. I know that Electron-Edge helps to run .NET in Node.js on Electron. But if it`s possible to use c# .dll on linux in this case?
Depends. Check out compatibility table at https://github.com/tjanczuk/edge - if dll is targeted coreCLR and if linux system has core.net installed, those might work for some. If you're dll isn't targeted to coreCLR, then it's pretty much impossible.
I'm trying to embed SQLite into my portable C# .NET 2.0 application rather than having the DLL files included in the distribution folder. However, to embed SQLite, I cannot use the Mixed-Mode libraries provided by PHXSoftware. Instead, I am using their 'Managed Only' version.
This works fine on 32-bit computers, but when it's running on a 64-bit machine, it throws a format exception. As I found out from here: http://sqlite.phxsoftware.com/forums/p/2564/9939.aspx I need to load the unmanaged sqlite3.dll manually in the required architecture format first before I use the managed libraries.
That's where I fall short. I cannot find a 64-bit version of SQLite to include along with the 32-bit one. Can anyone help? Dare I say, does anyone have any better ideas?
I'd recommend you build the source yourself. It's very straight-forward to do. Especially considering Sqlite offers amalgamation source.
Here are the compiler pre-processor defines I use for a 64-bit release build:
WIN64 NDEBUG
_WINDOWS
_USRDLL
NO_TCL
_CRT_SECURE_NO_DEPRECATE
THREADSAFE=1
TEMP_STORE=1
SQLITE_MAX_EXPR_DEPTH=0
Here are the compiler pre-processor defines I use for a 32-bit release build:
WIN32
NDEBUG
_WINDOWS
_USRDLL
NO_TCL
_CRT_SECURE_NO_DEPRECATE
THREADSAFE=1
TEMP_STORE=1
SQLITE_MAX_EXPR_DEPTH=0
The System.Data.SQLite fork has x86/x64 binaries for .Net 2, 3.5, and 4. Downloads are here.
Update:
Another possible solution is to target your application for x86 platform and just use the x86 SQLite libraries. If your application doesn't require x64 features targeting the x86 platform will greatly reduce the complexity of your deployment.
How do I create an app that is:
lightweight: I am guessing don't require .NET frameworks maybe?
portable: runs without installing and saves data in the app directory, so i can just move the folder or maybe even the exe?
this is just a personal experiment: i want to try create a simple todo list app that has the above attributes
I am thinking:
C#/WPF (but requires .NET framework, I can explore client profile thogh)
Appcelerator Titanium (i think this will be lightweight & good enough? I do not know if I can have a portable titanium app though)
It is almost portable if the target machines have .NET Framework installed.
NDepend is such a product, which is built against .NET 2.0 and runs fine on Windows Vista, Windows 7, and other Windows if you manually install .NET 2.0 before.
Personally, it is not hard to write an application launcher in native languages such as C++/Delphi to detect whether the target machine has .NET. If .NET is not yet installed, this launcher can display a warning or help install the framework automatically. (Even some installers allow you to do this.)
If you want to write it in C#, you either need the .NET framework or the Mono framework. Either way you need it. Thankfully .NET 2.0 is pretty ubiquitous.
By default, .NET uses xcopy deployment, so you can just copy the executable and any necessary DLLs around in a directory. It doesn't need to be "installed" unless you explicitly create external dependencies.
#jiewmeng, here i leave a few keys to build an portable application
If the application need save additional data like configuration files o data files , must be saved to the same folder of the exe application or an child folder of the application.
The application should not read/write configuration data to the Windows registry or in the %Appdata% folder.
avoid the use of external dependencies like ocx o dll files, that need to register in the system.
try to use an language wich makes native applications without framerworks dependence a good recomendation is use Delphi.
If you want to use .Net language, choose a version of .Net framework, that is in common use in most of the systems like the Microsoft .Net 2.0
Use Delphi, it's always portable and smaller
I have a program that requires both x64 and x86 dlls (it figures out which ones it needs at run time), but when trying to create a setup, it complains:
File AlphaVSS.WinXP.x64.dll' targeting 'AMD64' is not compatible with th project's target platform 'x86'
File AlphaVSS.Win2003.x64.dll' targeting 'AMD64' is not compatible with th project's target platform 'x86'
File AlphaVSS.Win2008.x64.dll' targeting 'AMD64' is not compatible with th project's target platform 'x86'
How can I make my setup target both platforms like my program does?
The MSI created by the setup project (in Visual Studio) can only target one platform at a time. Your option is to either make 2 MSI's, merge them together and make a custom setup boot strapper that choose between the two.
There are some 3rd party products,like Advanced Installer for example, that can do this for you.
I ran into this too and wrote a blog post about my solution:
deflate the file using deflate.exe, naming it with a different extension (e.g. .x64)
add it to your main project as a content file
add a custom action project to your solution
add the custom action to the setup projects "Install" custom actions
inflate the file inside the custom actions Install method using
System.IO.Compression.DeflateStream (see code above)
do a little dance around your desk, down the hall, and past as many coworkers as you care to annoy :)
The deflate.exe file can be downloaded from its repository on google code.
.Net has an "Any CPU" option. It's tempting to think of it as more of a "generic" option that's going to only use the lesser x86 features, but really it lets the JIT compiler on each machine pick the appropriate cpu type for that machine.
The only time you shouldn't use it is if you know you have dependencies or requirements that aren't good for one architecture or the other. For example: you know you need a lot of ram, you have a dependancy on a 32-bit native dll, or you want to pre-compile the app.
There's a danger here because you have a platform-specific dll dependancy. But you have dlls for both types and it sounds like you know how to pick the right one at runtime. So will the 'Any CPU' option work for you?
Open a deployment project.
In the Solution Explorer, select the deployment project.
In the Properties window, select the TargetPlatform property.
Choose either Itanium for an Intel Itanium 64-bit platform, or x64 for any other 64-bit platform (such as AMD64 and EM64T instruction sets).
At installation time, an error will be raised and installation will be halted if the target computer is not compatible with the specified platform.