Commented by: Sean Leyne (seanleyne)

This is not a project issue -- this is an issue with your deployment/installation approach. You should only be installing 1 version of the DLL into the application folder, since the application/OS can only run using 1 version.

Commented by: Matthew Adams (matthewadams)

What you say is true, Sean, for native applications, but not for .NET binaries. The same .NET binary can run on both 32- & 64-bit platforms. The Firebird http://ADO.NET Provider is a case in point; there are no separate 32- or 64-bit distributions, only the one distribution that runs via .NET on both 32- & 64-bit platforms.

The Firebird http://ADO.NET Provider currently requires work on our part, when it could be easily done by the provider itself, but it requires that the 64-bit fbembed.dll change its declared dependencies to be on differently-named 64-bit DLLs.

Commented by: Sean Leyne (seanleyne)

Matthen, yes there can be 32 and 64 bit applications, but that doesn't mean you need to install both. You can detect whether the OS is 32 or 64 bit and then install the appropriate DLLs/EXEs, in the appropriate paths. (A lot of install builders will do this for you).

You do not need to be detecting this at runtime.

Commented by: Matthew Adams (matthewadams)

One virtue of a programmer is laziness (http://c2.com/cgi/wiki?LazinessImpatienceHubris). I don't want to have to branch our installation logic to install 32- or 64-bit DLLs. I just want to slam 'em all in the bin directory and forget it, knowing the .NET provider will do the right thing.

Commented by: @hvlad

I'm agree with Sean

Commented by: Sean Leyne (seanleyne)

I understand laziness, my wife says that I am a Knight of the Round Table of Laziness, but I don't expect others to work so that I can be lazy -- which is what this case seems to be an example of.

Commented by: Matthew Adams (matthewadams)

Touché, Sir Sean of the Knights of the Round Table of Laziness. I bow to your reverence. Suppose, instead, venerable warrior, that I myself do the work and submit a patch so that others need not? Would that King Arthur then knight me for so greatly benefiting his lazy knights...

Commented by: Sean Leyne (seanleyne)

Matthew, personally, I don't see that there is anything to patch from a project perspective. You have a "unique" deployment approach, so this is something which only affects you.

Other project members may not agree, I will look for/await their feedback...

Commented by: @hvlad

Matthew,

i'm agree with Sean that what you ask is installer's job. It's not about our or your laziness. We can't and don't want to change a way how Firebird is distributed just because you think it should be distributed differently. Also think about applications which already loaded fbembed.dll (or fbclient.dll) and will be broken if we'll rename it. You can rename fbembed.dll at your application distribution, if you really need it.

Commented by: @dyemanov

I'd also prefer to leave the current distribution (32-bit and 64-bit binaries sharing the same name) in piece.

Commented by: Sean Leyne (seanleyne)

Based on the feedback of project's lead developer (Dmitry) and 2 other project admins (Vlad and myself), this case will not proceed.

Commented by: Matthew Adams (matthewadams)

Fair enough.