我比一切建议都多。.Net Remoting不使用.Net远程处理？
我下面举个例子：
Appication1.exe - 有对象MYLIST
Application2.exe - 需要获取MYLIST并与对象，就好像它是从应用2创建交互。
我应该使用.NET Remoting（即2.0）还是WCF或其他技术堆栈？有什么框架可以支持这个？每个的优点/缺点是什么？
我应该注意到，这更像是一个'帮手'应用程序，不会被开发团队以外的任何人使用。
我认为合理的选择是使用.NET远程处理。您将不得不在Application1上为Application2创建一个Web服务来与之通话。唯一的缺点是“MyList”需要用MarshalByRefObject标记。 MSDN说远程处理现在是有利于WCF的传奇东西（.NET 3.0）。但据我所知，Remoting是跨平台应用交流的唯一游戏。
这很难说。 WCF肯定是一种可能性。您必须拥有两个应用程序的控制权，并更改App1以支持（在推或拉模型上）将数据传输到App2。如果您不一定需要按需交换数据，则可以将数据库视为传输数据的方法。如果App1已经将一些数据写入数据库。然后你可以让App2从那里获取它需要的数据。或者如果交换不经常发生，你甚至可以使用文件系统。将列表序列化并用App2抓取它。 （我只是建议，因为它听起来像是在尝试将开发工具挂接到已存在的东西）。
远程处理是一种老旧的技术，充满了困难的实施和部署问题。 WCF更简洁，更易于实现。所以，如果它介于两者之间，我肯定会推荐使用WCF进行远程处理。
很难说如果不知道你的应用程序的更多细节，但我个人不会在这种情况下使用WCF。 WCF管道非常重，需要花费大量精力来设置和使用。它的API也非常适合Web服务，这在你的情况下似乎是过度的。微软声称WCF取代了远程处理，因为他们不想再支持远程处理，但同时使用了两者，我可以说WCF远不如在同类应用程序中移动数据的远程处理。
但是，有很多方法可以将数据从一个应用程序移动到另一个应用程序，各有各的优缺点。所有这些方法的全面讨论超出了本评论的范围。你能添加更多关于你的使用场景的细节吗？这个列表中有什么样的数据，它有多大，它来自哪里，正在做什么样的修改，应用程序1需要查看更改，应用程序2是否将数据发送到其他地方完成等...
我假设应用程序1是一个生产应用程序，而应用程序2是开发专用助手应用程序。如果是这种情况，您的目标应该是尽量减少或消除应用程序1中与支持应用程序2相关的任何额外开销。因此，应该消除非常繁重的WCF作为选项。远程处理还增加了开销。
你可以序列化对象 - 也许XML适合这个？
这个问题有太多的变数来完全回答它。你能提供关于应用程序1和应用程序2的更多信息吗？它们在哪里运行？你感兴趣的物体经常变化吗？他们如何保持国家？
我对此进行了投票，因为它似乎是最合乎逻辑的访问列表的方式，没有任何Remoting或WCF的开销。让app1只需将列表序列化为Xml或Binary格式化程序。 – IAbstract 2010-01-23 03:11:13
不应该“MyList”也是可串行化的吗？或者它所在的类/对象？ – IAbstract 2010-01-23 03:08:38