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

June 14, 2008 (Last Modified: June 15, 2008)

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

When you install Visual Studio (2002, 2003 or 2005) a version of the .Net SDK (Software Development Kit) that corresponds to the .Net Framework version also gets installed. For example, if you install VS.Net 2005 then the .Net 2.0 SDK gets installed. The SDKs contain all sorts of tools to help with .Net applications, including well known utilities like wsdl.exe and xsd.exe. The SDKs are also available for separate download if you are not using VS.Net to develop your applications (what are you using then I wonder…). This post will start a series of three related posts that look through the various executables found in the 2.0 SDK Bin folder (or at least the ones I found on my box) and give you a quick idea of what each one of them is for. I’ll provide links to more information for each one (and here I said I wasn’t doing an article of links) so you can look into them more.

By default the SDKs get installed to_ VSInstallLocation_\SDK_\Version,_ where VSInstallLocation refers to the location where your instance of Visual Studio got installed and Version refers to the version of the SDK. So for example, for VS.Net 2005 by default it will be under Program Files\Microsoft Visual Studio 8\SDK\v2.0 and for VS.Net 2003 by default it will be under Program Files\Microsoft Visual Studio .Net 2003\SDK\v1.1.

Some of the better known utilities:

Some of these are pretty well known and most people can skim them to get to the lesser known ones below.

Wsdl.exe - This is probably one of the most known utilities found in the SDK. This command line tool can be used to generate proxy code from XSD schemas, WSDL files and .discomap discovery documents. This same process is what VS.Net uses under the hood when you add a new web reference and the proxy class is created for you. Check out MSDN docs about WSDL.exe for more information.
Xsd.exe - Again, this tool is probably very well known by .Net developers. This command line utility is another code generation tool that can be used to generate strongly typed classes (including strongly typed datasets) from an XML Schema, as well as perform that operation in reverse to create a XML Schema based on an object. The tool can also infer a XML Schema from an XML document making creating XSD files easier (or at least give you a head start on them). VS.Net uses this type of process under the hood in a variety of places, but most notably when you select Create Schema from the XML menu when looking at an XML document. There is a wealth of information on the XSD tool and what it can do for you. Check out more information here and here. Note that it has some limitations that people aren’t particularly happy with.
GacUtil.exe - This may be a utility that you are either very familiar with, or just heard about depending on if you are strong naming assemblies and populating the GAC (Global Assembly Cache) with your libraries. GacUtil is used primarily to load or unload .Net assemblies from the GAC. The tool also provides the ability to help isolate managed code downloaded from the web and list the contents of the GAC. The windows shell extension (shfusion.dll) does pretty much the same thing when you visit C:\Windows\assembly on your box, or if you use the .Net Framework 2.0 Configuration Tool found in the Administrative Tools of any computer with .Net 2.0 Installed to manage the GAC. The GacUtil executable is usable for batch scripts, etc. and so is much more suited for automated build and deployments. Just like the other well known utilities there is a wealth of information on the GacUtil.exe out there; however, at the time of this writing the direct MSDN link for GACUtil from Google resulted in a Page No Longer Available.
Ildasm.exe - This is the MSIL (Microsoft Intermediate Language - what all managed code is compiled to and the JIT Compiler uses) Dissasembler. I would think this is a really well known utility, but I still come across people that have never heard of it. It is a small GUI application that lets you view the MSIL within a managed code assembly. This doesn’t hold a candle to Reflector (which I really hope you’ve heard of, and if you haven’t go check it out); however, it can still be useful if for whatever reason you don’t have Reflector on the development box. This only shows you the MSIL and manifest information for an assembly. Perhaps because it provides such a subset of what Reflector does is why more people don’t know about it. Start up this application and either load an assembly via the menu or drag and drop one onto the window.
Disco.exe - This is the Web Services Discovery Tool. You’ve probably heard of this tool if you’ve either created several web services that need to be shared, or you’ve taken an MS certification test on web technologies. Sites that expose web services can choose to provide discovery documents that this tool will find when executed against a URL. The Disco.exe then uses these discovery maps to generate wsdl files, xsd files, disco files, and discomap files based on what it finds at the URL that is fed in as a parameter. These resulting files can then be fed to the Wsdl.exe utility to generate proxy code. This tool uses the same process that is used by the Add Web Reference option in VS.Net to interrogate the remote service before using wsdl.exe to create the proxy code. There is more information about disco.exe here at the MSDN link.
Sgen.exe- This tool is the XML Serializer Generation Tool. When you use the XmlSerializer to serialize an object there can be some work going on behind the scenes where some code is dynamically created to serialize the type. Using the Sgen.exe tool will let you pregenerate these helper serialization classes so that they don’t have to be done on the fly at runtime. This is not only a performance enhancement, but it’s also a necessity if the code that would use the XMLSerializer may be in a zone or environment where it doesn’t have sufficient permissions to create this code on the fly (for example a SQL CLR procedure that hits a web service would not necessarily have the permissions to create these classes at runtime depending on the trust mode the assembly was loaded into SQL Server with). Find out more about the sgen.exe and what it can do for you here.
Sn.exe - This one should be very familiar for anyone that is serious about the security of their assemblies and/or loading assemblies into the GAC. The Strong Name tool (sn.exe) is used to digitally sign assemblies with an encrypted key. The tool also allows you to do a whole host of other operations like compare keys, check if an assembly is signed with a specific key, cause your development machine to ignore validation checks for certain assemblies or keys that may be in flux during development, etc, etc.. This is a tool that all .Net developers should be aware of and at least scan through the documentation on it (again, the MSDN link seems to be not available at the time of this writing, so you can check out an article about strong naming, which includes the use of this tool). This tool can have an entire series of posts just on it. In fact I used it when dealing with Strong Naming the Enterprise Library components.
TlbExp.exe - The Type Library Export tool is used to generate a Type Library file (.tlb) from a .Net assembly. For those of you who were not around in the COM days (hmmm, that wasn’t that long ago) components (read .dll files) used type libraries to expose their interfaces and public methods, etc. All the information that is available via the manifest and reflection in a managed code assembly must be exported to such a file if it will be referenced from a COM object. Once this tlb is created you can then register it like you would any COM object on the box (see regasm.exe that is distributed as part of the Framework for more information on this). There is an option in the Build properties to create a type library after a compile, which does the same thing (though maybe not through this command line tool directly) and registers the component. Check out this link for more information (again MSDN link is dead)
TlbImp.exe - The Type Library Importer is the exact opposite from the TlbExp.exe tool, which you would expect. This pulls the information from a COM object and creates an assembly that exposes all the type information in a manifest that managed assemblies will understand. This is what happens if you use the VS.Net Add Reference dialog and select a COM object. Under the hood the same process that the tlbImp.exe uses will be executed and a managed assembly will be created to act as the reference. Check out this link for more information (MSDN link was dead).

Some of the lesser known utilities:

Now I think we will be getting into the utilities that are a little lesser known. I say lesser known because I’m not sure I recognized them right away when I scanned through the Bin directory, but I could just be late to the party with these. These may be helpful to you, or you may never use them at all. I go over six of them in this post, but there are still 22 more that I’ll hit on later posts!

Signtool.exe- This command line utility is used to digitally sign a file for Authenticode. This is different than strong naming your assembly. If you are a component vendor and you want to digitally sign your code so that individuals can verify that it came from you then you would get a digital certificate from a trusted certificate authority (such as Verisign) and then use this tool to include that certificate in the signing process of your code. This probably won’t be used by people who spend their time creating internal applications; however, in the wild though (meaning the internet) you need a trusted certificate authority to agree that your code comes from you and only you (unless your certificate gets leaked….ouch). There is lots of information out there on when you should use digitally signed code and such…Verisign even includes instructions on how to do it. I could find SignTool.exe info on my MSDN Library locally, but when I searched for it on MSDN it didn’t turn up a live link. Interesting how many of these dead links I’m finding. If you are dealing with Click Once deployment you may also come across the need to use this tool.
FUSLOGVW.exe- Okay, so I did recognize this tool when perusing the Bin directory; however, I find that most .Net developers I know have not run into this. I have to say I’ve only had to use it really once. This is the Fusion Log Viewer and before I can really explain what that is you have to understand what Fusion is. Fusion is the process that the .Net Runtime uses to locate and load assemblies into memory. As the runtime JIT compiles MSIL code and executes instructions it loads .Net assemblies into memory, and then the other assemblies the executing assembly uses, etc. The process of locating the assemblies is handled by the Fusion engine. For example, if your code uses another assembly then the assembly may be in the GAC, or the directory with the executing code, or in another directory path. How does the runtime know where to find it? The Fusion engine takes care of that. If you’ve even seen the exception “The system cannot find the file specified” when your code calls into another assembly then you’ll see a need for the FUSLOGVW.exe tool. For more detailed information on how Fusion works then check out the .Net Fusion Workshop site. This has got to be the best description of the whole process and how to debug it there is. It gives a great bit of detail on the FUSLOGVW.exe tool. This tool essentially lets you see the chain of locations that the runtime is looking through in order to find the assembly it needs to load. Pretty helpful in troubleshooting why an assembly isn’t loading.
AxImp.exe - This is the ActiveX Control Importer utility. This lets you take ActiveX controls and host them in a .Net windows forms application. All controls on a windows form must inherit from Control. This tool will take a COM based ActiveX control and generate a wrapper class around the component that does inherit from Control. I’ve never had to do this and never knew this tool existed. It wouldn’t surprise me if the VS.Net IDE did this behind the scenes somewhere. Here is the MSDN link for the tool.
Cert2Spc.exe- This is another tool related to security and digital signatures. This is the Software Publisher Certificate Test Tool. You use this tool to generate a Software Publisher Certification file (spc) that you can then use with the SignTool.exe to digitally sign your code for Authenticode. This is for TEST purposes only.
CertMgr.exe- This is the Certificate Manager Tool. This tool is used to load certificates into certificate stores which allows you to do things like take a Software Publishers Certificate and load that into a list of trusted certificates. That way any code that comes digitally signed by that company (with that spc) will be trusted. If you run this executable with no command line arguments then a GUI will load up. The GUI exposes the same abilities as the command line counterpart. Here is the MSDN link on it. I have to admit I’ve never had to deal with Authenticode and digital signatures on code as all my experience has been building internal applications.

Whew…that was a long post. So, hopefully you’ve learned at least one thing from this post (so at least it was worth your time reading this novelette). What I learned in this exercise (other than what some of these executables do) is that there is a wealth of things available already on my development box that can help me out. It’s finding them and putting them to use that’s the trick.