合并 DLL 并更改管理命名空间
我想创建一个与第三方 dll 合并的单个 dll。这意味着最终消费者只需处理 1 个 dll，而不是 2 个。
出于增强目的，我们假设第 3 方 dll 是 nLog。如果合并的 dll 的使用者已经将 NLog 作为其项目中的引用，我该如何处理？
理想情况下，我希望能够将项目中的 NLog 命名空间更改为“XyzNLog”，这意味着用户不需要执行任何别名...知道我该怎么做吗？
现在我知道我可以为 NLog 添加别名到我的项目中，这样我就必须将其称为 XyzNLog，但我希望将其传递给合并 dll 的使用者，这样就不会发生冲突。
更新 - 解决方案
http: //blog.mattbrailsford.com/2010/12/10/avoiding-dependency-conflicts-using-ilmerge/
宾果！因此，通过使用 ILMerge，它就变成了 可以合并第三方 提供程序中的库 DLL 自己的 DLL，这意味着我们只有一个 要部署的 DLL。 但这还不是全部，我们 实际上可以更进一步，并且 告诉 ILMerge 内化所有内容 依赖关系。这是做什么的 转换所有第三方类 被声明为内部的，意思是 它们只能在 最终的DLL。呜呼！问题解决了 =)
考虑到这个问题，我的 dll 的使用者也可能让 NLog 消失......因为我引用的 NLog 转变为全部内部！这正是我想要的。
有人对此有任何反馈或想法吗？
I want to create a single dll that is merged with a 3rd party dll. This means end consumers will only have to deal with 1 dll instead of 2.
For augments sake lets say that the 3rd party dll is nLog. How do I deal with cases where the consumer of the merged dll already has NLog as a reference in their project?
Ideally what I would like to be able to do is change NLog namespace within my project to "XyzNLog", meaning that the user wouldn't need to do any aliasing... Any idea how I might do this?
Now I know I can add aliases to my project for NLog so that I have to refer to it as XyzNLog, but I want the same to carry over to consumers of the merged dll so that there is never a conflict.
UPDATE - Solution
http://blog.mattbrailsford.com/2010/12/10/avoiding-dependency-conflicts-using-ilmerge/
Bingo! So by using ILMerge, it becomes
possible to merge the third-party
libraries DLLs in with the Providers
own DLL, meaning we will only have one
DLL to deploy. But that’s not all, we
can actually go one step further, and
tell ILMerge to internalize all
dependencies. What this does it
converts all the third party classes
to be declared as internal, meaning
they can only be used from within the
final DLL. Woo hoo! problem solved =)
Given this the problem where the consumer of my dll could also have NLog goes away... as my referenced NLog shifts to being all internal! This is exactly what I want.
Does anyone have any feedback or thoughts on this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我同意 Hans 的观点，我强烈建议单独注册 DLL 来发布。
否则，您可能会陷入 DLL 地狱，从而赶走您的消费者。
然后，您可以设计一些巧妙的部署方法来检测 DLL 是否已注册等。
I agree with Hans, I would strongly suggest releasing with registering the DLLs separately.
Otherwise, you could be in DLL hell which would drive your consumers away.
You could then devise some clever deploy methods to detect if the DLL is already registered, etc.
我必须同意@Hans Passant（以及这里有一些信息< /a> 关于经常讨论的 DLL 地狱），但既然你问了这个问题，我会尽力回答它。
您可以将第三方 DLL 捆绑为资源。请查看此问题了解详细信息。
至于您的其他问题，我只是在您自己的命名空间下公开第三方 DLL 中的相关类，并且可能使用扩展方法来提供您想要的任何附加功能。
例如，您可以使用类中的静态方法（例如
XyzNLog.Logger.Log()）提供对 NLog 的Log()方法的访问，负责初始化，以及代码内部的任何其他内容（静态构造函数或您喜欢的任何其他内容）。由于您使用上述方法加载 NLog 程序集，因此您将是唯一可以直接访问嵌入式 NLog 程序集的人，并且用户将无法访问它。现在，您无法获得从 NLog 自动公开所有类的好处，在这种情况下您仍然必须手动公开它们。
编辑：另一种方法是尝试使用带有 /internalize 标志的 ILMerge 如此处所述。您可能无法完全解决问题，但请查看 这篇文章，看看您是否可以避免作者描述的陷阱。剧透警告：这也不全是桃子和奶油，但只要付出足够的额外努力，它可能会起作用。
I have to agree with @Hans Passant (and here's some info about the oft-discussed DLL hell), but since you've asked the question, I'll try to answer it.
You can bundle the third-party DLL as a resource. Please see this question for details.
As far as your other questions, I'd just expose the relevant classes from a third-party DLL under your own namespace, and maybe use extension methods to provide whatever additional functionality you want.
For instance, you can provide access to NLog's
Log()method using a static method in your class, sayXyzNLog.Logger.Log(), taking care of initialization, and whatever else internally, inside your code (static constructor or whatever else you fancy up).Since you load the NLog assembly using the method above, you'll be the only one having access to the embedded NLog assembly directly and the user won't be able to access it. Now, you don't get the benefit of having all classes autoexposed from NLog, you still have to expose them manually in this case.
EDIT: Another approach would be to try to use ILMerge with /internalize flag as described here. You may not be able to completely resolve the issue, but look at this article to see if you can avoid the pitfalls the author described. Spoiler alert: it's not all peaches'n'cream on this one either, but it may work, with enough extra effort.