08.09.2006
With the introduction of .NET 2.0 Microsoft introduced quite a few neat security related features, giving you the ability to micromanage security at code- & assembly-level using something called Code Access Security.
In short it allows you to restrict the access the code is given to the system, independent of how priviledged the actual user running the code is.
It also allows to define what rights can be granted based on the origin of the code. Now this makes sense. Random code run directly from the Internet can make sense, as long as access is severely restricted, while applications installed and run locally probably will need more access and can be trusted access to more parts of the system.
However, Microsoft decided that any code on your Local Area Network is not to be treated as local code, and imposes severe restrictions on the actual rights given to the code.
When you have code on the server, have your assemblies on the server and want to work on this trough a network share, this becomes tedious to say the least. Most of Microsofts documentation also seems to focus on how you can limit the rights given to your code design-time. Very little detail is given on how you can easy up on these restrictions on system-level, when you don't have the option or ability to alter design-time specs, from for instance 3rd party assemblies.
After searching a long time I found this article over at the MSDN Blogs. A straight forward, easy to modify example of just how you can make the .NET Framework trust your network shares, using the commandline-tool caspol.exe.
Also, if you install the Microsoft .NET 2.0 SDK, you can use the management console snap-in neatly hidden in "C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\mscorcfg.msc" using a GUI tool.
You may now develop yours applications without the (in my opinion) overly zealous .NET security getting in your way.