In lieu of installing a .NET application (including referenced assemblies) to an Intranet server or network share, you may be tempted to copy your assemblies to a network drive and execute them directly from there. However, if you've ever tried to do this, your application probably threw a SecurityException ...
To get around this, you have a few options that are documented at the .Net Security Blog. You could open up your security policy to fully trust the Intranet Zone, which is probably a bad idea. Or, you could strongly-name each assembly and configure the appropriate permissions for each assembly that you are going to deploy, which is a better idea. However, this means that you need to modify configuration settings on each user's machine every time a new assembly is deployed ...
To avoid this, you could configure a specific network folder (and subdirectories) to be fully trusted. This way, all future assemblies can be deployed to this network folder without the need to individually configure each assembly. Of course, you still open yourself up to rogue applictions that are installed in this folder being fully trusted, but you are more secure than if you fully trusted your entire Intranet!
To fully trust a specific network folder:
- Open the .NET Framework 2.0 Configuration applet,
- Expand the tree to My Computer, Runtime Security Policy, Machine, Code Groups, LocalIntranet_Zone,
- Right-click New... to create a new code group,
- Name your code group,
- Choose URL as the condition type for this code group,
- For the URL, enter a UNC path using the following format: file://\\<network drive>\folder
- On the next page of the wizard, select Full Trust as the existing permission set,
- Click Finish to add the code group ...
To test that your assembly is now fully-trusted from the network path, right-click at the Runtime Security Policy node and choose Evaluate Assembly... . If you navigate to your assembly, you can validate that your assembly is indeed fully-trusted. Of course, you can always execute your assembly to validate that your assembly no longer throws a SecurityException, but using Evaluate Assembly... can come in handy when debugging security problems ...