Ever since I posted this blog entry last month about how the Administrative Tools shortcuts were moved from the .NET Framework 2.0 redistributable to the SDK, I have gotten multiple follow-up questions and comments from customers about this scenario. In most cases, the folks who contacted me are system administrators who manage servers and want to change .NET Framework security settings but do not want to incur the overhead of installing the entire SDK on their server.
I was on the .NET Framework setup team when the decision was originally made to move the configuration tool to the SDK and remove the wizard tool altogether. At the time, the setup team and the feature teams decided that these type of graphical user interfaces were advanced features more appropriate to an SDK than to a redistributable that is intended to be installed on end-user machines. For example, many end users on XP Home found it strange to see administrative tools related to a product called the .NET Framework that they did not know was even installed on their system (because it was pre-installed by their OEM or via some other application).
However, after hearing so much feedback I decided to dig into this scenario in a bit more detail, especially considering that I hadn’t thought through the scenario where a system administrator would have to install a 300+ megabyte SDK in order to manage security policy settings.
According to the folks I know on various .NET Framework teams, the official way to administer security settings on a system that only has the .NET Framework 2.0 redistributable installed (and not the .NET Framework 2.0 SDK or Visual Studio 2005) is to use the command-line tool named caspol.exe that ships in %windir%\Microsoft.NET\Framework\v2.0.50727 as part of the .NET Framework 2.0 redistributable. There is some in-depth information about how to do this in this MSDN document.
That being said, I decided to look into the .NET Framework 2.0 SDK setup to see exactly how the configuration tool is installed and determine whether or not there is an easy way to extract that information and transplant it onto a machine with only the .NET Framework 2.0 redist installed. I started by downloading the .NET Framework 2.0 SDK, extracting netfxsdk.msi from the setup.exe package and opening it in Orca. I found the following information:
- The configuration tool appears to be comprised of 4 files – mscorcfg.dll, mscorcfg.msc, mscormmc11.cfg and mscormmc.dll
- The file mscorcfg.dll is installed to the GAC and to the local file system
- There are several registry entries associated with the component that installed mscormmc.dll
- There is a shortcut to mscorcfg.msc that gets installed to the Administrative Tools folder on the system
Armed with this data, I decided to experiment a bit and see if I could build an MSI package that would install the configuration tool on a system that already had the .NET Framework 2.0 installed. I used the WiX toolset and created an MSI with the information described above. Then I installed it on a system that had only the .NET Framework 2.0 redistributable and it appeared to work correctly, though I haven’t used this tool much in the past to truly know how well it was functioning.
If you are curious, you can see the WiX source (WXS) file that I created for this experiment to get a better idea of how things are structured, and you can compile it into an MSI yourself by downloading the latest build of the WiX toolset. Alternatively, you can download a compiled version of this MSI from this location.
Please note that while it appears to work correctly, this method of installing the .NET Framework 2.0 configuration tool is unsupported. For example, if any security related issues were to be found in any of these files, they would not be serviceable if installed on a system using a means such as this.
<update date=”12/17/2008″> Updated the WiX source code from WiX v2.0 to WiX v3.0 and added a download link for the compiled MSI. </update>
<update date=”3/11/2009″> Updated download links to point to my new file server. </update>