Solrnet、StructureMap 和 NHibernate
我在集成我们公司构建的库时遇到问题，该库在后端使用 Solrnet。我们还有许多其他库，其中之一使用 NHibernate 作为数据库。一切正常，图书馆取回数据。
当我们添加对这个使用 Solrnet 的新库的引用时，事情开始变得不对劲。当我们运行应用程序时发生的第一个错误。当应用程序使用 NHibernate 运行库的 StructureMap 注册表时，注册表会崩溃，因为 NHibernate 无法加载 Castle.Core 程序集（这不会导致在添加引用之前丢失任何问题）。如果我们确保 Castle.Core 存在，NHibernate 就会在尝试加载 Castle.Windsor 时崩溃，而这又是它之前不需要的。
有什么想法吗？正如我所说，如果我们删除使用 Solrnet 的新库，使用 NHibernate 的库就很好，但是一旦我们引用它，事情就开始出错。使用 Solrnet 的库还使用 StructureMap、FWIW 配置 Solrnet。
编辑：这些是混合中各种程序集的版本。 结构图 - 2.6.1.0 流畅的 NHibernate - 1.0.0.0 NHibernate - 2.1.2.4000 Solrnet - 0.3.1.0 Castle.Core（随 NH 一起提供）- 1.1.0.0
更新：它开始看起来像是 Solrnet 正在尝试加载 Castle.Windsor。我不知道为什么，因为我们给了它一个 StructureMap 配置。它的存在就足以炸毁一切。即使没有依赖于 Solrnet 的程序集，它的存在似乎也会扰乱 NHibernate 配置。
I'm having a problem integrating a library our company has built which uses Solrnet in the back end. We have many other libraries, one of which uses NHibernate for the database. It all works fine, the library gets the data back.
When we add a reference to this new library which uses Solrnet, things start to go arwy. The first error that occurs when we run the application. when the application runs the StructureMap registry for the library using NHibernate, the registry blows up because NHibernate can't load the Castle.Core assembly (which has not caused any problems being missing prior to adding the reference). If we then ensure that Castle.Core is present, NHibernate then blows up trying to load Castle.Windsor, which again it didn't need before.
Any ideas? As I said, the library which uses NHibernate is fine if we remove the new library which uses Solrnet, but as soon as we reference it things start to go wrong. The library which uses Solrnet also configures Solrnet using StructureMap, FWIW.
EDIT: These are the versions of various assemblies in the mix.
StructureMap - 2.6.1.0
Fluent NHibernate - 1.0.0.0
NHibernate - 2.1.2.4000
Solrnet - 0.3.1.0
Castle.Core (came with NH) - 1.1.0.0
UPDATE: Its starting to look like Solrnet is the one trying to load Castle.Windsor. I'm not sure why as we've given it a StructureMap configuartion. Its mere presence is enough to blow things up. Even without the assemblies which depend on Solrnet, the fact that its there at all seems to mess with the NHibernate configuration.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好吧，我想出了如何阻止这个错误。我们使用合并的 Solrnet.dll，其中包括用于连接到其他 Ioc 容器以及 NH 集成的所有类型。我转而使用未合并的二进制文件，这将其他 Ioc 保留在单独的程序集中，并且我们只包含基础 Solrnet.dll 和 StructureMap.Solrnet.dll，这基本上解决了问题。我仍然必须确保包含 Microsoft.Patterns.ServiceLocater，因为基础 Solrnet.dll 仍然公开了这一点。这并不理想，因为我们没有使用它，但比需要一堆其他组件要好。
Ok, I figured out how to stop this error. We were using the merged Solrnet.dll, which includes all the types for connecting to other Ioc containers as well as NH integration. I switched to using the unmerged binaries, which keeps the other Iocs in separate assemblies, and we only included the base Solrnet.dll and StructureMap.Solrnet.dll, which solved the issues mostly. I still did have to be sure to include Microsoft.Patterns.ServiceLocater, as the base Solrnet.dll still exposes this. Not ideal as we're not using it, but better than needing a bunch of other assemblies.