是否有可能使用ILMerge来内化Castle project的DynamicProxy类?
本文关键字：project Castle DynamicProxy 有可能 ILMerge 是否 | 更新日期: 2023-09-27 18:01:47
我有一个内部依赖于Castle. core .dll的. net库，因为我使用Castle的DynamicProxy(具体来说，是一个"没有目标的接口代理")来执行拦截自定义处理的方法调用。因为我的程序集是强命名的，所以我希望使用ILMerge将所有依赖项合并到单个程序集中以进行部署，内部化依赖项的类型，以便不向消费者不必要地公开它们。这对于NuGet的情况尤其重要，如果我的程序集是强命名的，我必须将我的包依赖项设置为特定的版本的依赖项，否则程序集名称解析会中断，因为Castle.Core.dll也是强命名的。请注意，将我的项目作为强命名程序集发布是我的用户所看重的一个特性，因此删除强名称不是一个选项。
显然，DynamicProxy需要它的一些类是公共的才能正常工作。没问题，我可以排除某些类型被ILMerge内化。但是，当我有一个用户引用我的库，但也引用Castle.Core.dll时，就会出现问题。公共类型现在由两个程序集提供，对它们的引用是不明确的。
如果我不使用ILMerge将Castle.Core.dll内部化，将它与我自己的程序集一起发布，这可能会导致我的版本和用户的版本发生冲突。如果我使用ILMerge来内部化程序集，我就被迫排除了DynamicProxy正常工作所需的内部化类型。这种方法将破坏任何同时引用我的程序集和Castle.Core.dll的项目，因为类型不明确。
我是否被迫选择这两个次优行动方案中的一个?还是有我还没想到的解决办法?
当您有两个同名的完全限定类型时，就会遇到歧义问题。这可以使用外部别名来解决。
默认情况下，所有引用的程序集都属于全局别名，这就是为什么在生成的代码中您会看到类似global::System.String的东西。我不能肯定地说如何在ILMerge中使用外部别名，但您可以使用它来消除引用程序集的歧义。无论哪种方式，您都可以指定您的"内部"castle . core .dll作为"castle"的别名，并从中删除全局别名。缺点是您必须像castle::Castle.Core.Interceptor.IInterceptor那样修改代码来利用这一点。
下面是一个很好的资源，它向您展示了更多信息，包括图像:http://www.davidarno.org/c-howtos/aliases-overcoming-name-conflicts-part-2-extern-alias/
请记住，次要引用的Castle.Core.dll(由使用您的程序集的其他人)可能包含相同的完全限定类型，但从所有帐户来看，它们仍然是两个明显不同的类，也就是说，期望类型为castle::Castle.Core.Interceptor.IInterceptor的方法将无法通过从第二个程序集传递类型Castle.Core.Interceptor.IInterceptor来工作。