I have a C++/CLI Managed Library that I built both for x86 and x64.
I use this library in a C# Project that I am building for Any CPU. And I am using the x64 Version of my C++/CLI Managed Library.
After looking at this question where some techniques to build using either the x86 or x64 dlls according the platform of your project.
I wonder, if it is possible to indicate the designer to use the x86 version of my library, while my application could still be using the x64?
Right now my designer shows errors if I try to use in my View Models anything that belongs to the x64 Library.
Related
I am currently facing a problem where I am referencing a 32bit dll. I tried changing the platform to 86bit which works fine but the requirements are to use a 64bit or 'Any CPU'. When I use the 'Any CPU' platform it somehow does not pick up the dll
Is there a way of using a 32bit dll in 64bit program?
I also read about a workaround of 'wrapping' which was not clear... can someone elaborate
Is there a way of using a 32bit dll in 64bit program?
In the same process: No.*
However, you could host the dll in a separate child process via something like the Add In Framework (which supports out of process workers).
* Note, I am assuming this dll is either natively compiled, or .NET but compiled explicitly for 32bit only.
I'm using OpenCvSharp with visual studio 2013. I've installed it through Nuget and it is working fine.
But when I deploy the application it has a DLL directory that has 128M. 128M for x86 and 128M for 64 indeed.
I'm using basically the functions from HighGui and Core. When I remove the DLLs, OpenCvSharp throws an exception when loaded.
I've tried recompile OpenCvSharp without success (this is another question) and even Recompile OpenCV to get smaller DLLs.
Is there any way of loading only the needed DLLs and point out which one can be removed?
The size of your deployment sounds quite large...
When I create a test project with Nuget package OpenCvSharp-AnyCPU 2.4.10 I get:
1.22MB for the net40 assemblies
32MB for the x64 dlls
29MB for the x86 dlls
OpenCvSharp loads the native dlls on demand (i.e. when the C# code needs the native code) so you could remove dlls which your code never uses, but you'd have to check the source or find this out by trial and error.
By default your C# app will build targeting Any CPU which means both sets of dlls are needed, but you could set Platform target: x86 in build properties and just not deploy the x64 dlls.
So i'm kind of new to programming but i started using Xamarin and i tried to add NHunspell package from NuGet on Xamarin Studio, it downloads it and the .dlls appear in Resources and NHunspell appear in Packets, but it doesn't appear in References and so when i try "using NHunspell" it doesn't work.
I have tried running the "install" script with Power Shell but apparently nothing changed.
How do I add NHunspell to my project?
Not every .NET library is compatible with Xamarin. They generally have to be either built against the appropriate Xamarin Framework, or build using a compatible PCL Profile.
scan.xamarin.com can tell you if a given DLL is compatible or not.
As I answered you already per Email the problem with NHunspell is that it is in fact an wrapper to Hunspell. Hunspell is written in c or C++ so it compiles to a native Dll. At this time the build produces two native DLLs for Windows 32 Bit and 64Bit. It would be necessary to produce native DLLs for ARM / Android or Linux or ... to use it on these platforms. I will do this for X86/X64 Linux in the future. But at the moment I'm snowed under so there is no timeframe. If you or someone else is willing to contribute, you're welcome.
BTW. NHunspell has an resolver for the correct native DLL. If your project has the native DLLs in the output directory, it resolves X86 or x64 in windows. You can do this in Xamarin studio by adding the native DLLs in your project and configure "copy to output directory". But this works only in Windows.
The latest packages (without NuGet) are here:
http://download.crawler-lib.net/NHunspell/
I've written a C++/CLI DLL to be used with my GUI .NET application. On my local development machine, everything works as expected. My GUI application says that it cannot load my C++/CLI DLL on any other machine, though. It always says that it cannot load my DLL or one of its' dependencies. So I was thinking maybe it's some missing C runtime or something?
Are there any prerequisites that need to be installed prior to using my C++/CLI DLL on another machine? Strictly from a .NET perspective, or C++ run-time, or whatever.
Edit: Sorry. It's VS2012, .NET 4.0, Platform Toolset v110.
In addition to the dependencies that other .Net languages have (e.g., the .Net framework), C++/CLI requires the C++ runtime.
You can download the C++ runtime redistributable for VS 2012 from Microsoft. Select the x86 or x64 version based on the compilation setting of your C++/CLI assembly, not the version of Windows the target machine is running.
Note that this is the runtime for Release compiles only. Debug compiles use a different runtime, which does not have a redistributable, and is only installed with Visual Studio.
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.