Commented by: Greg (gregweb)

Attached is a potential patch that will address this issue. If the client dll is not specified and fbembed.dll exists in the %PROCESSOR_ARCHITECTURE% sub folder it will be used. Otherwise will revert to previous behavior.

Commented by: Yiannis Bourkelis (yiannis)

I had also done a similar suggestion here: http://firebird.1100200.n4.nabble.com/Suggestion-Firebird-Net-Provider-should-be-able-to-load-x86-or-x64-DLLs-automatically-td2272784.html

Since NET Framework allows an assembly to recognize when running on x86 or x64 version of windows, the FirebirdSql.Data.FirebirdClient.dll could load the appropriate version of fbembed.dll, firebird.msg, icuuc30.dll etc for each platform.

This could be done if inside the application's folder is an XML file where we could enter the paths of the x86 and x64 versions of firebird DLLs. For example:

FirebirdSql.Data.FirebirdClient.Options.xml

<Platform>
<x86 Path="\x86" />
<x64 Path="\x64" />
</Platform>

The path could be absolute or relative.

So, if FirebirdSql.Data.FirebirdClient.dll is located in the folder:
C:\MyApp\
the appropriate version of fbembed.dll, firebird.msg, icuuc30.dll etc for each platform will be located in the folders:
C:\MyApp\x86
C:\MyApp\x64

That way we could build our applications as "Any CPU" which is simpler than providing two different versions of our applications for each platform.

Commented by: @cincuranet

I don't think the `PROCESSOR_ARCHITECTURE` is a good idea. For `64bit` it returns `AMD64`, which is correct, but most people would expect `x64`. And to make it worse, this variable might not be set on Linux/UNIX systems.

But. This leaves me wondering. What's wrong with using `ClientLibrary` parameter? One can use any path (s)he wants, and frankly I don't think it's that difficult, is it?

Commented by: @cincuranet

Because this didn't get enough traction, I'm closing it. Feel free to comment so it can be reopened and reconsidered,