Your article is a great start to something I'm trying to do but with a Service "a la" AppServer.
Consider the idea of an AppServer similar to old DCOM days.
What I would like to do is create a .net service which creates a class factory similar to your server exe. Now, unless I'm missing something, a client application that needs to create an instance of a class factory (your singleton factory) running on the same box would need to use remoting UNLESS it runs in the same AppDomain.
You have not solved that problem yet - all you did was show that a class factory "coclass" (if you will) can be created by the server and used remotely via remoting and a tcp channel. I fail to see how I can allow an application in the same machine get the instance of the class factory without remoting involved.
In a nut shell, I was hoping your sample would solve what you said in the opening paragraph about the best of both worlds.
Please let me know if I am missing something - is there some magic in the activator that somehow will not create a channel if on the same box. If so, then why do we always see references to creating assemblies in the same app domain - I don't see where two exes will be in the same domain.
In the article I tried to show a singleton that is accessed in-process when needed or externally by remoting, whithout changing any code, but only some configuration files. So when you only need a single instance of your appserver, you can run the singleton in-process. When you need more instances of you appserver, you can instantiate the singleton in one of them. That instance of the appserver accesses the singleton in-process, while the others by remoting. In all the cases, anyway, (UI) clients access the singleton by remoting. So it seems I can't help with your problem.