So there is this cool database called firebird, and it can be used embedded. the .net provider (as far as I understand) it uses the fbembed.dll, which comes in 2 flavors: 32 and 64 bits.
How does the .net data provider locates the correct one for the environment that is running in?
It does not select by itself. You have to have that 32bit/64bit dll in the current folder for the provider to load.
If the application is running in 32bit environment (32bit application in 32/64bit OS or AnyCPU application in 32bit OS), the provider will load DLL and expect it to be 32bit. Otherwise you will get bad image format error. Same applies for 64 bit environment.
For this reason, I always create MSI's of my application in two flavours - one with 32 bit dll and other with 64 bit. The application itself remains the same (AnyCPU) so the OS determines what DLL is required. I have been using Firebird embedded for more than 8 years now, and that practice has been easiest for me to follow.
Related
Using Firebird 2, we had to deploy 3 files with our applications to be able to connect to remote firebird servers:
fbclient.dll
msvcr80.dll
Microsoft.VC80.CRT.manifest
The first file was retrieved from the "normal" Firebird installer, the other 2 files from the "embedded" installer.
Firebird 4 doesn't provide an embedded installer, and I don't find proper information what to deploy for clients.
Reading this: https://ib-aid.com/download/docs/fb4migrationguide.html#_installing_client looks like Firebird 3 has lower demands. Is that the case? I just need communication-encryption and longer passwords, so FB3 would also be fine. (BTW, following the guide didn't bring success, otherwise I would not ask).
The minimum necessary files are listed in the document you link:
If we speak about installing Firebird client only, you need to have
fbclient.dll file. Firebird 4.0 client requires Microsoft Runtime C++
2017 with the same bitness as fbclient.dll. If Microsoft Runtime is
not installed, you may just copy it’s two files, msvcp140.dll and
vcruntime140.dll that are included in ZIP for Windows.
So the absolute minimum you need is fbclient.dll, and in some cases you may also need msvcp140.dll and vcruntime140.dll when those are not already installed on your system.
In addition, it is advisable to include firebird.msg for error messages, and for some use cases, adding the ICU files is advisable (if you use the functions of fbclient to render/parse WITH TIME ZONE types).
If you want wire compression, you'll also need zlib1.dll, and if you want to use Chacha wire encryption instead of the less secure ARC4, then you also need plugins/chacha.dll (the chacha.dll needs to be in a plugins folder relative to fbclient.dll).
All these libraries must be the same bitness as your application. As discussed in the comments, the problem seems to have been that you tried the 64-bit DLLs from a 64-bit Firebird installation, while your application was 32-bit.
If your application is 32-bit, then obtain the files from a 32-bit installation or zip kit, or look in the WOW64(*) folder of a 64-bit installation (from the installer, the 64-bit zip kit doesn't contain this directory). This WOW64 folder contains the 32-bit files fbclient.dll, msvcp140.dll and vcruntime140.dll (for the additional DLLs you need to use a 32-bit installer or zip kit).
* This follows the awkward Windows naming of 64-bit Windows having 64-bit files in %WINDIR%\System32, and 32-bit files in %WINDIR%\SysWOW64
I have a rather large application built in visual studio which runs in x86 and have recently had a need to integrate a library which is only built in x64. Is there a way to utilize an x64 dependency in x86 mode or do I need to build a seperate application, somehow call it then maybe pass the data back to the parent application via a socket or something???? Any Suggestions?
I resolved this issue by creating a second application to run in 64 and set up listeners for console output and error output in order to pass data back
We have a scenario where we require a plugin to do some custom steps in CRM 2011.
The client PC's are running 32 bit Outlook, due to the requierment for some silverlight applications extending crm, and Silverlight not supporting 64 bit.
Hence the plugins are failing when offline, presumably due to Outlook 32 bit not being able to launch 64bit plugin. The O/S's are all x64.
I have tried to deploy a 32 bit sampleplugin.dll to the CRM Server, but cannot register it, as I get a BadImageFormatException.
I just want to know if this is possible or not at all ?
I am guessing it's not possible, but just want some confirmation.
Thank,
Steve
You have to develop your plugin without a specific target architecture, this means you have to target Any CPU.
Dynamics CRM 2011 is 64 Bit on the server side. The plugin will be therefore executed in 64 Bit processes. That is the reason why you are getting the BadImageFormatException
You could not be sure, if you have 32 Bit or 64 Bit on the client side
In Visual Studio, are you explicitly targeting x64 when you build the plugins in VS? If so you might try All CPUs instead.
I have created a simple application of reading mail properties from a nsf file using Interop.Domino.dll, things works fine for 32 bit OS but when i attempt to run the same application under 64 bit OS i am unable to create LotusNotes Session , getting the COM Exception. Though i can run the same application on 64 bit by changing the plaform to "x86" but if i change the platform to "Any CPU" its not working.
I have few other dlls which are meanted for 64 bit machine so i need to keep the Platform to "Any CPU", but in this scenerio i am unable to register the Interop.Domino.dll
Is there any Solution to it.
Thanks and Regards,
Haseena
The Domino server api is available in x86 and x64 flavors, so you would need to build against the appropriate one. The client api is x86 only, and if you are linking to that, it would behave the way you describe.
My .net windows forms app won't run on Windows 7 64 bit. Error says ADODB not found. Giving it the dll (by putting it in with the program) then gives error that ADODB provider is not properly installed. How to fix this?
The app must run as a 32 bit process as OLEDB is not supported in 64 bit processes.