Running IBF with the .NET Framework 2.0 installed
".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>
<configuration>
<startup>
<supportedRuntime version="v1.1.4322" />
</startup>
<supportedRuntime version="v1.1.4322" />
</startup>
</configuration>
fixes the smart tag problems just fine.