4

When an assembly exposes a superfluous (but missing) dependency, is there a clean way to squelch or ignore it?

Scenario:

Some app uses a FooUtil class, in CoolAssembly.dll. The only methods of concern are FooUtil.AwesomeMethod1 and FooUtil.AwesomeMethod2, both of which only have primitive-typed parameters, and both of which return void.

FooUtil implements IFooUtil, which publicly exposes .ProblematicMethod, a method that returns a CrazyNamespace.Bar. CrazyNamespace is defined in an assembly that's not available.

Now I could probably disassemble FooUtil and rebuild it without the unneeded dependencies, but that's the nuclear option, and I'd like to avoid it. So...

  1. Is there any way to simply hide the leaked dependency from the consuming app, or ignore it within the app, provided the leaked type isn't referenced anywhere in any possible call stack?
  2. If not, is it possible to redirect the dependency to a fake for CrazyNamespace that only exposes dummy substitutes for FooUtil's leaked type dependencies?

I assume that #2 could get hairy if the dependency chain gets deep or tangled, but that's out of my control. I can't know everything that CrazyNamespace.Bar depends on, but logically I should only need to worry about the subset that's publicly exposed (and/or nonpublicly consumed) by FooUtil. If #2 is possible in principle, then is the extent of FooUtil's dependence discoverable? (I'm thinking of method signatures consumed from nonpublic call sites.)

Paul Smith
  • 3,104
  • 1
  • 32
  • 45
  • I never tried this, but if assembly containing crazynamespace is not expected to be signed/strongsigned, then maybe you can just create an assembly with expected name, and create a type in that namespace that doesn' do anything??? (again, never tried this) – LB2 Feb 25 '14 at 22:03

1 Answers1

2

The word "clean" is off the table. As long as the assembly doesn't have a strong name then you can create a dummy version of it with the right [AsssemblyVersion] and display name and get both the compiler and the CLR to accept it as a substitute. Of course you need to implement the methods as throw new NotImplementedException(). You of course have no guarantee they won't throw.

If it is strong-named then your options dwindle dramatically. Ildasm.exe + ilasm.exe required, at least to alter the .assembly directive so your dummy assembly approach can work again.

This is not a good place to be. Work with the assembly owner to come up with a better approach.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536