Is it possible to know which .dll called a C# service? Even if the call passes through a COM layer first?

Question

We have layered architecture that has a native C++ client, and a managed client C++/C# wrapper around it. (2 dll files, one native one managed)

These two clients go through a COM layer to a C# service, there are many different versions of these clients and the service is designed to be backward compatible.

Recently we realized we might need to know the version of the client calling into the service. (the dll files)
Is there a way to go through the call stack and grab the dll that called in and its version? Does going through the COM layer make this an impossible task?

Other products consume and deliver these clients, so the location or path of the dlls is not always known. Getting the location through the call stack might be an alternative route to the solution, but I might be thinking about this entirely incorrectly.

We can't edit existing released client dlls, so we have to be able to determine the version of the dlls from the service layer at runtime.

Answer 1

It is possible to capture a stacktrace, step thru the various stack frames, get the methodinfo for each, get the declaring type, and find the assembly for that type. This however is rather cumbersome, and would be slow since it would use a lot of reflection. I'm not sure if COM would affect this, but I suspect it should not, as long as the call does not jump between threads.

This would also be rather poor practice since the method call depend on information that is not obvious for the caller. As such it can be very confusing for new developers, and may be fragile.

Perhaps it would be sufficient to check what dlls are loaded, rather than what version made the call?

I would recommend making your service work correctly regardless of client if at all possible, possibly adding information to the call if needed. Another approach is to specify multiple versions of the service, and let the client call the version it has been developed with. Third approach would be to explicitly inform the service about the client version, and if this is not done, assume some specific client version.