1

I've got a .NET application which uses a COM server. The COM server is registered on the machine where I run it, so when my code reaches new MyInterop.SomeObject() the appropriate MyComServer.exe is started.

However, as I'm debugging, I've got several copies of MyComServer.exe residing in different folders with different configuration files. I would like to specify which my app should load.

Two workarounds that I know of are:

  • I can re-register it every time (MyComServer.exe /regserver) before use. But I don't like to use a global solution for a local problem.
  • I start MyComServer.exe manually (it then runs as a standalone app) and the COM infrastructure will reuse this existing process. But that's not very automatable.

Is there anything more appropriate?

Vilx-
  • 104,512
  • 87
  • 279
  • 422

2 Answers2

1

The COM server .exe got started by your new MyInterop.SomeObject() call. You've no doubt got so many .exe's running because you terminated the program while debugging, without allowing .NET to shutdown properly and decrease the reference count in the finalizer thread. COM doesn't have a mechanism to clean-up these lost references. Simply use Taskmgr.exe, Process tab to kill the running instances.

COM has a mechanism to attach to a running instance of a server through the ROT (Running Object Table). This is however not something you can bolt on later, it has to be explicitly supported by the server. If you do have to option to tinker with the server then do consider making it an in-process server instead. Much less troublesome.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
0

You could try creating the config file dynamically based on debug version.

Alan Stephens
  • 569
  • 5
  • 14
  • Hm? And what if I want to run several instances of my app in parallel, each of which connects to a different server? – Vilx- Dec 06 '11 at 15:19
  • Ah, if you've got concurrent apps you'll need those different servers .. was originally going to suggest building multiple debug versions of the server .. though potential registry mess .. if I understand your last comment not sure what options you have. – Alan Stephens Dec 06 '11 at 15:34
  • Well, currently it's just a hypothetical scenario, and I hope I never actually have to do it... but I like to be prepared. So you're saying - COM does not allow such perversions? – Vilx- Dec 06 '11 at 15:35
  • well, if you have to re-build your COM server for each config file you'll have fewer options than reading from the config at runtime. I'm sure the latter would allow a solution but COM can get pretty messy. – Alan Stephens Dec 06 '11 at 15:44
  • It's more like there are several versions of the COM server on our testing servers ("servers" as in - physical machines), so it'd be nice to specify which one to use. Also, each of these COM servers has its own DB (hence the different configs), since the DB version and software version have to match. Oh, and since our software supports both MSSQL and Oracle, then each version also has two copies for this sake. – Vilx- Dec 06 '11 at 15:50
  • @Vilx- Most of your problems come from the fact you have multiple version of the COM server. There a reason for this? – Security Hound Dec 06 '11 at 16:00
  • It's an accounting application which gets updated pretty often. It's typical usage is as a standalone desktop application, but it also doubles as a COM server to allow other applications to integrate with it. There are actually other interfaces to it which are less fragile, but this one has been there historically and is still sometimes used as a poor-man's solution for integrating. – Vilx- Dec 06 '11 at 16:15