When an assembly provides redundant (but missing) dependency, is there a clean way to suppress or ignore it?
Scenario:
The application uses a FooUtilclass CoolAssembly.dll. The only dangerous problems are FooUtil.AwesomeMethod1and FooUtil.AwesomeMethod2, both of which have only primitive-typed parameters, and both of them return void.
FooUtilimplements IFooUtil, which publicly provides a .ProblematicMethodmethod that returns CrazyNamespace.Bar. CrazyNamespacedefined in an assembly that is not available.
Now I could parse FooUtiland rebuild it without unnecessary dependencies, but this is a nuclear option, and I would like to avoid it. So that...
- Is there a way to simply hide the missing dependency on the consumer application or ignore it in the application if the missing type is not mentioned anywhere in any possible call stack?
- If not, is it possible to redirect the dependency to a fake for
CrazyNamespace, which provides only hidden substitutes for the FooUtil'sdependent leak types?
I guess # 2 can get hairy if the dependency chain gets deep or messy, but it's out of control. I can’t know everything that depends on it CrazyNamespace.Bar, but it’s logical that I only need to worry about the subset publicly exposed (and / or not publicly consumed) on FooUtil. If, in principle, # 2 is possible, is it possible to determine the degree of dependence FooUtil's? (I think of method signatures consumed from non-public call sites.)