The previous release of Serial Key Maker had a minor bug in it; minor – depending on your point of view, that is
For some unknown reason, I was referencing the Windows.Forms dll in my API. So when a user added the Serial Key Maker API reference to his project, Visual Studio pulled in the Windows.Forms dll too, when it wasn’t already referenced. I didn’t notice this because much of my testing involved a Windows Forms application.
However, if you are using the Serial Key Maker API from a console application, or in another DLL, you would not need the Windows.Forms reference, but Serial Key Maker would cause you to need it.
Lesson learned: Make a unit test for a scenario that does not involve windows forms.
This lead me to consider what other objects I had carelessly tied to my application. It turns out a colleague of mine has an application well suited to this problem. I had not used it before and my new problem seemed like an opportunity to take a good look at it. I got a copy of Assembly Inspector and put it to work on Serial Key Maker.
What follows is my review of Assembly Inspector.
Serial Key Maker and Assembly Inspector
Although I know and respect the author of Assembly Inspector, I have done my best to keep this review as unbiased as possible – focusing squarely on the value of the software he wrote. In fact, he didn’t use Serial Key Maker for his licensing solution (Serial Key Maker was not ready when he implemented his licensing solution), so I have no hidden agenda here.
I prize simple, intuitive software that just…works. Assembly Inspector is a huge winner in that category. From installation, to loading my first assembly, to evaluating the output generated, Assembly Inspector is beautiful in its simplicity.
It supports drag-n-drop and provides multiple views of the dependency tree. You can quickly switch from tree view to list view. You can filter out common Microsoft dependencies.
At a glance you can see all the DLL’s that your object is dependent on. The information supplied is everything you need to know about the objects referenced: name, version, location and whether it is signed or not.
At first, I performed a basic test of the Assembly Inspector functionality. A vanilla, “how does it work out of the box” test.
I dropped the Serial Key Maker API dll onto Assembly Inspector. I then dropped my user interface executable onto Assembly Inspector. In both cases, I quickly got a report of all the assemblies tied to my application, and felt confident that Assembly Inspector was correctly reporting how Serial Key Maker was put together. (If only I had looked at this tool before I released my previous version!)
After the vanilla test, I tried to break Assembly Inspector.
I created 4 test DLL’s. DLL1 through DLL4. I made each DLL dependent on the other. I put DLL 2 and DLL4 in the GAC, and left DLL 1 and DLL3 out of the GAC. DLL4 referenced Serial Key Maker. I then referenced DLL1 from Test.Exe
When everything was set up correctly, I tested it with Assembly Inspector, and it reported everything correctly. I then tried the following to break AI
I removed DLL 2 and DLL 4 from the GAC independently
I renamed all 4 DLL’s independently
I recompiled DLL3, breaking binary compatibility
I changed DLL to be strongly named.
In all cases, Assembly Inspector correctly reported when one of the dependencies was missing, or un-reachable. No matter how I tried to fake out Assembly Inspector, it was able to correctly report what was broken, and where it was broken.
After the session, I was left with a high confidence that if Assembly Inspector did not report any dependency issues, then there were none.
The feature that allows you to filter out Microsoft assemblies is an excellent touch!
Often you will want to see and fix that which you have control of. You can usually safely assume the Microsoft dependencies are valid (if they are not, you have other issues, unrelated to the development of your product.). The feature, however, is not complete. I would like to have the ability to filter out libraries by name (including the use of wildcards, and perhaps regular expressions).
The “Hide” feature for Microsoft and System libraries did not exclude “mscorlib” and “Accessibillity”. I could have done that with a freeform text filter.
A practical application of this software for me would be to use it in my unit tests. I would like to be able to call it from my unit test harness, and have it run through its paces and report when I have something missing. Thus, a command line interface would fully complete what I would need out of this application.
Another nifty feature of the reporting, is that Assembly Inspector efficiently removes all duplicate references from view. If two objects reference the same dependency, it is not repeated. This was done, I assume, to streamline the display, and make the dependency list more readable. I would, however, like to be able to toggle this feature, so I can optionally see where each dependency is repeated and used.
In all, I was very impressed with the presentation and function of Assembly Inspector. It accurately told me the state of my application’s dependencies, and provided full comfort that my software was as I thought it was…which is what you want and expect from such a tool.
Summary
Version Evaluated: 2008.10.5.9
Pros: Very clean, simple interface; does exactly what it says it does; accurate and reliable results.
Like to See: Free text filter; ability to toggle seeing repeated dependencies; a command line interface to be able to include Assembly Inspector validation into my unit tests.
Verdict: If you work with and deploy .Net assemblies, Get It!
Posted by serialkeymaker 
Posted by serialkeymaker 
Posted by serialkeymaker 