Missing Configuration Tool in 2.0 Redist
- From: "Daryl" <Daryl@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 7 Feb 2006 07:29:29 -0800
Background: The .NET Configuration tool (found in Administrative Tools) was
removed from .NET 2.0. The only way to obtain this functionality in .NET 2.0
is to install the complete (~400 meg) SDK. This is not a realistic option
for deployment to user desktops. Enterprise customers NEED this tool.
--- Granular Permissions: ---
..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.
--- Support Nightmare: ---
You are correct that a lot of end users won't make use of this tool. Who
will make use of it? Power users and administrators. How is an
administrator at the help-desk going to fix a .NET permissions problem if the
control panel app isn't on the user's machine? Install the SDK? It's almost
Take a look at some of the other stuff buried in "Control
Panel\Administrative Tools". ODBC Data Sources? How many end users even
know what that is, much less how to use it? But it's installed on their
machine. Do you know why? Because they might need it.
More likely, it will be needed by a DBA who's working over their shoulder,
helping them set up a connection. Either way, it still has to be there for
them to use it.
If we're removing everything that only an administrator or a power end-user
will ever use -- well, why not delete the Event Viewer? Any chance that home
users actually load up Event Viewer and scan through their system logs? I
In fact, nothing in the Administrative Tools folder is needed by most
end-users. That's why they made an Administrative Tools directory in the
first place. It's a place to put tools which are mostly used by
administrators, and maybe a few savvy power-users.
--- CASPOL.EXE: ---
A few MSFT people have mentioned caspol.exe as an alternative. Tell them I
said: You have GOT to be kidding me. A graphical tool was too complex for
end users -- but these same people are supposed to figure out:
caspol -m -ag All_Code -url \\Server\PubDLL * FullTrust -n "MyPrograms" -pp
--- Impact on Busniess Developers: ---
I write custom, internal software to automate business processes. Most of
my apps are installed on between one and ten desktops. Most are signed with
an internal Software Publisher key.
From time to time when an app is deployed, someone might see aSecurityException. If that happens, I'll go to their desk and use the .NET
Config tool to figure out what the problem is and fix it.
We are deploying .NET 2.0 in the next three months. Questions for
Microsoft: Now what? One of my users has a problem with their .NET
permissions. Is it something at the Enterprise or User level, removing a
permission my app needs? Good question, but how am I supposed to answer it
with no Config tool? It's difficult to even VIEW the security policy without
the control panel app, much less FIX things. So now what, Microsoft?
--- Summary: ---
The right thing to do is just put the control panel back into the
redistributable where it belongs. Installing .NET and not getting the
Configuration tool makes about as much sense as installing a sound card and
not getting the volume control. Removing this from the redistributable DLL
seems like such a boneheaded move, that I can only assume it was done to save
a little bit of space. This is a very bad tradeoff.
If you're a developer, please vote on this bug in the Feedback Center!
Search on "mscorcfg" in product ".NET Framework"; there are at least 7 bug
reports. Most have been closed as "By Design". Microsoft needs to reverse
this design decision ASAP.
- Prev by Date: Re: HOWTO Run CASPOL for full trust on UserControl.
- Next by Date: Re: CAS exception - crash
- Previous by thread: Re: HOWTO Run CASPOL for full trust on UserControl.
- Next by thread: Re: Searching on Encrypted Fields