我正在使用AppDomain.CreateInstanceFromAndUnwrap()在不同的AppDomain中创建对象。我无法让它工作，因为它不断向我抛出以下错误：
无法加载文件或程序集“COMon，Version = 2.0.4960.27874，Culture = neutral，PublicKeyToken = null”或其依赖项之一。该模块应该包含一个程序集清单。
但是，我发现这是因为它试图加载我的DLL（它与我的.NET程序集同名）。
这就是我调用方法的方法：
_script = (Script)_appDomain.CreateInstanceFromAndUnwrap(Assembly.GetExecutingAssembly().Location, "COMon.Scripting.Script");
只要没有与.NET程序集同名的本机DLL文件，它就可以正常工作。为什么当我传递.NET程序集的完整路径和文件名时会发生这种情况？
答案 0 :(得分：3)
当我传递.NET程序集的完整路径和文件名时？
这不是该方法的工作原理。第一个参数是程序集的显示名称。它不是文件名。 MSDN文章建议您查看Assembly.FullName以了解有关显示名称的更多信息。
因此，正常的CLR搜索规则将有助于查找程序集。它将首先查看GAC，然后查看AppDomain的探测路径。如果您没有依赖的怪癖，CLR会不注意文件的文件扩展名。程序集的显示名称未指定它。所以它考虑了一个EXE和一个DLL等价物。您可以在Fuslogvw.exe的跟踪中看到的东西，当您遇到这样的问题时，您总是希望使用该实用程序。而在其他地方，添加对EXE的引用可以正常工作。
所以它找到了COMon.exe，这是一个kaboom，它不是一个托管程序集。
除了简单地重命名程序集之外，还不清楚在您的情况下可能采用的正确解决方法。当你修补AppDomains时，你通常也想使用AppDomainSetup并设置ApplicationBase或PrivateBinPath属性。