Hi all,

The bug tracking database (http://tracker.firebirdsql.org) is down
right now, so I'm emailing this to get it out there.

I've got a .NET 4.0 application that's using the Firebird ADO.NET
provider with an embedded Firebird 2.5 database. The .NET application
itself runs without changes on both 32- & 64-bit platforms. However,
I'd like to take advantage of 64-bit platforms if I'm running on one.

Currently, the 32- & 64-bit DLLs that ship with Firebird embedded have
**exactly** the same names. That means that I have to have to create
two subdirectories in my installation directory, one for 32-bit
Firebird DLLs & one for 64-bit Firebird DLLs, and then check the
bitness of my environment very early in my app's startup so that I can
dynamically add via the Win32 API SetDllDirectory the correct 32- or
64-bit Firebird directory. If the 64-bit DLLs had the suffix "64", I
would have to go through such machinations.

For example, the 32-bit DLLs could remain fbembed.dll, etc, but the
64-bit versions could have names like fbembed64.dll, etc. That way, I
can copy **all** of the Firebird DLLs into my application's normal bin
directory, and know that the .NET provider is going to pick up the
right DLLs based on the bitness of the currently executing
environment. That ensures that, without changes, my .NET app is
getting the max bitness available without my having to do anything.

WDYT? Seems easy enough to me to implement...

-matthew

--
mailto:matthew@...
skype:matthewadams12
yahoo:matthewadams
aol:matthewadams12
google-talk:matthewadams12@...
msn:matthew@...
http://matthewadams.me
http://www.linkedin.com/in/matthewadams