在运行时更新 MEF 目录
我目前正在使用 MEF 开发一个 MVC Web 应用程序，以便 a) 开发人员可以为网站开发插件，用户可以选择他们想要在自己的帐户上使用哪些插件。这意味着我的一些合成必须在应用程序启动并且用户登录之后进行（它会进入数据库，获取插件的程序集并将它们添加到当前目录中）。
它的工作方式是，我有几个库存储在数据库中，并在用户登录加载到 AssemblyCatalog 时将其取出，我可以将其成功添加到现有的 AggregateCatalog 中 在我的作曲家中。但是，在我的一个库中，我有一个未导出的 IController 合约，导致该特定小部件损坏。我不完全确定如何强制 MEF 在启动后重新组合。我在这里发帖，希望有人能给我一些建议。
我的代码基于 Matt Abbott 的优秀博客系列，所以我有点希望他也会提出一些建议。
I am currently working on an MVC web app with MEF so that a) developers can develop plugins for the website, and users can elect which plugins they want on their account. This means that some of my composition has to happen after the app has already started and the user has logged in (which goes to the database, grabs the assemblies for the plug in and adds them to the current catalog).
The way it works is I have a couple of libraries that I store in the database and pull out when the user logs in to load into an AssemblyCatalog, which I can successfully add to my existing AggregateCatalog in my Composer. However, in one of my libraries I have an IController contract that isn't getting exported, causing that specific widget to break. I'm not entirely sure on how to force MEF to recompose after startup. I'm posting here, hoping that someone has some advice for me.
My code is based off the excellent blog series by Matt Abbott, so I'm kind of hoping that he'll chime in with some advice as well.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
那么，您不能只加载所有可用部分（无论哪些客户端启用了它们），而是通过
Lazy或ExportFactory与元数据的组合来使用延迟实例化识别您的客户端系统的各个部分？这样您就不需要按需加载程序集，它们就在那里准备就绪。如果您希望从数据库动态读取程序集并将其加载到您的 AppDomain 中，您可以将其包装在新的 AssemblyCatalog 中，但可以利用重组。
例如，在那个早期版本中，我使用的是
PartCreator，它演变成即将发布的ExportFactory（但未包含在最终的 .NET 4.0 中） ）。如果将[ImportMany]更改为[ImportMany(AllowRecomposition = true)]，下次添加新目录时，例如：应该重新组合
[ImportMany ]PartCreator(ExportFactory) 实例集。不确定这是否有效...我需要先了解您的预期架构，然后才能说它会或不会工作...
Well, couldn't you just load ALL available parts (regardless of which clients have them enabled), but use deferred instantiation, either through
LazyorExportFactorywith a combination of metadata to identify the parts to your client system? That way you wouldn't need to load assemblies on demand, they are just there ready to go.If its the case that you want dynamically read an assembly from your database and load it into your
AppDomain, you can probably wrap it up in a newAssemblyCatalog, but take advantage of recomposition.E.g., in that early version, I was using
PartCreator<T,TMetadata>which evolved intoExportFactory<T,TMetadata>nearing release (but not included in final .NET 4.0). If you change the[ImportMany]to[ImportMany(AllowRecomposition = true)], next time you add a new catalog, e.g.:Which should recompose the
[ImportMany]set ofPartCreator(ExportFactory) instances.Not sure if that would work... I'd need to understand your intended architecture before I can say it would or would not work...
我将其作为答案输入，尽管这并不是真正的答案，而更多的是一个结论。我的问题是这样的：我在应用程序启动时完成了所有 MEF 组合，然后在用户登录后尝试将其全部分开。
实际上，我只需要推迟所有这些。首先让用户登录，然后根据用户“安装”的内容（从数据库中提取程序集等）执行所有 MEF 组合，将该组合容器存储在会话或其他存储机制中（这样我就可以获得导出）根据构建页面、小部件等的需要），我很高兴。我最初的问题是由于试图将方形钉子装入圆孔中而产生的。我的合成不需要在登录之前发生，而不是启动。虽然我可能会使用 MEF 在我的应用程序中执行一些 DI，但这将与用户组合分开。
不过，我要借此机会再次感谢 Matthew Abbott 关于 MEF 和 MVC 的出色系列文章，这确实帮助推动了这个应用程序的发展。 :) 我没有将他的回答标记为回复，但我确实投票了，以帮助他获得更多声誉。
I'm entering this as an answer, even though it's not really an answer, but more of a conclusion. My issue was this: I was doing all of my MEF composition at app startup, then trying to separate it all by user after they've logged in.
In reality, I just need to postpone all of that. Let the user log in first, THEN do all my MEF composition based on what the user has "installed" (pulling assemblies from the database, etc.), store that composition container in session or some other storage mechanism (so I can get exports as needed to construct pages, widgets, etc.), and I'm golden. My original issue arose from trying to fit a square peg into a round hole. My composition doesn't need to happen until login, not startup. Although I might use MEF to do some DI in my app, but that would be separate from user composition.
I will take this moment, though, once again to thank Matthew Abbott for his excellent series on MEF and MVC, which really helped push this application forward. :) I did not mark his answer as a reply, but I did upvote it to help give him more reputation.