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

Okay, so after almost a two week break it is time to finally wrap up the third and final part of the .Net 2.0 SDK tools series. This series has covered many of the executables found within the bin folder of the .Net 2.0 SDK. The first part covered some tools that were probably pretty familiar to most .Net developers and second part covered some that probably were not well known. We complete the series with the last ten executables which are probably also not that well known.

• Nmake.exe - This is the next generation make.exe for C++. It builds projects based on commands within a make file. Not much else to add to this one. Check out the MSDN documentation.
• PermCalc.exe - This is the permission calculator tool. It’s used to look through an application and all the associated assemblies to garner the minimal permission set required to execute the application. It keeps it’s own virtual stack trace as it run through all code paths to gather up this information. It handles both imperative and declarative security demands. The output is an XML file that can be parsed to determine all of the permissions required to execute the code. Note that this walks the code paths and references. If your application loads assemblies dynamically you’ll not get the full picture; however, I can see this being useful as a way to document the required permission sets for installation purposes. I can see where this can be very useful and it appears to be new with .Net 2.0. The MSDN Documentation describes the parameters.
• PEVerify.exe - If you are creating a compiler that will generate MSIL and want to verify that your code produces type safe constructs, then this is the tool for you. I think the normal .Net developer would never have need of this tool. If you ever do need to use it then MSDN has you covered.
• Rc.exe - This tool is the Resource Compiler utility. It is used to compile .rc files (resource files) into .res files so that they can be compiled into you assemblies. This tool helps create apps that can be localized by including language specific resources into resource files. I’ve only ever worked on one application that was localized and it really wasn’t all that localized (US and Canada). While it would support the different language resources based on the culture codes the only thing that really changed was like “Postal Code” instead of “Zip code”. More information about this tool can be found on MSDN.
• ResGen.exe - This tool is also based around resources. It can take text and .resx files and turn them into binary .resource files, or take .resource files and decompile them into text and .resx files. This functionality is provided by the .Net framework and this tool just wraps the ResourceReader, ResourceWriter, ResXReader and ResXWriter classes. After you’ve created your .resource files you can link them to your assemblies or create satellite assemblies using the Assembly Linker (al.exe) tool. If you are creating localized applications you should become very familiar with the al.exe tool and possibly the ResGen tool as well for automated builds. MSDN can be consulted for a ton of more information.
• SecUtil.exe - If you need to represent a strong name key or the public key for a X.509 certificate within your code you can use this tool to extract it into text form. You can then take the text output and put that into a constant in your code. Good to know, but I’ve not had to deal with this before. I guess if you wanting to specifically check against a specific X.509 certificate or public key in your code this would be how you can represent that evidence in your code. More here.
• Setreg.exe - The Set registry tool is used to change the behavior of the public key certification process. For example, you can use this tool to have the machine trust all certificates that will get created with the makecert.exe tool. Or you can instruct the machine to okay any certificate even if the revocation server is offline (good for disconnected development environments). Check out the syntax on MSDN. Note that changing how your computer decides to trust certificates can be dangerous and you should only do it if you know what you’re doing.
• SoapSuds.exe - This tool operates much like the wsdl.exe does in generating a proxy for a web service for use via your client application; however, whereas wsdl.exe creates a proxy that will call web services over HTTP the soapsuds.exe tool generates proxy code that will deal with the web service via .Net remoting. Interesting. I’ve only dealt with remoting on one occasion, usually I’m dealing solely with web services via HTTP. MSDN describes the parameters of the tool. Also unlike wsdl.exe the code generated by SoapSuds.exe is expected to be referenced by your assembly, not just embedded into your code which is the usual way to handle code generated by wsdl.exe. At a glance I don’t see where you can control the language output of this tool like you can with wsdl.exe.
• StoreAdm.exe - The Isolated Storage Tool is used to manage existing isolated stores for the current user. You can use this tool to get a list of all the assemblies and applications that have placed data into isolated storage for both roaming and non-roaming lists. This can also be used to remove all existing stores for the current user. If you’re writing smart client applications you may find this tool useful.
• WinRes.exe - This tool is a visual layout tool you can use to help localize your applications without having to have direct access to the source code. For example, if you create an application that needs to be localized you can pass along the work to a 3rd party who could use this tool to load up the resx file and translate your English values into other languages. The output of the tool is NOT interchangeable with the output of VS.Net when it comes to the resx files they produce so when deciding what tool to localize with you must make a choice between one or the other. Check out more on MSDN. The nice thing about this tool is that the 3rd party translators only have to have this tool to do the work and not the full VS.Net IDE. The only things that appear for them to deal with are the localizable items, so it’s less likely that something would inadvertently be changed. Also note that only localized data is dealt with by this tool. Language neutral information will NOT be saved.

That’s it. All the executables from the .Net 2.0 SDK bin directory. Hopefully this series at least gave you one or two helpful ideas of what tools outside of the IDE that are already on your machine. Some of the tools have .Net 1.x equivalents, and some don’t. The next few .Net Nugget posts will be more code based.

Please leave comments on what you think of the series.