DLL Hell: A ghost from the past

It can be quite surprising how this ghost from the past can still haunt you in the era of .Net.

The Problem

We have a .Net Excel PlugIn, developed with ManagedXLL under .Net Framework 1.1 and we have been relying on Visual Studio 2003 to debug it (Run Excel, then "Attach to Process"). Today, however, this process suddenly stopped working. Visual Studio gives the following error message ("Unable to attach to process"? very "informative", I must add) when attemp to attach to Excel:

The Solution

It became quite obvious that this has something to do with .Net Runtime versioning when I realize the only difference is that I installed .Net 2.0 last Friday (Yeah, I know this makes me look like a caveman...). Visual Studio 2003 should work with .Net Framework 1.1 only. No surprises here. And we have set the PlugIn and ManagedXLL to work with .Net 1.1 exclusively. So why would it messes around with .Net Framework 2.0? After a couple attempts, I found a somewhat odd solution: to define a configuration file for Excel. Save the following as Excel.exe.config in the same directory as Excel.exe (requires Admin account):

<configuration>
   <startup>                                
      <supportedRuntime version="v1.1.4322"/>
   </startup>
</configuration>

It seems this config file would force Excel to load 1.1 version of the Runtime. But why would an unmanaged executable such as Excel require .Net runtime (even without the plugin) in the first place is beyond my understanding.