是否有可能回避C#中泄露的程序集依赖性

当一个程序集暴露出多余(但缺失)的依赖关系时,有没有一种干净的方法来压制或忽略它?

场景:

一些应用程序在CoolAssembly.dll中使用FooUtil类.唯一值得关注的方法是FooUtil.AwesomeMethod1和FooUtil.AwesomeMethod2,它们都只有原始类型的参数,并且都返回void.

FooUtil实现了IFooUtil,它公开了.ProblematicMethod,一个返回CrazyNamespace.Bar的方法. CrazyNamespace在一个不可用的程序集中定义.

现在我可以反汇编FooUtil并在没有不必要的依赖项的情况下重建它,但那是核选项,我想避免它.所以…

>有没有办法简单地隐藏泄露的依赖从消费应用程序,或在应用程序中忽略它,只要在任何可能的调用堆栈中没有引用泄漏类型?
>如果没有,是否可以将依赖项重定向到CrazyNamespace的伪造,它只暴露FooUtil泄漏类型依赖项的虚拟替代?

我假设如果依赖链变得深沉或纠结,#2可能变得毛茸茸,但这是我无法控制的.我不知道CrazyNamespace.Bar所依赖的一切,但从逻辑上讲,我只需要担心FooUtil公开暴露(和/或非公共消费)的子集.如果#2原则上是可能的,那么FooUtil的依赖程度是否可被发现? (我正在考虑从非公共呼叫站点消耗的方法签名.)

最佳答案 “干净”这个词不在桌面上.只要程序集没有强名称,就可以使用正确的[AsssemblyVersion]和显示名称创建它的虚拟版本,并让编译器和CLR接受它作为替代.当然,您需要将方法实现为throw new NotImplementedException().你当然不能保证他们不会扔.

如果名字很强,那么你的选择就会大幅减少. Ildasm.exe ilasm.exe是必需的,至少要改变.assembly指令,这样你的虚拟装配方法才能再次运行.

这不是一个好地方.与装配所有者合作,提出更好的方法.

点赞