It feels like I'll never get this release out.
I'm currently facing an interesting flavour of DLL hell (tastes like bananas) resulting from copy-local assemblies that get loaded into the same application (Visual Studio) in different load contexts. Basically, ReSharper and Visual Studio Team Test both want to load Gallio.dll but they do it in different ways from different locations. This results in some rather curious behavior because two identical copies of the assembly will be loaded but they are nevertheless considered different from one another.
It would be nice if we could just tell ReSharper and Visual Studio Team Test to load my add-in assemblies from the Gallio installation path, but neither of them actually support that behavior. They both require their add-ins to be copied into very specific folders.
I can think of two possible fixes right now:
- Add some hacks to install a custom assembly resolver just in time at all entry points into the add-ins so that we can control more precisely how Gallio.dll gets loaded. That way we can avoid having multiple copies of Gallio.dll.
- Put Gallio.dll into the GAC.
I previously used option #1 for the Gallio ReSharper add-in. It was a real pain because I had to carefully instrument all entry points into the add-in and avoid referencing any Gallio types until the assembly resolver hook was installed. I ripped this brittle code out a couple of weeks ago since I figured just copying Gallio.dll locally would be good enough. (guess again!)
So option #2 really seems best. Keep in mind that the copy of Gallio in the GAC should only be used for external tools integration. I don't anticipate test assemblies or the basic standalone runner actually referring to anything in the GAC so Gallio should still be usable in-place without requiring any installation steps (except for these add-ins of course).
However, it's 4am now so I'm going to sleep on it for a little while. It may be that using the GAC will cause more headaches such as problems with the NAnt or MSBuild tasks that might also involve a little non-standard assembly resolver-foo of their own.
Next problem: Throw out NSIS (finally!) and rewrite the installer using WiX...
No comments:
Post a Comment