Implementing an Excel add-in in C # with minimal pain

Question

I developed an add-in for C # Excel 2003 add-ins in VS2005 that supports an object with some simple calls, as well as a separate RTD class, all sitting on a large existing C # internal stack.

Everything works fine as it is, but ...

I was told that in order to avoid possible conflicts with other Excel add-ons, which may require a different .Net version, I will have to click on the .Net code of this non-proc.

1) Is this true?

2) Is it possible to do this in such a way that the out-of-process server starts automatically on demand, is available only to the appropriate user (to simplify security problems) and does not require complex installation, etc. etc.?

3) If this can be done, how?

My (COM-visible) classes are currently running:

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 still really want to know whether it is easy to promote C # outproc, for example declaratively ...

Answer 1

It is true that with the current CLR versions (1.0, 1.1, and 2.0), different versions of the CLR cannot coexist in the same process. However, theoretically, while Excel is configured to load 2.0 CLR, there should be no problems with extension code 1.x and additional 2.0 code coexisting. When any add-in code 1.x is loaded, it should automatically point to the 2.0 CLR, which is backward compatible.

There was a time when Excel was connected to NOT load the 2.0 CLR to solve a specific compatibility problem (explained in the sidebar in this article ), but this was fixed with the Office update ( KB908002 ), which can be installed separately or with your add-in installer ( and in any case he should have been pushed). When using this update, Excel should automatically download the latest version of the CLR.

Microsoft's current plan says that with the release of 4.0 CLR (with VS2010), it will be able to coexist in the same process with CLR 2.0, so I hope this is not a problem either.