【发布时间】：2010-07-07 05:40:19
【问题描述】：
我正在尝试确定 MEF 是否是我们的应用程序框架应该采取的正确方向。根据我对 MEF 的阅读，我们的框架似乎并不“完全”适合，但我会看看是否有专家可以指导我。
我们的框架允许我们将一个核心网站和依赖程序集部署到一个地方（并将修复或功能传播给所有客户），然后我们将客户网站“合并”到核心网站中并将其扩展到哪里需要。
现在在 IIS 中，每个客户端站点都是在自己的 AppDomain 中运行的自己的应用程序。但是，每个应用程序都有相同的物理路径指向“核心网站”。
所以我们的文件结构是……
- /核心站点
- /bin（包含核心站点和依赖 dll）
- /[核心站点文件夹]（例如模型、视图、控制器、内容等）
- /客户
- /_Assemblies（包含所有客户端程序集 - 100 个客户端）
- /客户端1
- /[客户端站点文件夹]（例如模型、视图、控制器等）
- /客户端2
- /[客户端站点文件夹]（例如模型、视图、控制器等）
- /客户N
您可能已经猜到了，程序集加载是我们的问题。出于几个原因，我们不想将所有客户端程序集放入根 /bin 文件夹中。首先，我们不希望每个客户端站点都加载所有其他客户端程序集。其次，我们不希望每个站点的 AppDomain 都因为 /bin 文件夹中更新了另一个客户端的程序集而被回收。
为了在 asp.net 1.1 中进行这项工作，我们遵循http://www.hanselman.com/blog/MovingTheCodeBehindAssembliesDLLsToADifferentFolderThanBINWithASPNET11.aspx 并在 web.config 中添加
if ( Directory.Exists( assembliesDir ) && AppDomain.CurrentDomain.SetupInformation.ShadowCopyDirectories.IndexOf( assembliesDir ) < 0 )
{
AppDomain.CurrentDomain.SetShadowCopyPath( AppDomain.CurrentDomain.SetupInformation.ShadowCopyDirectories + ";" + assembliesDir );
}
还有中提琴，一切似乎都像一个魅力。不幸的是，在 asp.net 4.0 中，AppDomain.CurrentDomain.SetShadowCopyPath() 已被弃用。因此，我们一直在尝试从字节数组中自己加载程序集，尝试使用 AssemblyResolve 事件，在 [assembly: PreApplicationStartMethod( typeof( MvcApplication ), "PreApplicationStart" )] 中搞砸，尝试使用 System. Compilation.BuildManager.AddReferencedAssembly 无济于事。
我们要么得到：
- 没有加载程序集
- 加载的程序集过多，或
- 程序集被加载，但是当视图正在呈现并遇到命名空间应该位于 的
因此，我正在寻求使用任何机制的任何建议和/或有关 MEF 是否适合的建议。我的 1000 英尺观点是，MEF 更适合 1 个应用程序（和/或网站），其中插入了多个组件。我犹豫是否开始进行重大代码重构（似乎），因为在我们的情况下，每个应用程序/应用程序域一次只有一个组件插入其中。它似乎也比我们需要它做的更多（只需加载程序集并让 asp.net 识别它......然后我们所有的代码都会工作）。
非常感谢任何建议。
【问题讨论】：
标签： asp.net-mvc-2 mef asp.net-4.0 assembly-resolution assembly-loading