c# - How to find out which assembly handled the request -

i have web solution contains 2 projects (a , b) b referencing a.

in a have html extension method can called either a or b.

my question once method called (usually partial view) there way inside method figure out whether call came assembly a or assembly b without passing it?

i tried see if can httpcontext.current.request not find useful. can uri still not tell me assembly file originated request in.

---

thanks answers - method returns string , string string.resx file have 1 each assembly. why need know file access return string. since each assembly "registers" on start if add new assembly method not change, since assembly.in fact whole project not change. reason why not introducing parameter @ time b/c mean huge amount of changes , don't see benefit. while see point , agree think in case it's not method returns different things , it's grabbing correct resource file based on assembly.

as slaks pointed out, can check httpcontext.current.application.gettype().assembly.

however agree john in comments you have made bad design decision if need this.

the problem

your method hypocrite.
talks different different callers doesn't tell in open.

you see, each method defines contract arguments , return type.
example, int.parse says takes string , turns int. if want change default behavior, may give numberstyles and/or iformatprovider.

we consumers don't know how int.parse implemented. because static, expect doesn't have side effects , will return same value same set of parameters.

repeat mantra after me:

explicit better implicit.

you angry if found out int.parse somehow analyzes code , changes behavior depending on it's called from.

it's caller's responsibility define context, not callee's.

try give simple , concise answers questions below:

• what happens if method called assembly c?
• how unit-test it? if other developer uses method in unit tests?
• what happens if rename assembly or b? merge them? split them further?
• will remember change method if above happens?

if answering of questions above poses challenge you, sign you're doing wrong™.

instead should...

introduce parameter

think method contract. can make full , descriptive?

define generic (as in english) method in separate assembly doesn't know callers , has additional parameters, , define parameter-filling shortcuts in concrete assemblies.

it's better these parameters don't know assemblies either.

for example, if needed resolve urls inside method, accept string baseurl or func<string, string> urlresolver it's potentially usable any assembly cares specify those.

in worst case, define enum possible caller contexts , pass method. make design problem explicit, rather implicit. obvious problem better hidden problem, although worse no problem @ all.