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.
Related
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/
We have two applications that use ILNumerics and have run into the same issue with both. We use the mkl_custom.dll and during development the application runs fine. The dll in use during development sits in the bin32 folder automatically generated when downloading the ILNumerics from nuget. However when we install the applications we get "Unable to load DLL 'mkl_custom': The specified module could not be found. (Exception from HResult: 0x8007007E".
Here is what we have tried:
Building the application in Any CPU, x86.
Switching the bin32 to include the bin64 dll's and viсе-versa.
Running dependency walker and including all dll's that are needed.
Changing path variable.
We are using ILNumerics 3.3.3.0.
One of the dependencies for mkl_custom is msvcr*.dll. Packing this dll manually may work on some operating systems but not all. Make sure the target system has c++ runtime redistributable package installed.
This installs the msvcr dll correctly. Hopefully this should fix the issue
I have a project that is build on Any CPU configuration, .Net Framework 2.0, vs2008 with 32bit version of SQLite dll used in it.
Well this works fine on my 32 processor environment, but when i ran this project on 64bit processor environment i experienced
"Could not load file or assembly 'System.Data.SQLite, Version=1.0.66.0, Culture-neutral,
PublicKeyToken=db937bc2d44ff139' or one of its dependencies.
An attempt was made to load a program with an incorrect format."
I even tried adding 64 bit dll on my project but it did not work.
I have tried all the solutions but that did not work for me. Since i am bound to build the project on 32 bit machine, i need a way to run this tool on my 64 bit environment too.
Any suggestions/comments/improvements means a lot for me.
Thanks in Advance.
Compile your application using x86 configuration.
When dealing with dlls like SQLLite that are compiled for x86, your process must be running in x86 mode.
I find these steps can be used to deal with sqlite.
Download NuGet
open cmd and type nuget install System.Data.Sqlite -- note it will create a folder in your current directory
copy dlls from net20 folders to your solution like so.
Add a reference to System.Data.SQLite.dll
Make sure you copy both SQLite.Interop.dlls to your output dir
Hope it helps.
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.
I have three projects, ProjectA (exe), ProjectB (exe) and ProjectD (class library)
Project A references the System.Data.OracleClient.dll and ProjectD. Project B just references ProjectD. The 32-bit client version of oracle is installed and therefore ProjectA has to be a 32-bit application. Project B can be built as a 64-bit application.
Project A build settings:
Platform: Active (x86)
Platform target: x86
Project B build settings:
Platform: Active (Any CPU)
Platform target: Any CPU
My questions are what should the build settings be for ProjectD (the class library) and when ProjectA and ProjectB get built does it build ProjectD differently? A deeper explanation of the CLR would be great in terms of communications of the projects.
ProjectA and ProjectB are to be used on 64-bit Windows Server 2008. No installation, just standalone exe's.
Only the Platform target setting for the EXE project matters. That's the assembly that gets loaded first and determines the bitness of the entire process.
A DLL doesn't get a choice, it must be compatible with whatever was selected by the EXE project. Picking AnyCPU for a DLL project is therefore almost always the correct selection.
There are just a few cases where you'd use an explicit setting. You'd only do so if you know that the class library has a dependency on some kind of native code, like the Oracle provider, and that trying to run that native code in the wrong bitness produces a completely inscrutable exception. You can avoid that exception and get a (slightly) better one by picking the Platform target for the DLL, the program will fail with a BadImageFormatException early when it tries to load the assembly. Albeit that this exception isn't exactly a very informative one either. Some odds that an admin is going to try to reinstall the DLL a couple of times before deciding that the real problem is elsewhere.
So basic ground rules: pick x86 for the EXE project, AnyCPU for all other class library projects, a nastygram to Oracle for doing nothing to make this easy.
My questions are what should the build settings be for ProjectD (the
class library) and when ProjectA and ProjectB get built does it build
ProjectD differently? A deeper explanation of the CLR would be great
in terms of communications of the projects.
Just use Any CPU for your lib. It'll build a unique assembly that can be executed in both 32-bit en 64-bit environments.
Technically, the just in time compilation with either produce 32-bit code or 64-bit code at runtime.