.NN #1: .Net 2.0 SDK Tools (Part 2 of 3)

[Edit 3-22] - Series Name change from DNN to .NN.

This is the second part of a 3 post series on the executables found in the Bin directory of the .Net 2.0 SDK. You can check out the first post here. In the first post we covered probably the most well known of these executables, such as wsdl.exe and xsd.exe along with a dozen others (both well known and lesser known). This installment will cover a dozen more executables and their purposes.

• Clrver.exe- This command line utility is used to determine what version of the CLR processes have loaded. A process can only have one version of the CLR loaded at a time. Depending on how the CLR was loaded could determine what version the process has in it, which may not be the version you’re wanting. An example of this was just on a recording of Hanselminutes where there was an ASP.Net and ASP hybrid application that was showing some odd behavior. If an aspx page was hit first then everything worked well; however, if an asp page was hit first (as in the first request to the application period, not just the first request in a given session) then all subsequent calls to an aspx page would result in an error. What was happening was that the asp page was hitting a COM component that called into a managed .Net component. Apparently, when the CLR is loaded via InterOp like this it uses the highest version of the .Net platform registered on the box regardless of what the managed component was compiled against or registered for. This command tool could let you peek into a process to see what version of the CLR is actually loaded. Just running the command with no arguments will tell you what versions of the Framework are on the machine. You can also get a list of all processes on the machine using the CLR and what version of the framework they have loaded, or you can request the version of the CLR used by a particular process (via process Id). There is a sample that uses this command utility on MSDN. You can also check the Hanselminutes episode (which includes the debugging issue and how they solved it, but doesn’t mention the clrver utility), which is actually on how to interview developers.
• Cordbg.exe- This is the Common Runtime Language Debugger tool. It can be used to start debugging sessions against running managed code processes. On a development box I’m not sure I’d see much point in this since you have a very nice IDE to do debugging with; however, on a box that may not have VS.Net (say a test box) you can use this utility. They even ship the source code of this tool as a sample application. Some of the operations you can do with this is attach to a process (and app domain within a process), kill a process that is being debugged, dump memory, etc. Basically it looks like all the operations you can do while debugging within VS.Net can be performed with this command line utility. Find out more about this on MSDN. This utility ships with the 1.x and 2.x SDKs, but it is written in native code, not managed code.
• CorFlags.exe- This utility is the Core Flags Conversion tool. Within an assembly there is a corflags value that indicates what platform the assembly was compiled under. .Net 2.0 can run on either a 64 bit platform or a 32 bit platform and assemblies are generally compiled against one platform or the other. If you use ildasm.exe (described in part 1 of this series of posts) and open up an assembly, take a look in the manifest tab and look for the .corflags value to see where the bit is stored. VS.Net lets you handle the platform decision at build time with a compile option in the project properties; however, if you get an assembly that you don’t have the code for and you need to load it on a 64 bit platform in 64 bit mode, then you can use the CorFlags.exe to flip the flag over to 64 bit. Now, this may have completely unintended consequences on the execution of the code, so use this is extreme caution. It’s better to get a version that is compiled against the correct platform. You can read a little more about it on MSDN (I mean a little bit since there isn’t much there) and then another little article here.
• Genasm.exe- Not only had I not heard of this tool I couldn’t find anything in MSDN Library about it and an online Google search turned up only references to it generating errors during builds. It looks to create a design-time assembly that contains the design time properties and attributes from another assembly. I see some references to it in conjunction with mobile development. I contacted the local mobile expert (Nino) to see what he knew about it. It sounds like XML descriptive information is pulled from your custom control and put into an .xmta (i.e., Xml MeTadata Attritbutes) file. Genasm can then use that file to create an assembly metadata assembly. Still unclear as to what this is used for. If you know, please leave a comment!
• Jbimp.exe- This is the Java-language bytecode to MSIL converter tool. This tool can convert some Java-language bytecode (.class) files to MSIL so that they can be executed on the .Net platform. There looks to be some limitations on what it can convert and it is recommended that if you have the source files then attempt to compile using the .Net J# compiler instead of converting the files over the MSIL. Check out the MSDN documentation.
• Lc.exe- The .Net License Compiler is used to generate license files so that they can be compiled into your assemblies. For example, if you are using a 3rd party component that has a license file that is required to have the component run then you can use LC.exe to get that license file compiled into your application so that you aren’t distributing the license file as a separate file (which gives people the capability of using the control in code other than yours). You can check out the MSDN documentation about this (which is sparse at best) and also an article about licensing with .Net.
• Mage.exe and MageUI.exe- While these tools sound like they would work magic, what they do is create and edit assembly deployment manifest information for click once deployments. I guess if you aren’t sure of how click once works it could be considered magic compared to the hell of deployment options prior to click once. The Mage.exe is the command line version and the MageUI.exe exposes the same functionality only through a user interface. There is a bunch of information out there on Click Once Deployment and even a good book on the subject.
• MakeCert.exe- The MakeCert utility is used to create X.509 certificates for testing purposes only. If you are working on a project that requires you to use a certificate and you don’t want to use your real production certificate in development then using the MakeCert utility can produce a certificate suitable to use. You can check out the MSDN information for more information about this.
• Mdbg.exe- This is another debugging tool that is very similar to corDbg.exe except this one only ships with the 2.0 SDK and is written in managed code. This is the Managed Code Debugger tool and it has a command line interface that appears to be exactly the same as CorDbg. You can use this tool to debug both 1.1 and 2.0 managed assemblies, but 2.0 must be installed on the box for this tool to work. Check out the MSDN documentation.
• MgmtClassGen.exe- This is the Management Strongly Typed Class Generator. You would use this tool to generate strongly typed versions of a WMI class that you will use in your code. I’ve not really worked with WMI classes at all, but apparently you have the ManagementClass which is kind of like a generic class that can represent many sorts of WMI classes, such as Win32_Process which is a process. Most WMI work uses the ManagementClass to get at these WMI classes; however, the MgmtClassGen tool can actually generate a strongly typed class to access instead of the generic ManagementClass. Since WMI classes can be all sort of things I can see where this can become helpful. Check out the MSDN documentation. Oh, and this tool uses the System.Management.ManagementClass.GetStronglyTypedClassCode method to generate its code, so you can do the same thing within your own code if you need to.
• Mt.exe- The Manifest Tool is primarily used to embed a manifest file into a code assembly (that presumably doesn’t have one….for example if you compile a C++ project using something other than VS.Net). It also appears to have a great many other options such as pulling out an XML manifest from a managed assembly, merging manifests and generate manifests from RGS or TLB files. I can’t say that I found a lot of information on this tool when I went looking.

Well, that wraps up Part 2 of my look through the Bin folder. I can’t say many of these jumped out at me as something I’d use a lot now that I know it exists. The ClrVer may come in handy on a jump drive for troubleshooting and I need to look more into the mdbg and cordbg tools for being able to debug on a test machine that doesn’t have VS.Net loaded. The next DNN post will wrap up with the final set of ten executables in the Bin folder of the SDK.