描述:
com可以作为dll,exe服务。
1）如果作为exe服务，我们可以创建本地或远程进程服务，Allowing merging proxy/stub code 就灰掉了，这说明什么？？？exe com的proxy/stub到底是以什么样的形式出现和发布？
2）作为dll com可以作为分布式com服务远程调用吗？是不是客户需要也要安装和注册dcom？如果可以，是不是服务端还要用dllhost.exe 代理将dll com创建为一个可以独立运行的com服务进程呢(当然两端的DConfig配置少不了的)？
请com高手澄清说法，呵呵！
我的看法是，学了com很长时间，对理论和一些机制还是有些认识。不过在高级特性如线程与安全模型，还是光看没做，工作很少涉及的。等等。感觉xml webservice 学起来容易，使用方便，配置也不成问题。java 在webservice 组件方面有ejb强大的支撑，使用也不错。
解决方案1:
1）EXE的COM服务器必定是进程外激活，代理/存根代码是必需的，所以不用选择。
2）dll可以用于进程外/远程激活，这种方式往往用于已有的dll组件的远程使用，但是已有组件的注册信息要作调整，要为dll分配一个APPID，在激活是要使用代理方式，这样SCM会使用dllhost.exe包装dll。
顾名思义，代理占位，当然是要在不同的进程空间才需要的。实际上，客户在调用服务器组件的时候就是需要同代理dll打交道，而代理dll在通过lpc和已经在服务器com那里占到位置了的dll进行通信，对客户来说屏蔽了不同进程空间的信息交互。
我的理解，在ATL向导建立EXE工程的时候灰掉的选项的意思不因该是不允许代理占位的dll的生成，如果是那么p.c文件怎么出来的，代理、占位服务不在这个时候用，那该在什么时候？难道是进程内组件用的？？
第二点：对于dll，因该不可以作为独立的COM服务器运行，一个独立的COM服务器起码有自己可以依赖单独启动的宿主。分布式COM通信也遵守RPC协议进行通信，如果没有独立启动的宿主，就一个dll，在远端能提供服务吗？
纯属个人意见，有不对的地方望大虾海涵。。。
weirdy(软件设计师):
说的对头！
对于exe,PROXY/STUB是不能合并的(这里应该是指不和EXE合并,而不是说proxy+stub)因为他们要运行在不同的进程来实现调度.DLL可以作为分布式对象,当然需要双方安装并配置DCOM,COM对象是在DLL中或者exe中不影响他的功能,对客户透明.
解决方案5: 1,把proxy/stub 和组件合在一块，减少发布时的麻烦
2，必须是exe，当然你也可以写一个代理进程，像com+一样
1，如果在向导中选择exe来作为服务器类型，对话框底部所有选项都变成灰色，这表明不能使用他们了，为什么不能把代理/桩子放在exe文件中呢？这是因为代理/桩子必须在客户端进程内，如果把它放在可执行的服务器程序中，那么他就变成进程外的了。再说说为什么exe服务器不能支持MTS/COM+？因为这些技术依赖于被dll监管程序运行的服务器。
2，dll com不能作为分布式com，它是进程内组件。Dcom肯定要安装和注册dcom和DConfig配置。
这是我自己的理解！难免有错！一起探讨！