Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

Policy Exception running code over intranet

Thanks for the answers on my previous post.

Still working on the same .NET Console app, the current problem is this:

I can run the app on my machine, and copy it to other people's machines and run them locally, but I cannot execute the application from a shared folder on an intranet computer. Attempting to do so throws a Policy Exception.

First off, it's not a permissions issue. I can run other apps from the same folder, and the Security settings for the file have Full Control to Everyone.

I looked into the Policy Settings (mostly using MSDN) and the only information I can get out of it seems to say that the default Policy should allow me to do this. Regardless, I can't figure out how to change the Policy for my C++ Console Application.

Wednesday, March 17, 2004

You need to run ConfigWizards.exe which is in the .NET 1.1 runtime folder somewhere and set the local intranet permissions to full.

Wednesday, March 17, 2004

Ah crap, so this means that out-of-the-box workstations can run regular Win 32 apps off the intranet, but not .NET, unless each user runs this Wizard to lower their security level?

Wednesday, March 17, 2004

No, it means you have to assert the permissions you need, when you need them.  See for an explanation of the base class' implementation, CodeAccessPermission.Assert(...) for more info.

Greg Hurlman
Wednesday, March 17, 2004

Code on a network share is, by default, partially trusted and placed into the sandbox. It's no different from code that's run via an HREF EXE inside Internet Explorer.

The motivation is that you don't control the code, so it's not fully trusted like something you installed locally yourself.

Brad Wilson (
Wednesday, March 17, 2004

Brad is, as usual, correct. The .NET Framework has the concept of code access security (CAS), whereby the amount of trust given to .NET code depends on its physical location.

The brute force approach to fixing this is to do what M suggests - go to Control Panel > Administrative Tools > MS .NET Framework 1.1 Wizards > Adjust .NET Security and set the security level for the Local Intranet zone to FullTrust. The problem with this approach is that now you're trusting *all* .NET code that's available on your intranet, which may not be what you want.

The more surgical approach is to give your .NET assemblies a strong name by signing them with your development team's private key (which can be generated by .NET). Then do a once-only install of a policy on your clients' machines that trusts all assemblies signed with your team's key. Now all of your team's .NET assemblies will be fully-trusted no matter where they're physically located.


Author of "Comprehensive VB .NET Debugging"

Mark Pearce
Thursday, March 18, 2004

*  Recent Topics

*  Fog Creek Home