Don't worry about rejecting advice if it means a big rewrite. I'll be curious to see what others suggest though.


Joining a Domain or Workgroup requires admin rights and is completed by rebooting, and it can have drastic consequences for lots of things on the local machine. No, you don't do this from an application or casually at all really. The issues aren't so much about you "being secure" as not breaking the security mechanisms in Windows, losing user accounts, various things like service configuration, etc.

As the quote I posted above suggests there is a way to force cross-domain DCOM to work using local machine accounts, but it requires that the same users and same passwords are on both machines. In a Workgroup situation you pretty much have no choice since there are no Domain controllers to establish other trust relationships anyway.

This bites all but trivial .Net coders all the time because Visual Studio uses DCOM for Remote Debugging:

VS Remote Debugging Across Workgroups or Domains


I really hesitate to encourage you on this path for a couple of reasons.

One, if you can't unravel the very simple Coffee Monitor sample you have a long way to go yet learning to write a successful DCOM server. There are many things that make sense for local COM that need to be done the opposite way for good results with DCOM. So you have a large investment in time to make yet even ignoring most DCOM configuration issues over a LAN (and here "LAN" means computers in the same Domain or Workgroup), i.e. just getting this working on one machine.

Then you have all of the LAN (same network) issues.

And then you get to all of the finicky cross-network issues.

At any stage you may run into an immovable object. This will likely lead to great disappointment.


So if you really want to follow this path I think you need to get the Coffee Monitor tutorial worked though and functioning, first on one computer, then between two in the same network (remember, network here is a software concept not hardware), then between two machines in different networks (probably Workgroups in your case). It is probably the simplest example you are going to find, since simple "OLE automation" à la Office applications doesn't really count.

At least you can get the mechanics worked out before you tackle anything as large as the application you are trying to ultimately create... and maybe get too far down a road that dead-ends on you.