I mean for which platform, the particular DLL can be used. For example abc.dll can be used in 64 bit platform or 32 bit platform? How can I know it?
If you have the source-code for the dll's project file, you can go to the project->properties and find out the targeted platform (x86/x64).
However, please note that by default all .NET assemblies are set to target "any" platform. So, the particular dll you are referring to could be a generic one, and could be used on both type of platforms.
Related
NuGet documentation is quite clear: there is no target for plain Mono projects. We have Monoandroid, Monotouch, Monomac, and a few flavours of Xamarin for various platforms.
On one hand, if Mono is binary compatible to .NET, it shouldn't need different DLLs. And indeed "Mono is binary compatible with Windows. Which means that you can run binaries produced by .NET compilers from Microsoft and other vendors." according to the Mono FAQ.
On the other hand, "Mono does not have every .NET API implemented and when executing a binary from Windows that consumes an unimplemented API you might get an obscure message about tokens not being found."
So I think we need a specific Mono target. Am I missing something?
Your point is absolutely correct, but as everything in opesource - you need to implement it yourself (or hire me :) )
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
I am trying to use the SQLite's .Net DLL to access some data on a local SQLite database. The problem is that i need a way arround this error because i need to develop a software for 32/64 bits platforms (by using VB.Net not C#).
How can i stick to the 32bit version of the DLL to allow 32bit users of my program use it too?
If it's not possible to work with the 32bit version of SQLite's DLL, is it possible to include both versions in my Installer and programaticly choose which version of the DLL should be used?
Or..is there any other way to access SQLite databases without this particular DLL? (Things in C/C++ are much easier when it comes to SQLite usage as i remember)
Thanks!
If you change your Target Platform to x86 instead of AnyCPU your code will be emitted as 32bit code also on 64bit systems and you could use just the 32bit dll of SQLite.
If you think that you are loosing some value working exclusively with x86 then I can give you this reference where the PRO and CONS of AnyCpu are critically examined.
To change the Target Platform use:
Menu BUILD, then Configuration Manager
Choose x86 from the Active Solution Platform combo.
If you don't have an x86 choice,
choose New and Select x86 and copy the default settings from AnyCpu.
System.Data.SQLite (SDS) is apparently the most popular way to use SQLite from a .Net application.
I was wondering if
SDS requires shipping the SQLite DLL in addition, or if SDS includes
the SQLite source code, and
SDS can be statically compiled into a
VB.Net application of it can only be shipped as a DLL?
Thank you.
To expand on my comment, SDS is a .net wrapper for unmanaged code, so you will need to ship your release code with a copy of the DLL.
As Steve mentions, there are 32 and 64bit versions of the DLL, and as i discovered after much frustration, you must have the corresponding visual c++ runtime installed on the target machine, so if you deploy the 32bit version onto a 64bit machine, it will need the 32bit c++ runtime environment installed.
An alternative that i am currently looking into but havent had time to test is csharpe-sqlite, a pure .net implementation:
http://code.google.com/p/csharp-sqlite/
Coded in c# as the name suggests, but of course usable in any .net language including vb.net
Actually it's quite easy to compile System.Data.SQLite.dll to the does not require C++ runtime. For example if you download source code and follow the build procedures you'll find statically linked (no C/C++ runtime required) copy of System.Data.SQLite.dll in the following path:
<your-src-root>\bin\<2008 or 2010>\<Win32 or x64>\ReleaseStatic
For example if your source is in C:\Work\sqlite-netFx-source-1.0.80.0 then statically linked binary for Win32 and .NET 3.5 (VS 2008) will be located in:
C:\Work\sqlite-netFx-source-1.0.80.0\bin\2008\Win32\ReleaseStatic
Furthermore since System.Data.SQLite.dll is a mixed-mode assembly consisting of a managed .netmodule and native .obj file linked together using link.exe, it is possible to build your app as a .netmodule as well and link it together with SQLite into a single mixed mode assembly.
The resulting assembly will still be either Win32 or x64, however since almost all x64 machines will have no problem running Win32 code you can just settle on Win32 as long as:
Your app is an .exe or a .dll the is always loaded into a Win32 process, and
You don't use any of x64 specific advantages such as larger address space or using unmanaged code available only in x64
I am creating a wrapper around a native lib, which comes in both 32 & 64 bit flavors. I have a fairly complex C++/CLR project that includes a number of header files from the native libs. I got it to work fine on x32, but now I'm not sure how to provide an alternative x64 build.
Can someone outline the steps to create such project?
Various defines depend on _WIN32 / _WIN64, so must be multiple projects?
Both x32/x64 native libs have identical file names. Currently the lib ref is done with #pragma comment (lib, "xxxxxx.lib"). How should this be changed?
Lastly - VS2008 has only Win32 platform listed, not Win64 (I do have x64 VS2008 component installed).
Thanks!
Normally it is sufficient to select the drop down which says win32 (next to the Debug/Release one on the toolbar) and selected "Configuration Manager". Then open the "Active Solution Platform" drop down and select New. Choose x64 type (which if it doesn't exist then 64bit compilers are not installed) and copy solution from the orignal Win32 one. Now your project can be built selectively by changing the drop down on the toolbar.
Normally it works more or less as is but you might want to consider tweaking a few pre-processor defines if only for the intellisense.
As for libraries, for platform ones (supplied as part of VS/PSDK) then you dont need to change anything. For your libraries you are wrapping then change the Additional Library Directories in the project properties to point to the 64bit directory.
Visual studio doesn't always install the 64 bit options.
It can be fixed by running the VS installer, choosing add/remove features, and checking the x64 feature.