Dll-Hell with 3rd-party code

[Tobias_Loew]

Hi,

I'm developing on Windows. In my code I use IF 2013 but I've got 3rd-party code which is linked against the IF 2011 dlls. As all the IF dll have the same name in the different versions it is nearly impossible to ensure the correct dlls are loaded. It gets even worse when I'm trying to load my dlls into other processes that already use IF-dlls (e.g. Matlab).

Have you ever though about tagging your dlls with a version-number like msvc or mfc dlls (I don't mean an SxS mechanism, just a main dll versionnumber would be very helpful.)

regards

Tobias

[Tobias_Loew]

Comming back from an "offline" weekend, I'm very impressed about the resonance to my question.

The main version-problems I had was when a customer reported that his Matlab instance crashed when he tried to load a dll provided by me. It tourned out that the customer used a Matlab version from 2007 (iirc) and when my dll got loaded it used the quite old IF-dll from the Matlab-Path (local copy, no use of "Common-Files"-folder) and crashed as it was linked against the IF 2011 runtime. As I can't (and won't !) tell customers to delete dlls from their Matlab-installations, I already figured out that a local SxS installation of the correct IF-runtime with my dll seems to be the only possible way.

So, failrly speaking, I have a solution for the problem, but it is a massive weapon (assembly embedding, additional local SxS installation) to work around something that easily could be solved by simly tagging the IF-dll-names with the version. So, I was hoping for some easier/better solution.

[IanH]

That's one approach I hadn't considered - but I think that means you'll end up with two instances of the Fortran runtime active in the same process.  If you have interaction between those runtimes then things could go astray (though I can't think of any reason why that interaction could happen without explicit programmer action).

[Steven_L_Intel1]

We investigated using side-by-side (SxS) assemblies,. but Microsoft engineers advised us not to do so. I had hoped at the time that they were coming up with an alternative solution, but no. For the present, we're stuck with what we have.

When you install the Intel Fortran redistributables. it adds the paths to those at the front of PATH. But if MATLAB has its own copies of the DLLs in its own executable directory, they will be used first.