Aaron Stebner's WebLog

Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio

Details about setup for the .NET Framework 2.0 configuration tool

Details about setup for the .NET Framework 2.0 configuration tool

  • Comments 40

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>

 

  • It's important to note that it's just not the shortcuts that were removed - it was everything including what the shortcuts pointed to and their dependencies.

    Administrators should also be aware of how to edit the appropriate XML configuration file or set publisher policies. A GUI interface is handy but not necessary.
  • Two things:

    1) Microsoft, please publish and support a distributeable .NET 2.0 Config Tool.

    2) Could you please publish your MSI you created.
  • Hi ATS - I have delivered the feedback about this tool being in the SDK as opposed to the redistributable to the .NET Framework team, but it would probably help for them to hear it from external customers and not just Microsoft employees.  I encourage you to report this as a bug/suggestion at http://lab.msdn.microsoft.com/productfeedback.

    I am not going to publish the built MSI because of the servicing implications that it causes and because I don't want to give the impression that something like this is officially supported.  It would not be difficult for you to use the WXS file along with the latest drop of WiX from http://wix.sourceforge.net to create an MSI on your own if you really need it though...
  • This is a boneheaded move on Microsoft's part.  It seems like such an obvious mistake, that I can only assume it was done in order to shave a megabyte off the 2.0 redist's download size.

    "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."

    That's why it's located in the Administrative Tools folder.  Take a look at some of the other things in there.  ODBC Data Sources?  Component Services?  How many home users need any of those?  Why not delete the entire folder?

    Here's what I had to say about this in dotnet.security:

    .NET 1.1 had very granular control of permissions.  I could give an assembly permission to read just one drive, or write in only one directory which I had created, or only connect to certain sites, etc.  In short, I could install an assembly with just the permissions it actually needed.

    Now that's all gone.

    It's still there in .NET 2.0 of course, but what good is that with no way configure it?  Microsoft goes to all the trouble of building an incredibly powerful permission-granting scheme in the System.Security namespace -- and then completely removes the only way of interfacing with it.  At this point the user is left to just assign "FullTrust" and hope for the best.  This is not smart, and definitely not secure.

    As a developer, the "safest" thing to do is to install all of my code with FullTrust.  Since the user can no longer tweak permissions, nothing can be fixed after deployment.  Demanding unrestricted permissions for my assemblies makes this a non-issue.  Nothing will ever have to be tweaked, because everything is running with the .NET equivalent of "root".

    Of course, it's only the "safe" option for me, the developer.  It makes life much harder for the people who worry about security.  For the sake of a 3% decrease in download size, Microsoft has taken a large step backwards in security.
  • Thanks a lot!
  • Thanks for the information in depth, but it would help a lot more if you could provide the compiled msi itself, even its not supported.
  • Dear Aaron,
    as a user, I did isntall the redistributable. And I do NEED to adjust security setting for just one program.
    I did not figure out how to use the caspol.exe (as a command line tool it IS more complex).
    I have a dial-up internet conection here in Brazil, so downloading 340 Mb for the SDK is almost impossible.
    Can you PLEASE send me this Compiled Tool you build for me to test? If you can send by email, do it to [ auler (-at-) yahoo (-dot) com ].
    Thank you very much!
  • What do we have to do to get Microsoft to publish a supported 2.0 framework that includes the config tool?

    This is ridiculous. Stop playing Where's Waldo with us. Every time someone on a dev team comes up with a better idea of how a GUI should look or where a tool should be packaged means that there are thousands of man hours that will be wasted while we try to figure out what you changed. Please preserve our investment in "know how" by not changing stuff just for the sake of change.
  • Can you send me the msi. My email is s.spence@tvdsb.on.ca.  

    Thanks for your assistance on this item.
    may 15, 2006
  • Removing a tool, only because is for administration, is ... let's be gentle and say not smart enough, especially for someone who seems to know what web applications administration means.
    Thank you, anyway, for guiding us http://lab.msdn.microsoft.com/productfeedback, to correct your team's errors. Are there other things we should know about???
  • Hi Marion - I have heard a lot of similar feedback about this particular issue and I have delivered it to the .NET Framework setup team for future consideration.  I encourage you to vote on the bugs that exist for this issue on the Product Feedback site as well because the team tends to give more consideration to bugs that have more votes from customers in the field.

    I'm not sure what you mean by "other things we should know about" though.  What kind of things are you referring to in that question?
  • It's better for f** smarties in "setup team" think twice before doing so stupid decisions. It's OBVIOUS w/o any f** "votes" that this tool is ABSOLUTELY NEEDED.

    When M$ will stop thinking INSTEAD of users? What about ASK 'em?
  • Hi Thorn - There is no disputing the need for this tool, that is why it is still shipping (although it is in the SDK and not the redistributable).  At the time this decision was made, the theory was that enabling administrative tasks was not something that made sense to include in a redistributable package (plus it added a megabyte or so to the redist size), so the decision was made to move it to the SDK.  We didn't really have a mechanism to poll users to ask about this kind of scenario, but that is part of what we hope to achieve with the Product Feedback site and the voting mechanism.  I hope to convince the team to move this tool back into the redist based on the feedback I've received on my blog, but I am not actually on the .NET Framework setup team anymore so I don't have a lot of influence into what they decide to do.  Hearing feedback directly from customers via the Product Feedback site lends a lot more weight to my suggestions, so that is why I suggest voting on the bug reports if you haven't already.  I apologize for the hassle that this decision has caused you.
  • Can you send me the msi. My email is 13318970808@gd165.com  

    Thanks for your assistance on this item.
    june 08, 2006
  • The link to the WXS file seems to be broken.
    How can we get the source files.
    Thanks for your help.
Page 1 of 3 (40 items) 123
Leave a Comment
  • Please add 5 and 1 and type the answer here:
  • Post