Feb 15, 09:38 PM by Steve | Binary Incompatibilty
Posted in Work & Programming
I spent the last two days at work chasing my tail trying to figure out why a DLL, when recompiled with a trivial change, suddenly (and dramatically) stopped working. It still didn’t work when we recompiled it without the change. Things were complicated by the fact that the client of the DLL was in FoxPro^ick^, the DLL was VB6, and it called some .NET assemblies through COM interop. I’ve been around COM so long I know it very well, but FoxPro I know nothing about and .NET versioning and interop is still very mysterious.
Anyway, to make a long and boring story short, it turns out that the problem was caused by the .NET assemblies having been recompiled on the build machine at some point, without incrementing the version or build number. The interfaces in the type libraries for the COM interop had jumbled around and when the DLL was compiled against these, it was no longer compatibile with the original .NET assemblies.
You see, with “early binding”, the memory offsets for the function entry points (the vtable) are compiled into the DLL. However, since the new type library had jumbled things up, the entry points didn’t match the original type library and we were esentially calling the wrong functions. I extracted the type libraries from the released assembies, placed them on the build machine, and everything was happy.
I should have figured it out faster; I’ve seen this kind of thing before. The version numbers threw me and I assumed they were the same, and didn’t look into it deeper. It wasn’t until I extracted the IDL from the released assemblies and compared that against the assemblies on the build machine that I realized they had been rebuilt, and then all of the pieces fell into place.
<< 23 Minutes of Pain and Suffering
