我大致了解AppDomain是什么，但我不完全了解AppDomain的用途。我参与了一个基于大型服务器的C#/C++应用程序，我想知道如何使用AppDomains来提高稳定性/安全性/性能。特别是:我了解一个域中的故障或致命异常不会影响在同一进程中运行的其他应用程序域-这是否也适用于非托管/C++异常，甚至可能是堆损坏或其他内存问题。AppDomain之间的通信如何工作？使用AppDomain与简单地生成多个进程有何不同？ 最佳答案 AppDomain的基本用例是在托管第3方代码的环境中，因此不仅需要动态加载程序集还需要卸载它们。无
我有一个使用单独的C++DLL的C#插件。对该DLL的唯一引用来自插件本身。父应用在自己的AppDomain中加载所有插件，并在卸载插件时卸载这个AppDomain。我已经检查过了，当我卸载插件时，我确实看到了应用程序的内存下降。我还能够删除所有已加载的托管程序集。问题是，当我尝试删除nativeDLL时，我只会不断收到访问被拒绝的信息，直到我关闭整个应用程序。我已经研究了一段时间了，但我仍然不明白为什么只有这个DLL保留在内存中。 最佳答案 AppDomains是一个纯托管代码结构。native代码中不存在类似的东西，Window
我需要在非托管进程中托管.NET运行时。我有代码可以通过COM加载运行时，我可以将程序集加载到AppDomain中并执行代码。但是，我遇到了托管在网络共享上的应用程序的问题，必须更改应用程序策略才能让它们执行，这不是一个选项。所以我想做的是将运行时的主AppDomain的权限级别设置为不受限制。有人可以提供有关如何设置AppDomain策略级别的示例吗？我不太清楚如何从非托管代码实例化所需的类以创建PolicyLevel和相关对象并设置策略。基本上我不知道我需要什么包含/命名空间引用才能使它从我使用的C++代码中工作。这是我此时的代码:///StartsuptheCLRandcreat
我想知道是应该为每个实例使用一个进程，还是应该使用AppDomains在单个进程中运行多个实例。我有一个服务器应用程序，它遵循类似于telnet的设计。用户始终通过TCP连接，服务器保持客户端session的完整状态，该状态显示在工作站上。该软件需要支持至少500个并发连接，可能更多。一个典型的安装将需要3到7个应用程序实例连续运行，尽管除了一个实例之外的所有实例都只有几个连接(它们用于测试、引用环境等)。在内部，出于开发目的，最多将有40个环境，每个环境最多有20个并发连接。我的目标主机环境将是64位Windows。我知道IIS使用的模型只有一个进程和多个AppDomain，但我也可
我很好奇有没有类似.Net的AppDomain的Java抽象。我特别好奇，因为我发现我们的Coldfusion/J2EE服务器由于缓慢的内存泄漏而需要每隔几天重新启动一次，而我们还无法轻松找到它。这可能会破坏我们长期运行的流程，我们真的很希望有一种方法可以在人们超过特定时间段/内存阈值时慢慢地将他们推向新的JVM。根据我有限的.Net经验，我很确定这是IIS和AppDomains能够通过回收承受内存压力的AppDomains相当无缝地管理的一种情况。如果我在AppDomains上对这种情况有所帮助，请告诉我。有什么建议吗？ 最佳答案
假设我有一个AppDomain.AssemblyResolve的处理程序事件，并在处理程序中构造一个字节数组并调用方法Assembly.Load(byte[]).此方法本身是否会导致再次引发AssemblyResolve事件，并导致重新输入我的处理程序？我的问题不仅限于可以使用C#编译器生成的程序集，它们还可以包含CLR支持的任意元数据和可执行代码。我做了一些实验，但没有发现任何情况。我尝试加载需要额外引用的程序集，尝试将CAS属性添加到加载的程序集(其解码需要另一个程序集)，尝试加载带有模块初始值设定项的程序集(全局.cctor方法)。在任何情况下，我都没有观察到AssemblyRe
我正在尝试将同一台机器中跨AppDomain通信的性能损失降到最低。在我的玩具示例中，A类加载到AppDomain1中。它创建一个AppDomain2并在那里加载一个Class2的实例(Class2继承自MarshalByRef)以取回代理。然后Class1在代理上重复调用一个不返回任何值的方法。我得到以下结果:没有AppDomain，两个类都加载到同一个AppDomain中，第一个类重复调用第二个方法(该方法没有参数):2400万方法调用/秒如上所述的两个AppDomain，方法没有参数或“大量”字符串参数:340.000次方法调用/秒如上所述的两个AppDomain，一个可序列化参
当我执行AppDomain.Unload(myDomain)时，我希望它也执行完整的垃圾收集。根据JeffreyRichter在“CLRviaC#”中的说法，他说在AppDomain.Unload期间:TheCLRforcesagarbagecollectiontooccur,reclaimingthememoryusedbyanyobjectsthatwerecreatedbythenowunloadedAppDomain.TheFinalizemethodsfortheseobjectsarecalled,givingtheobjectsachancetocleanthemselv
我有以下方法应该检索加载的本地(在bin文件夹中)程序集的列表:staticIEnumerableGetLocalAssemblies(){AssemblycallingAssembly=Assembly.GetCallingAssembly();stringpath=newUri(Path.GetDirectoryName(callingAssembly.CodeBase)).AbsolutePath;varassemblies=AppDomain.CurrentDomain.GetAssemblies();returnassemblies.Where(x=>!x.IsDynamic
假设我有两个C#应用程序-game.exe(XNA，需要支持Xbox360)和editor.exe(XNA托管在WinForms中)-它们两者共享一个完成大部分工作的engine.dll程序集。现在假设我想添加某种基于C#的脚本(它不完全是“脚本”，但我会这样调用它)。每个级别都有自己的类继承自基类(我们称之为LevelController)。这些是这些脚本的重要约束:它们需要是真实的编译C#代码他们应该需要最少的手动“胶水”工作，如果有的话它们必须与其他一切运行在同一个AppDomain中对于游戏-这非常简单:所有脚本类都可以编译成一个程序集(例如，levels.dll)，并且可以根
