June 17, 2010
I had to put one feature (assembly redirections) away, but it is still worth it. I believe I will put this back as soon as I found some details on how this works. The new version also fixes the Directory Scanner. I realized the "recursive search" does not work as expected and influences the final results.
From now on, the application will be always compiled against .NET 4. If you need the older version for .NET 3.5, the link is available on the home page. However, the development of this is discontinued so you should not expect any new features or bug fixes for this old version. I am not capable of developing both of them at once. If you really hit an issue, I am still available on my e-mail so you can send me a note.
June 3, 2010
Seems to be a bit tricky and I had to remove few little features (like analyzing redirects) but I am going to add them later. CheckAsm for .NET 4 is not really done yet, but I can offer a preview version on demand. Just ask at checkasm@booring.net.
May 19, 2010
Only patches were released in the last months, no new features were added. However, new Visual Studio 2010 is out with the brilliant new .NET Framework 4 and a new way of referencing assemblies. I am working hard to make CheckAsm to analyze them. While the current version is not able to load a .NET 4 assembly at all, I am planning to release a preview with a limited support soon, most likely in the end of this month. Please be patient and watch the RSS channel for new updates.
September 26, 2008
After ten days I noticed that the 3181 build was a debug build with a test exception in the main code, so the application was not usable at all. I am very sorry for this. The 3191 is now available for download.
September 2, 2008
I received two bug reports on Friday, one was in French and the other one was in English. I was not able to resolve any of the bugs, so please, if you are interested in solving the bugs, contact me via e-mail checkasm@booring.net. Thanks.
July 26, 2008
I managed to add the new functionality mentioned before so now you can find a new menu item (Tools - Scan Directory) in the CheckAsm. The idea is that the scanner reads a full content of a folder looking for .NET assemblies and then performs a fast check on them. If a reference is missing, the result is displayed red and if you want, you can do a thorough scan of the assembly.
July 20, 2008
I found a new feature I would like to have in the CheckAsm - a simple directory scan. The idea is that application will look in a directory for all present .NET assemblies and will perform a quick check on them. Every error will be reported and user can perform standard check on the wrong assembly to get more information. I am currently working on this and I think it will be ready on the next Monday.
June 10, 2008
My hosting provider had some bug in their information system so they did not notice I paid for the domain registration. Well, I paid one cent more than I was supposed to (by mistake) and they probably compared the payment with "=" sign instead of ">=". So, advice of the week: Do not compare floating point numbers with equal signs :)
I am sorry for any inconvenience caused.
June 02, 2008
So I have added the filtering and fixed some little bugs and I have analyzed a lot of information on the missing assemblies (mentioned in previous post). The assemblies can not be found because they are not in GAC but there should be some publisher policy file specifying the version to use. But since the publisher policy file is on a local computer, I am not going to count with that. CheckAsm is designed to help with building installation packages so you always have to think on customer's computer and his locally set publisher policies. However, dependency bindings can be specified in application configuration files and these files are not supported for now. I am going to add this feature in the next build. Check this site next monday for the new version :)
May 28, 2008
As I wrote two weeks ago, I had received some interesting ideas on CheckAsm features and I started implementing them. You could find searching in the last build, the next build I am planning on Monday will contain filtering.
I tried to run CheckAsm WinXP 64-bit but got into trouble. The win32support DLL file is not working. If you need to run the CheckAsm on a 64bit system, delete the DLL. You will receive a warning and reading imports will not be available, but the application will be still able to determine whether there is everything ok with your assemblies. I will try to get it running on x64 machines, but it can take some time.
I also noticed some of assemblies are not displayed even if your application is working. These are mostly mscorlib.dll and .NET assemblies version 1.0.3300.0 and 1.0.5000.0. This is because the assemblies are not in GAC (gacutil does not show them too) and applications with such references are always loading newer versions of them. I still can not decide what to do with that (so if you have any idea, tell me :) ) but the next build of CheckAsm will contain filtering so you can filter them out (temporarily).
May 15, 2008
I received an interesting bug report yesterday with a package of assemblies included. There was a really large number of referenced assemblies and even few circular dependencies. Analyzing the main assembly took about minute on my laptop so I started to think about speeding the process up. The solution was easy: I added caching. Every assembly information is now cached so every assembly is analyzed only once. Analysing the chinese package takes only few seconds now. I also received few good suggestions and I will add them to the next build which will be released during next week.
I appreciate any comment or bug report so do not hesitate to write me. Use CheckAsm - Help - Report bug...
May 07, 2008
Number of downloads was really low last week, but still, CheckAsm has been downloaded more than 100 times now. I have fixed few bugs on which I got reports - thanks for your feedback. I have one more build to release now and then I will wait for some time to get some reports and maybe even ideas what to do. I'd also like to test the CheckAsm on .NET 3.5 assemblies.
I need a revision on how .NET framework 1.0 and 1.1 assemblies are stored because I guess there is some bug - some of DLL's are reported missing because they are not found in GAC, but they are in Windows\Microsoft.NET directory and they are working, so this is really strange. When I know this, the new CheckAsm release will be done along with some minor UI bug fixes and minor features added (like sorting on GAC listing).
April 29, 2008
Also first bug report has been submitted today. Although exception information was written in Spanish, I was able to fix the bug. Hot fix is available for download now.
April 29, 2008
I found this blog post on CheckAsm and it was really great feeling to read a comment on it. So I have added "Reviews and Comments" section on the main page of this site and I hope there will be more soon:)
The blog post: Julie Schlosser, Inetium.com
April 25, 2008
I have changed so many stuff in CheckAsm that I decided to add a .1 to version - so now CheckAsm is in version 1.4, build 3040. Celebrate! :)
I found a bug in win32support.dll. If an assembly had a lot of references and all the referenced assemblies were read for DLL imports, a piece of memory "got lost somewhere" and this caused an exception. This is now fixed and I hope I will do not find any other bug in this library, because I really do not like C++ :))
I finally managed to draw new icons and finally realized there is a "bit-depth" property on the tree view control, so now the icons are new and look good (not like 8-bit :) ). I was thinking a lot about what the icons should look like and could not find anything. So I looked and saw the DLL file icon is a sheet of paper with some sprockets and I saw a lot of files have sheets of paper, so I said 'why don't I use this?' So now we have a lot of colored paper in the application.
I have added bug reporting. If a serious exception occurs, a special dialog with error description and call stack is shown and by clicking the "proceed" button, your web browser is opened and bug report is submitted via my website. I hope this will be useful and I will get a lot of bug reports. Well, I did not mean it the way it sounds :)
So, now we have version 1.4 and I will make some little bug fixes till next build and then the application is probably done. I hope you like it.
April 25, 2008
Unloading assemblies (the promised "better memory management") seemed to be tough issue but in the end it was quite easy. I need to do some tests and then I will make a new release build (probably on Monday). I also changed icons and added application icon, finally :)
I also noticed some problems with assembly versioning so I need to take look at it, but this will be fixed after the next build.
April 18, 2008
I was trying to do something to unload assemblies from memory, when they are tested, but I reached a dead-end. I just can not unload an assembly, there is no Unload() function. What I have to do is to run the analysis in a special AppDomain and then throw the AppDomain away (unload it). This will be the "better memory management", however this needs a large redesign of code so the next build will be without this feature. Unloading assemblies will be done in the build after the next one. I am sorry.
So now you can experience a problem: you load an assembly to view its dependencies, and it is dependent on e.g. MyAssembly.dll version 1.1. Then you try to open another assembly, which depends on MyAssembly.dll version 1.0. This results in error, just because assemblies are not unloaded now. The only workaround for this is to restart CheckAsm.
April 10, 2008
I have one more tool for downloading on this website - AssemblyTest. I made this simple tool beacuse I found out sometimes an application crashes before the Main() function is entered. This is mainly caused by a missing assembly and the problem is usually in static members of the class implementing the Main().
The panic starts when you execute the application on a customer's machine (with no Visual Studio) and it crashes, so you put some Traces to the code and try it again, but you find the debug output clean. So you have no stack trace, you do not know where the exception occurs. It is easy to prevent this behavior (just create class Program with the only function Main in which the main class of your project will be instantiated and started - this is now standard in Visual Studio 2005) but you just can not do a lot of changes in code on customer's machine.
I had this problem and that is why I needed the AssemblyTest. This little application (few lines of code) just starts the application within its AppDomain and catches all exceptions. Here is the main code:
try
{
AppDomain.CurrentDomain.ExecuteAssembly(args[0], null, new string[] { });
}
catch( Exception ex )
{
Console.WriteLine( ex.ToString() );
}
It is good to have enabled Fusion logging: set EnableLog to REG_DWORD 1 in registry key HKLM\Software\Microsoft\Fusion. AssemblyTest already enables this for you.
April 8, 2008
Side-by-side assemblies are really hell for me. There is no documentation on directory structure and one can only guess how all this works. Well, Microsoft had the brilliant idea of including manifests in DLL files so now CheckAsm parses the manifests and looks for even more imports.
I spent few days finding out how to check whether a DLL is missing or not. This is the solution: CheckAsm parses DLL file header and reads all imports. Then it extracts manifest file from the DLL and reads all side-by-side assemblies. It looks into each directory for each sxs assembly and gets list of files there. Then the list of sxs assemblies is compared with imports which could not be found the standard way (system, system32, windows, %path% directories) so we have finally the missing imports (if any).
Well, I was wondering what if a file does not have a manifest but does import of some mfc 8 library - such file can not be loaded and is considered invalid by system, so I guess my final solution is correct.
April 7, 2008
This was quite stressful. I really needed basic information on what DLL files are imported because when an import is missing, assembly can not be loaded. I googled for solution a lot but I found the only option - analyze DLL headers. And since I am not very good in C++ it was not the right option for me. So the CheckAsm was programmed like "take the binary code and find a string ending with ".dll" in it, check whether it could be a file name and add it to list of imports".
This seemed to be a good solution for that time but I still wanted more. Finally I found some sources of "PE maker" - a tool injecting its code to other DLL files, and there were few functions reading imports of a DLL. That was what I really needed and since it was licensed under GPL, I used that (sources are included in package now).
So now (version 1.3.3020) CheckAsm parses .NET assembly and finds it references and moreover it parses its header and looks for imports. So now you can see what libraries are really missing.
April 2, 2008
CheckAsm is already version 1.3 but I have still some thigs to do. That is why I am going to start this blog about it.
I made this tool because I found there is a lack of such tools. Well, we know Dependency Walker, which is good, but does not show .NET references, and then there is Lutz Roeder's .NET Reflector which is good but too robust.
I had a problem when I installed some of our company products on a clean machine, some libraries were missing and I was not able to find out which ones. So I just made a simple command line tool for analyzing .NET references from which the CheckAsm was created. So the main idea was to have the Depends for .NET.