My Friend was looking for one error that he was continuously getting when he was trying to setup my old version 1.0 .net code. The error message was:
The given assembly name or codebase, “Microsoft.practices.EnterpriseLibrary.Common” was invalid.
Then I went in Google and searched for the issue, I did not get any satisfactory resolution. However I came to know about one good tool from Microsoft that I had never been used. That tool name is “Assembly Binding Log Viewer”. Using that tool it is very easy to get the error which runtime faced while loading the assembly. I came to know that it may be 3 reasons when we generally get above type of error.
1) assembly deployed to the wrong location
2) mismatch in version numbers
3) mismatch in cultures
Before I could ever suggested my friend how to resolve the problem he came to my desk and said that he had solved his problem. I asked him how did you achieve that he said he deleted all the old folders with all assemblies and then he recreated everything back then it started running 🙂
I was happy that at least his problem got resolved.
However, Assembly Binding Log Viewer is a good tool it starts logging the error that we get while loading assembly at runtime. It helps us to know what the exact error was because typically the .net application shows us the exception message that is very generic it’s called TypeLoadException. By looking only that exception it is very difficult diagnosis the problem.
For running the tool:
You have to type fuslogvw.exe (it stands for Fusion Log Viewer) in visual studio tools, command prompt. The moment you will type it will open up one handy-dandy widow’s application.
It will show you the entries of each failed assembly bind. It will show you below details:
1) application that initiated the bind
2) the assembly the bind is for
6) Public key
7) Date time of failure.
You can store the log files in your desired location you only have to say the directory name you cannot write the log file name this tool will take care of it. Say if you want to store it in C drive then you have to click on settings button you will get one new popup window there you can enable custom path and write c for drive. This directory should be clean, and only contain files that the runtime generates. If it contains an executable that generates a failure to be logged, the failure will not be logged because the tool tries to create a directory with the same name as the executable. In addition, an attempt to run an executable from the log location will fail.
However, you have to take care of deletion/clearance of the entire log files generated by tool. It will not be deleted automatically. If you will not select custom path to store the log files then this tool will generate this log files in wininet cache, and therefore automatically cleans it out.
Now I started using this tool whenever I got any assembly binding related problems because it saves my hours that I wasted digging into the problem by doing hit and trial methods. You can also read Suzannes article for more details.