I can't believe that I've been racking my brains for hours trying to figure out how to execute my .NET 2.0 code in Microsoft Excel 2003.  Hopefully this tidbit of information will save somebody else on the web some pain, frustration and time.

Punchline: You need a file called EXCEL.EXE.CONFIG in the same directory as EXCEL.EXE.

I created a class, written in C# and compiled with Visual Studio .NET 2005, with the .NET 2.0 Framework.  This class has a COM Interop wrapper so that it can consumed by ActiveX clients, most notably Excel 2003.  This class was compiled with the "Register for COM interop" setting in the properties turned on.  This arrangement autogenerates the GUIDs and COM interface for you, though I prefer to define my own COM interfaces manually in production code.

Here is a sample class in C#:

// COMClass.cs
using System.Windows.Forms;

namespace AnyCOMLib {
    public class COMClass {
        public void DoSomething() {
            MessageBox.Show("I did something.");
        }
    }
}

When I compiled this C# class, Visual Studio generated the DLL and TLB files I expected.  You can invoke it from a COM client, and it seems to work.  Here is the VB code:

Dim thing As Object
Set thing = CreateObject("AnyCOMLib.COMClass")
thing.DoSomething

I typed out a simple VBScript file with this code, and it worked.  A message box popped up saying "I did something.".

I created a simple VB 6.0 program with this code, and this worked, too.  The same message box displayed.

I created a VBA macro in Excel 2003.  This did not work.  I had a message that read:

Run-time error '-2147024894 (80070002)':
File or assembly name AnyCOMLib, or one of its dependencies, was not found.

So I thought - If I can create a VB6 DLL that can be called from Excel (true) and VB6 code can call my COM-wrapped C# code (also true) then why not create a VB6 DLL that calls my C# code and call that from Excel?  Unfortunately, Excel was not easily fooled by this subversion, and I continued to get the -2147024894 error.  That was a waste of time.

After spinning my wheels for too long, I finally found something helpful.  It turns out that I need a file named Excel.exe.config to be placed in the same directory as Excel.exe (typically at C:\Program Files\Microsoft Office\Office11).  That file has the following format:

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

You have to make sure that you have the correct supportedRuntime elements for the .NET runtime to work.

Here are links to the pages that helped me find out about this:

newsgroup microsoft.public.dotnet.framework.sdk

topic in msnewgroups.net

These were specifically targetted for MS Word, but the same method applies to running .NET assemblies in Excel 2003 as well.

I hope this helps somebody!

I have this habit of underestimating Microsoft, especially when it comes to the Office product line. At first blush, I was unimpressed with Office 2007.  To the average user, on first glance, it looks like Microsoft has traded one set of GUI widgets for another set of more complicated GUI widgets.  Combining this with the IT pundits declaring Office 2007 dead on arrival, I ignored it.  It's hard for me to get very excited about new widgets.

But last night I chanced upon the VSTO site (Visual Studio Tools for Office), and took a peek at this video.  I was amazed, and had to concede that Microsoft had pulled it off once again.  They have raised the bar for us programmers and expectations of users.  Briefly, your WinForms user controls can plug right into the Office environment, into either the ribbon or in the side docking panel.  Having worked on a system in C# that emulates a similar behavior, I was very interested, and a little disappointed that my craftily written code would soon be obsolete.

The thing about Office, and Word and Excel in particular, is that everyone uses it.  People get a warm fuzzy from software they use frequently and have some understanding of.  The number one feature request I get is to be able to download data into an Excel spreadsheet.  And VSTO 2005 SE (Second Edition) makes the job for programmers integrating into Office a whole lot better.  And it gives a compelling reason to upgrade to Office 2007.  This is only a minor upgrade for the end-user, but this is a sea-change upgrade for the Office developer.

VSTO 2005 SE will also allow Office programmers to achieve the type of service-oriented architecture that was difficult to achieve with our previous tools.  Since your user controls can do all those wonderful things like consume web services, chat over networks, query databases, access the file system, etc., the integration possibilities are nearly endless.  And the ability to dock your components right at the user's fingertips within the Office application makes the software convenient to summon for the end-user.

Now to work on my "reasons to upgrade" spiel for my clients...