Ask Learn
Preview
Please sign in to use this experience.
Sign inNote
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
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>
Anonymous
January 24, 2006
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.Anonymous
February 10, 2006
Two things:
1) Microsoft, please publish and support a distributeable .NET 2.0 Config Tool.
2) Could you please publish your MSI you created.Anonymous
February 10, 2006
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...Anonymous
February 13, 2006
The comment has been removedAnonymous
February 16, 2006
Thanks a lot!Anonymous
March 01, 2006
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.Anonymous
March 05, 2006
The comment has been removedAnonymous
March 22, 2006
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.Anonymous
May 15, 2006
Can you send me the msi. My email is s.spence@tvdsb.on.ca.
Thanks for your assistance on this item.
may 15, 2006Anonymous
May 17, 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???Anonymous
May 17, 2006
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?Anonymous
May 29, 2006
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?Anonymous
May 29, 2006
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.Anonymous
June 07, 2006
Can you send me the msi. My email is 13318970808@gd165.com
Thanks for your assistance on this item.
june 08, 2006Anonymous
July 07, 2006
The link to the WXS file seems to be broken.
How can we get the source files.
Thanks for your help.Anonymous
July 08, 2006
Hi Fbarbin - The link appears to be working fine for me. You might have hit some temporary downtime on my file server earlier this morning or something like that. Can you please try to access it again and see if it works for you? If it doesn't, please contact me using http://blogs.msdn.com/astebner/contact.aspx and I can send it to you via email instead.Anonymous
July 09, 2006
OK. It works fine right now. Thanks for your help.Anonymous
July 17, 2006
I ran into an interesting issue when I was working on some of the very early builds of the Windows Media...Anonymous
July 17, 2006
PingBack from http://microsoft.wagalulu.com/2006/07/17/using-custom-actions-versus-using-launch-conditions-in-an-msi/Anonymous
October 30, 2006
Thanks a bunch I got this to work. A couple tips. Download the bin from the wix link you don't need the source. Replace all the GUID in the wxs file as it says witha valid GUID or just make something up (I didn't say that) Then these two .exe's are the ones you want. candle.exe SampleFirst.wxs it will create a .wiobj file then... light.exe SampleFirst.wixobj you're done!Anonymous
November 02, 2006
http://mygreenpaste.blogspot.com/2006/03/net-framework-20-configuration-tool.htmlAnonymous
November 27, 2006
Almost a year after your first post, the redistributable version is still lacking the configuration tool. And I can't find the bug in http://lab.msdn.microsoft.com/productfeedback. Which id does it have ?Anonymous
November 28, 2006
Hi AgainINeedToRegister - Keep in mind that this post was originally published after the final version of the .NET Framework 2.0 was released, and there has not been a new version released since then (yes, the .NET 3.0 has shipped, but it includes the .NET 2.0 in the same form that it originally shipped). I thought that there already was a bug report on this sisue, but I also looked on the product feedback site and could not find anything. I suggest reporting a bug on the feedback site so that the teams in charge of these features will hear additional feedback and possibly be motivated to revisit this decision.Anonymous
January 02, 2007
Please everyone go BACK and re-vote for the currently open Feedback - since Microsoft keeps closing the old ones saying it was by design! The current open one is ID: 244131Anonymous
January 02, 2007
This is big mistake don't include this tool in .NET 2.0 Framework I spent 2 days trying to run .NET 2.0 apps from network share and failed. Stupid caspol tool. At home i'm free from YOURS SUPER EXTRA TECHNOLOGY and keep my hand far away from vista. Ireneusz PiaseckiAnonymous
January 02, 2007
PS - you can still find all the old ones if you simply search for: mscorcfg Of all the relevant results, only 244131 is "Active"Anonymous
January 11, 2007
irekpias, I ran into the same issue you did but figured out how to get caspol to behave by playing around with caspol in v1.1 and seeing how it changed things in the GUI tool. The command you need is: [path to caspol]caspol.exe –pp off –m –ag 1 –url file:s:/dir/subdir FullTrust –name NewGroupName "-pp off" is only necessary if you need to run "silent" "-m" is to change the machine level "-ag 1" adds the new policy after the root (group 1) "-url file:s:/dir/subdir" change s:/dir/subdir to the network drive you have mappted (s: in my example) or to something like //server/share/dir/subdir. You need to specify the location of your executable. "FullTrust" is where the policy goes. You can specify some other policy or create your own named policy with the rights you need. "-name NewGroupName" gives the new code group a name so that you can modify it more easily in the future. Of course you can name the group whatever you want.Anonymous
January 30, 2007
If the concern was that home users were being confused, then Microsoft should have just removed the shortcuts and not the actual mscorcfg.msc and related .dll files. That way admin and deployment people could still actually do their job and home users would not know anything about itAnonymous
January 30, 2007
Hi Tonderum - Just to clarify, the concern was not only home user confusion, but also the increased size within a package that is designed to be redistributed with other applications. I'm not endorsing this concern in this case, but just wanted to mention some of the factors that went into this decision back then.Anonymous
May 30, 2007
Hi All, i have the setup file. i created it using the WiX source (WXS) file that is given here and the wix2.0. i downloaded(wix-2.0.5325.0-binaries.zip) from the link given in the blog. if anyone want the setup file then simply mail me.My mail Id is sudeep_srivastava@semanticspace.com. The total size of the setup is 2.1 MB, and it's tested, it's working fine in my organization. Thanks.Anonymous
June 11, 2007
The comment has been removedAnonymous
July 02, 2007
PingBack from http://www.shirilla.com/index.php/archives/49Anonymous
July 02, 2007
PingBack from http://www.shirilla.com/index.php/archives/50Anonymous
July 02, 2007
PingBack from http://www.shirilla.com/index.php/archives/51Anonymous
July 02, 2007
PingBack from http://www.shirilla.com/index.php/archives/52Anonymous
July 02, 2007
PingBack from http://www.shirilla.com/index.php/archives/53Anonymous
December 11, 2008
Its been almost one and half year and i am trying my best to give the setup file to whoever asked for it as soon as possible. I have one more request when you ask for the setup. when you mail me, please keep sri_sudeep@yahoo.com in CC as sometime i am not able to send mail from office mailId and specially on weekends i don't access my office mail Id.Anonymous
January 20, 2009
PingBack from http://www.hilpers.com/291389-framework-2-0-programme-vomAnonymous
July 01, 2012
So, where is it for .NET Framework 4.0? The SDK is part of the Windows SDK, but it's not in the BinNETFX 4.0 Tools directory (or anywhere else seemingly)Anonymous
July 02, 2012
The comment has been removed