".NET ends DLL Hell" … that was the message back in the days when the .NET Framework was still in beta.
With .NET, each assembly is easily versioned, global assembly registrations are versions specific and app developers are strongly encouraged to keep their assemblies local. And that can work to solve DLL Hell problems.
However, .NET doesn't completely solve the problem quite yet. There is still the case of unmanaged excutables loading the .NET Framework where DLL Hell is as bad as ever. I've blogged a few times about my
problems with BizTalk 2004,
NUnit's problem's with different framework versions are pretty well known as well and generally speaking having more than one version of the .NET framework installed is an issue for every unmanaged application, e.g. Internet Explorer, Word, etc. , and managed apps that explicitly load the runtime. The latest victim on my list of apps that break when installing a new version of the .NET Framework is the
IBF client.
I found that out, when I was preparing a demo for my last SQL Server XML features talk. I thought it would be a cool idea to consume a native
SQL Server 2005 web service in IBF. Unfortunately, I got an error from the smart tag loader from Excel, Outlook, Word and since IBF 1.5 added Internet Explorer support, I even got errors when launching IE. The error was:
There are problems with the Microsoft Information Bridge Framework 1.5 client. Run the client Setup program to repair the installation. The error details are stored in the event log.
But the details in the event log didn't really provide that much more information:
Information Bridge cannot start because Microsoft .NET Framework 1.1 failed. Return Code: 80131604
Since I had the smart tag running on a different VPC image that didn't have SQL Server 2005 or a CTP of .NET installed I suspected once again issues with loading the wrong version of the .NET framework.
When troubleshooting my BizTalk issues I found how you can configure
applications to load specific runtime versions. With IBF, I just had to find where I needed to add these configurations. With some help from Ted Howard and Michael Kiselman from the IBF team I found that I need to add .NET app.config files for the unmanaged(!) applications that host the IBF pane, i.e. Word and Excel. That's pretty obvious actually, if you know that Fusion, the .NET assembly loader, does look for app.config files for unmanaged and managed executables alike. Adding WinWord.exe.config, Excel.exe.config, Outlook.exe.config files in \Program Files\Microsoft Office\OFFICE11 for Word, Excel and Outlook and Iexplore.exe.config in \Program Files\Internet Explorer for Internet Explorer with the following entries:
<?xml version="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v1.1.4322" />
</startup>
</configuration>
fixes the smart tag problems just fine.
Now I still have some issues trying to run
VSTO solutions on that
VPC image, but I haven't had a chance to get to the bottom of those yet.