【发布时间】：2016-12-02 10:29:47
【问题描述】：
我的问题的标题可能已经暴露了我不确定自己想要什么的事实，因为它可能没有意义。
对于一个项目，我希望能够在我的应用程序中运行可执行文件，同时重定向它们的标准输入和输出，以便我的应用程序可以通过这些流与它们通信。
同时，我不想让这些可执行文件执行某些操作，比如使用网络，或者在他们自己的工作目录之外读/写（基本上我只想让他们从标准中读写进出）。
我在互联网上的不同地方读到，在创建 AppDomain 时可以使用 PermissionStates 设置这些权限，然后您可以在其中执行可执行文件。但是，我没有找到一种方法来通过它们的标准输入和输出与可执行文件进行通信，这是必不可少的。但是，我可以在启动新进程 (Process.Start()) 时执行此操作，但我无法设置可执行文件允许执行的操作的界限。
我的直觉告诉我应该以某种方式在 AppDomain 中执行进程，以便进程在域中“运行”，尽管我看不到直接执行此操作的方法。
我的一位同事通过创建代理应用程序来实现这一点，它基本上是另一个可执行文件，其中创建了 AppDomain，其中执行实际的可执行文件。然后代理应用程序由主应用程序中的进程启动。我认为这是一个很酷的想法，虽然我觉得我不应该需要这一步。
我可以添加一些代码，其中包含我迄今为止创建进程和 appdomain 所做的工作，尽管这个问题已经很长了。如果你愿意，我会添加它。
【问题讨论】：
-
这非常复杂，可悲的是——这些安全方法一次又一次地失败是有原因的，他们付出了巨大的努力，没有人能把它们做好。但是，您可以做的是以受限用户的身份运行该进程 - 虽然它没有为您提供 CAS 为您提供的粒度，但它也容易得多，并保持进程隔离。进程内扩展可以很容易地杀死您的应用程序:)
-
无法在
AppDomain中运行进程，因为它们是完全独立的概念。AppDomains 在进程中运行，反之亦然。当然，它们首先只适用于 .NET 应用程序 :) -
@Luaan 那么当我打电话给
AppDomain.Create(...).ExecuteAssembly(pathToMyStuff)时会发生什么？我觉得这开始了一个新的过程，但根据你的说法，情况并非如此...... -
它在给定的程序集中执行入口点方法，在给定的
AppDomain内（如果我简化，它相当于GetType("Program").GetMethod("Main").Invoke();）。没有产生新的进程。AppDomain确实是一种软件隔离进程的机制，但是使用起来相当棘手，而且隔离对于真正的沙盒来说太有限了。 -
.NET MSDN 文档实际上相当不错——在
ExecuteAssembly上，它实际上明确指出“此方法不会创建新的进程或应用程序域，并且不会在一个新线程。”我想知道如果我们回到“首先检查文档”模型，我们会节省多少精力，而不是期望我们的假设是正确的，只是因为方法的名称是“执行”：D 对我来说，原来的假设源于“它位于AppDomain，因此它显然无法启动进程。” - 这可能可能是错误的。