Edit – even though the steps described below related to an example with IIS, you can use this technique for any running process, it’s just a matter of identifying the process id. In some cases you will not even need the process id, e.g. if all processes are using the same version of a DLL.
Figuring out what dll is actually executing on a running web server is no easy task; it’s not as simple as looking in the bin directory of the deployed application as the dlls are copied from there to a set of temporary directories within the windows systemroot.
I know of two ways of figuring this out, the first requires some code changes and the second does not.
I wrote some time ago about how to find which dll is really executing when running an application, it works just fine if you can alter the source code to include the snippet I proposed.
Clearly that is not a lot of use in a deployed application when you cannot change the code or even redeploy.
No code change needed
Here is the alternative, no code changes needed. The application I am interested in is called MyFancyApp, there are other applications running on the server too. Let’s say that the dll I am interested in is AutoMapper.dll, I need to verify that the running dll is really the version I expect.
1. Open a command prompt and navigate to
appcmd list wp, this will show all the running application pools and the associated process ids. The output will look something like this –
You can see that MyFancyApp is running with process id of 1224.
Now switch to Process Explorer.
4. Double click one of the entries for PID 1224 where the Type is DLL.
5. In the lower pane of Process Explorer the AutoMapper.dll is selected and the version is shown, I had to right click on the lower pane and the version column to make it visible.
That’s it. No redeploy, no code editing, no remote debugging. You now know for sure which dll is running and where to find it. If the dll is your own and you are concerned about what might be in the code you can open the file in dotpeek to decompile it.