This project has moved and is read-only. For the latest updates, please go here.

WCF Configuration for Excel Add-In

Apr 16, 2012 at 2:45 PM


First thanks for the great library.

I'm developing an Excel Add-In that needs to communiccate using a WCF service. Therfeore i neet my Add-In to load the app.config that i added to my project. Unfortuantelly Excel simply ignores the config file and the solution to directly edit the Excel.exe.config is a no-go for me.

Could you give me a hint where i can tell Excel/.Net config system to load my file and make WCF configuration work. The Project is based on the COMAddinRibbonExample you ship with the library.

Thanks in advance for any kind of help.

kind regards,

Apr 16, 2012 at 8:32 PM

Hello Chris,

I know this problem from my own projects and i dont have a simple solution for :(
What i do in this case is to shift the communication in a service or simple .exe assembly.
in other words, create a local .exe programm, this programm do all the things with WCF and provide these functionality to other local programs, also your addin. the easiest way to realize them is the COM Running Object Table. .NET still missing a lot shared features for desktop application development.
btw: this is a typical pattern. its not allowed for an Addin to establish an internet connection, you run here as an InProc Server, for local or external Firewall, the HostApplication is the bad guy here. Its a better way to shift the communication in an external process and provide some configuration for administrators.
if you need help about local process to process communication in .NET then gimme a sign.


Apr 16, 2012 at 9:01 PM
Edited Apr 16, 2012 at 9:11 PM


Thanks a lot for your answer. So if i understand correctly there is simply no "best practice" solution for using WCF directly from the Add-In code... good to know, this is my first Office Add-In and you saved me from a lot of headache. As i have not done any process communication on the windows platform it would be really great if you can give me hint to the right sources on the net to get into this stuff.

[EDIT]: Some googling resulted in the possibility to use WCF over named pipes. Do you have any experience with that, as WCF is a technology i'm familiar with. Or is there any "hidden" office feature preventing that from working...

thanks a lot,


Apr 16, 2012 at 10:39 PM

hello chris,

[if you a german native speaker please gimme a hint].

first: i have experience with named pipes as a nice alternative to shared memory, its okay to push signals but not anyone else. 
Preliminary: What is the Running Object Table?
The Running Object Table(also known as ROT) is a systemwide table in memory for running COM Components. Its easy to accesing these components with one call at runtime, also for .NET Components(with some prequisits)

I use the Running Object Table most of the time.
The Running Object Table is great but works only in the same user context. for example. a windows service runs typical as Account:LocalSystem and typical programm runs in the context of the current user. The Running Object Table doenst support these situtation(safety first) The WIN32 API makes sure all calls are guilty in the current user context.

What you have to dor for ROT Support:
For the server:
You can create a typical .NET class with some COM attributes. make sure the program is already running.(Autostart) any client can accesing these Component now in local desktop environment with one call. the office applications are usable in the same way. what i have to say is: NET doesnt suppport desktop application development. you need some line of code to create an entry. thats all:

For the clients:  .NET Clients have to call Marshall.GetRunnningObject(with the progID given by the server) this is the same method you have called for runnig Office instances. Office use COM all of the the the time. For full development support you have to include the type library definition from the server application. now you can cast the object from the table to your type given by the libary.
Summary: COM is an ummanaged standard and resolves problems you never kown in .NET(by design). But anyway, the basic idea is simple. Create a server and publish a type library.(These type library includes the server) these type library use client developers in her local programs. the type library contains stupid type definitions(not real code). a client converts the table object at runtime in a type from the published type library. the type library can use the objects now but keep in your mind. the objects are COM Proxies. i can create a sample solution for you with a server and a client. helpfull?


Apr 17, 2012 at 7:51 AM


[Ja ich bin aus wien, also schreib ich jetzt mal einfach in Deutsch weiter. ]

Ich bin deswegen auf WCF mit Named Pipes gekommen weil ich da die Technologie schon kenne bzw. schon viel mit WCF gemacht haben.Aber schön langsam dämmert mir das ich an der ganzen COM Interop problematik nicht vorbeikommen werde... bin bis jetzt in der Windowswelt mit purem .Net/Managed Code durchgekommen (primär Web Apps/LOB Applikationen etc).

Also ROT bietet mir zugang zu den laufenden Programen wenn ich das richtig verstehe, und aus der kann ich mir dann mein Interface Casten? Wie spielt das mit Async WCF zusammen BeginFoo/EndFoo? Ich kenne mich damit leider noch überhaupt nicht aus.

Wenn es für dich nicht zu viel Aufwand ist (will dich ich mit meinen Problemen aufhalten) würde ich das Angebot der example Solution gerne annehmen. 

Danke vielmals,


Apr 17, 2012 at 1:31 PM


Ich habe eine Solution in in den Downloadbereich gestellt: Local Shared Data Example
Die Solution demonstriert wie ich das üblicherweise in meinen Projekten umsetze.


Apr 17, 2012 at 1:58 PM

Hallo Sebastian,

Bin wirklich beeindruckt wieviel Aufwand Du in dieses Projekt und den Support steckst.

Vielen, vielen Dank,

Apr 18, 2012 at 1:51 AM
Edited Apr 18, 2012 at 1:52 AM

Hallo Christian,

Dankeschön! Natürlich kann ich nicht zu jeder Zeit an NetOffice arbeiten bzw. zeitnahen guten Support liefern aber diese Woche gehts gerade mal wieder ;)
Ein kurzer Hinweis zum Local Shared Data Example. Das Beispiel nutzt LateBinding und ist nur in der Lage einfache wie Typen wie String oder int vom Server ann den Client zu reichen. Es ist möglich dies auch earlyBind auszuführen, d.h. ohne Wrapper auf der Client-Seite. Man kann dabei auch mit echten Typen zur Entwicklungszeit arbeiten sowie eigene bzw. .NET Referenztypen wie XDocument weitergeben, dazu muss der Server jedoch als COM Komponente registriert werden was ein Deployment Erschwerniss bedeutet. In den meisten Fällen möchte man dies nicht und geht lieber den einfachen Weg daher habe ich mich für das LateBinding Beispiel entschieden.