Here is a nice tid bit of information. A feature added to the .NET framework called CAS (Code Access Security) was designed to allow you to run .NET code in a sandboxed environment (much like running Java applications in the Virtual Machine). Java applets (Java programs embedded into a web page) by default can not do things like read files on your hard drive. The .NET framework has similar security features.
By default, applications run from your own computer (off your own hard drive) have Full Trust. This means that it can pretty much do anything to your computer that you as a user have access to do. The CAS system uses the same zones that internet explorer uses (IE -> Tools -> Internet Options -> Security Tab). When you try to run a .NET application from a network share or mapped drive, that application falls under the Local Intranet Zone. This zone is more restrictive and keeps applications from behaving badly and deleting all your files (unless you copy it to your local drive).
There are a few solutions to this problem. One is to trust the application. This requires that you sign the application with a strong name. I am not going to go into much detail on this except to say that you would have to do this for each application (and possibly it’s DLL files).
This particular article is not about deployment (there are many good articles on that topic). This article is more specifically for development. The presence of the CAS system makes it difficult to keep your project files on a file server. You get a message similar to this:
The problem isn’t generally that the code won’t open, it is that when you hit that play button to run your program, it may not be able to run then. When you are writing the software, you want the program to run as if it is on your box.
Signing each component could become quite a burden if the resulting application does not require signing when you release it. If you are like me, you have many projects on your file server and signing each one would just take more time out of your busy day. Since you have control over your file server, you can generally trust the information on it. Here I will show you a technique that will allow you to give Full Trust to a mapped network drive. This could be a security hole, so make sure you really do trust the server that is storing your project.
The nice thing about trusting a mapped drive is that you can trust all projects on that drive. Just run the command once and forget about it.
First, change to the directory where the caspol.exe file is located. You can change the version directory (the last one) to suit your installation, but any of the three should work (.NET 1.0, 1.1, or 2.0). We are using the directory for version 1.1. Open a command prompt (Start -> Run -> cmd -> Enter) and type the following.
Before we show you the actual command, lets demonstrate something. You can see a list of items already in place. The following is the command to show the list (in bold) followed by its output.
Notice the numbers (1.2, 1.2.1). This will be needed when we show you the command. Notice that it is a hierachal layout. We will put our item under the Local Intranet section as a mapped drive exists on the local intranet.
The next thing you will need is a mapped drive. I mapped a Z drive to my network share. If you don’t use the drive letter Z, replace that with your own. Ready for the command? Here it is.
Lets break it down now. The -q option just means quite. The -machine option causes the change to happen at the machine level, meaning it will modify your machines configuration. The -addgroup option says put the new item under the 1.2 group (see the previous list, it puts it in the Local Intranet section).
The -url option is the one that says what path to trust. You could probly use a UNC (Universal Naming Convention) path instead of a mapped drive. You could also use an HTTP address here (it is expecting a URL after all). The key thing to remember is that it expects a URL, so any file paths (UNC or mapped drive) will require the file:// item at the beginning.
By having the * symbol after the drive letter, we are saying trust ALL folders in this path. If we left it off, we would only be trusting that directory and not all subdirectories.
Next, we fill in the trust we want to grant (Full Trust). We could deny running code here if we put in Nothing, but instead we want code to run from this mapped drive as if it were on this computer. Here is a list of possible options we could put in there.
The last two options allow you to specify a name and a description. You need this to be able to identify your group later if you need to remove or modify it.
Once you have granted trust rights to your application path, you can see it in the list. Run the same command again and look at your new item.
Notice your new item. From here on, you should be able to open up your Visual Studio projects and run .NET applications from a shared drive without the trust warnings or errors (you might need to close Visual Studio completely before it will work).
Before we go, I want to leave you with the command to remove a group once you have added it.
Notice that the label is the numeric value in front of your item when you use the -lg option to list the groups. Be careful not to remove one of the system groups or you will give yourselfe a very big headache. Use the FULL label for your item (not 1.2, but 1.2.3!).
Hope this helps!
Computer Magic And Software Design