Home » excel » .net – Making a C#-based Excel add-in run out-of-proc with minimal pain

.net – Making a C#-based Excel add-in run out-of-proc with minimal pain

Posted by: admin April 23, 2020 Leave a comment

Questions:

I have developed a prototype C# Excel 2003 add-in in VS2005 that supports an object with some simple calls, plus a separate RTD class, all sitting atop a large existing in-house C# stack.

It all works fine as-is, but…

I’m told that in order to avoid potential conflicts with other Excel add-ins that might want a different .Net run-time that I will have to push .Net code this out-of-proc.

1) Is this true?

2) Can this be done in such a way that the out-of-proc server is launched automatically on demand, is accessable to only the appropriate user (to simplify security issues) and doesn’t need elaborate installation, etc, etc?

3) If this can be done, how?

Currently my (COM-visible) class stubs start:

namespace SimpleAddinMockup1
{
    /// <summary>
    /// Main entry point from Excel for non-real-time methods.
    /// </summary>
    [ClassInterface(ClassInterfaceType.AutoDual), ComVisible(true)]
    public sealed class Main
    {

    ...
    }
}

and

namespace SimpleAddinMockup1
{
    /// <summary>
    /// In-proc real-time server facade for an Excel instance to our main server connection.
    /// </summary>
    /// Note: to throttle updates in Excel use 'Application.RTD.ThrottleInterval = nnn' for nnn ms between updates (default is 2000).
    /// See: http://msdn.microsoft.com/en-us/library/aa140060(office.10).aspx
    [ClassInterface(ClassInterfaceType.AutoDual), ComVisible(true)]
    public sealed class CPRTDServer : Excel.IRtdServer
    {

    ...

    }
}

Update: I would still be very keen to know if pushing the C# outproc is easy to do, eg declaratively…

How to&Answers:

It is true that, with the currently available CLR versions (1.0, 1.1, and 2.0), different versions of the CLR cannot coexist in one process. However, in theory, as long as Excel is configured to load the 2.0 CLR, there should not be any problems with 1.x add-in code and 2.0 add-in code coexisting. When any 1.x add-in code gets loaded, it should automatically be pointed at the 2.0 CLR, which is backward compatible.

There was a time when Excel was wired to NOT load the 2.0 CLR in order to address a specific compatibility problem (explained in the sidebar in this article), but this has been addressed with an Office update (KB908002) that can be installed separately or with your add-in’s installer (and should have been pushed by now anyway). With this update applied, Excel is supposed to load the latest available CLR version automatically.

Microsoft’s current plan is that, when the 4.0 CLR is released (with VS2010), it will be able to coexist in one process with the 2.0 CLR, so hopefully this will not be a problem going forward either.