LINQPad 5 AnyCPU error - BadImageFormatException on IBM.Data.DB2.dll

[maximpashuk]

Windows 10 64-bit.

If using LINQPad 5 - linq2db plugin works fine. if using LINQPad 5 AnyCPU - linq2db plugin throws exception

I think this happens because IBM.Data.DB2.dll has platform target x86 If I open IBM.Data.DB2.dll from Redist folder in this repositiry in JetBrains dotPeek, I can see picture

So I think linq2db plugin should provide two versions on IBM.Data.DB2.dll - x86 and x64 bit editions. You can do this using bindingRedirect feature.

[ili]

That would be great if possible. Do you know if x64 IBM.Data.*.dll and if yes where can we get them?

[maximpashuk]

You know, I am not using DB2 at all. Exception I get thrown when I want to connect to MS SQL Server.

But I googled a link http://www-01.ibm.com/support/docview.wss?rs=4020&uid=swg27016878

Hope this helps.

I can see that client libraries used in linq2db is outdated (version 9.7 used, but current is 11.1). I think core lin2db project should be updated to support both x86 and x64 versions.

As for me, I am not sure should linq2db support DB2 at all.

[ili]

Thanks a lot!

[jakesays-old]

I just came across this issue. My suggestion is to allow the linqpad driver to function when provider dlls are missing so that the ones we can delete the ones we dont need.

[NimaAra]

Any update on this please?

[ili]

In next versions we'll switch off loading x86 providers in 64 bit environment. For now I can only suggest not using Any CPU build :(

[NimaAra]

okay, sounds good. Any idea when the next version will be out?

[halleck1]

Unfortunately, the fix that you did Igor is not really working (see screenshot below). The problem still exists with the change in the screenshot because the check is done in the runtime, while the BadImageFormatException happens during the assembly loading and binding. Unfortunately, the only real fix for LINQPad AnyCPU on 64 bit OS is to remove all references to the offending assemblies (DB2, Informix and Oracle Native).

I did it and it works after rebuild. Just in case you want to incorporate the changes Igor, I'm also attaching the diff file.

linq2db.patch.zip

[sdanyliv]

Unfortunately we need more clever solution with dynamic assembly loading.

[jogibear9988]

a try catch around does not help?

[sdanyliv]

Project has references, so libraries will be loaded automatically. And proposed solution just removes a lot of providers that do not support x64 mode.

[jogibear9988]

Are the Librarys only referenced or are they also used?

[halleck1]

The libraries are referenced and hence are automatically loaded by .NET Fusion (assembly loading code).

There is no clever solution unfortunately unless you want to resort to dynamic assembly loading and wrapping their types. The alternative is rather to produce 2 builds of plugin for x86 and x64 platforms with preprocessor conditions removing the offending pieces of code.

[sdanyliv]

It is not too hard to load assemblies dynamically. But i have not time do do that right now.

[halleck1]

It's not hard, but you'd need to re-wrap every single class from them in your custom loader. It's just going to be a pain in the neck.

The other alternative could be to host the main plugin entry point in the new dll which would hook up to the AppDomain.CurrentDomain.AssemblyResolve event and would suppress the exception on 64 bit OS. It would then need to hide those specific providers from the UI as well.

[halleck1]

Also, for anyone else looking for the plugin which would work on 64 bit OS - here's the build that works for me. linq2db.LINQPad.zip

[sdanyliv]

Working on version that loads data providers dynamically, expect this after 2.0 release.

[sdanyliv]

Fixed in #11