How to find out which assembly handled the request

Question

I have a Web solution which contains two projects (A and B) with B referencing A.

In A I have an Html extension method that obviously can be called from either A or B.

My question is once the method is called (usually from a partial view) is there a way inside the method to figure out whether the call came from Assembly A or Assembly B without passing anything to it?

I tried to see if I can do anything with HttpContext.Current.Request but could not find anything useful. I can get the URI but that still does not tell me which assembly the file that originated the Request is in.

---

Thanks for your answers - the method returns a string and the string is from a string.resx file which I have one for each assembly. That is why I need to know which file to access to return the string. Since each assembly "registers" itself on start up if I add a new assembly my method will not change, since it will just look up the assembly.In fact my whole project will not change. The reason why I am not introducing another parameter at this time is b/c it will mean a HUGE amount of changes and I honestly don't see the benefit. While I see your point and I generally agree with it I think in my case it's not that the method returns different things , it's just grabbing the correct resource file based on the assembly.

Answer 1

As SLaks pointed out, you can check HttpContext.Current.Application.GetType().Assembly.

However I agree with John in the comments that you have probably made a bad design decision if you need this.

The Problem

Your method is a hypocrite.
It talks different to different callers but doesn't tell it in open.

You see, each method defines a certain contract with arguments and a return type.
For example, int.Parse says that it takes a string and turns it into an int. If we want to change default behavior, we may also give it NumberStyles and/or IFormatProvider.

We the consumers don't know how int.Parse is implemented. Because it is static, we most certainly expect it doesn't have side effects and will always return the same value for the same set of parameters.

Repeat this mantra after me:

Explicit is better than implicit.

You would probably be very angry if you found out int.Parse somehow analyzes your code and changes its behavior depending on where it's called from.

It's the caller's responsibility to define the context, not the callee's.

Try to give simple and concise answers to questions below:

• What happens if the method is called from assembly C?
• How would you unit-test it? What if some other developer uses this method in unit tests?
• What happens if you rename assembly A or B? Merge them? Split them further?
• Will you remember to change this method if anything above happens?

If answering any of the questions above clearly poses a challenge for you, it is a sign you're Doing It Wrong™.

Instead you should...

Introduce a Parameter

Think about the method contract. What can you do to make it full and descriptive?

Define a generic (as in English) method in a separate assembly that doesn't know anything about the callers and has additional parameters, and define parameter-filling shortcuts for it in concrete assemblies.

It's better that these parameters don't know anything about the assemblies either.

For example, if you needed to resolve URLs inside your method, you could accept string baseUrl or Func<string, string> urlResolver so it's potentially usable from any assembly that cares to specify those.

In the worst case, you could define an enum with possible caller contexts and pass it to the method. This will make your design problem explicit, rather than implicit. Obvious problem is always better than hidden problem, although worse than no problem at all.

Answer 2

Check HttpContext.Current.Application.GetType().Assembly