Introduction
Before .NET, my company had several network servers that were used as a place to store applications. If you wanted to use one of these apps you had to have a mapped drive to the network server. Then you could launch the app from there. So the EXE was stored on the network, but the app would still run locally when launched. We used Delphi so there was only the EXE, no DLLs to install, register etc. Now with .NET, the Windows apps have to be installed locally for them to be fully trusted. There are several publications that list all of the things that are not trusted from an application that is not installed locally. Some examples are, no file IO, no access to registry, no access to database stuff, the list goes on. Installing an application locally is a pain especially when it comes to releasing a new version. It needs to be released to everyone who has already installed it. It is a lot nicer just to release it to one spot on the network. Of course, you do have to make sure no one is using the app when you release it to the network. Or you have to bounce them out of the app. Still you only have to release it to one place.
Background
So there are options in .NET for distributing applications. If you have a local intranet you can host an ASP.NET application. This can be somewhat limiting for extremely complex applications that are better suited for a Windows style application. It is not always easy to release something new on the web either even if it is your local intranet. You can use a web server to help distribute the application. Something like: it checks to see what version you have locally and if there is a newer version it is installed locally and then launched. You can use terminal server. The application only exists on the terminal server and your users have to log into the terminal server to access the app. We have tried all these approaches and personally I don't care much for them. So on to the next two. First, the one I like best, create a machine level runtime security policy. Then put it into a MSI script and have your users run the MSI script (they only have to once), or have Active Directory distribute the MSI script at login. This policy marks a network server and folder on that server as fully trusted. The other option is to use the SN.exe tool to create a strong name key and mark all of your applications with the strong name key and then create a runtime security policy allowing anything with that strong name key to be fully trusted. In part 1 of this article, I will only be reviewing how to do the machine level runtime security policy that marks a network folder as fully trusted.
How do you do it...
First, let me show you the error you get if you try to launch a .NET app from the network when it is not fully trusted.
Next, I will describe how to do the run time security policy that marks a network server and folder as fully trusted. This is something we are currently doing and it seems to be working well. You set up a machine level runtime security policy in the .NET framework configuration tool, which can be found in Control Panel->Administration tools. Note that if you are not an Administrator on your PC, you will not be able to set a runtime security policy. Under Runtime Security Policy\Machine\Code groups\All code\localIntranet_zone\, you want to add a child code group.
Put in a name and comment for the new code group and click next.
Now you need to select the URL from the drop down and put the servername\foldername in the URL textbox. It should follow this format: file://SERVER/Folder/*. Then click Next.
Next you need to select what security you want this folder to have. Full trust is what I usually pick, but there are several options. Then click Next and finally click Finish. At this point you would be able to launch a .NET Windows app from the server\folder you just set up in a code group and you would not get a security violation.
Creating the MSI script
On to creating the MSI script for this code group. Click on the runtime security policy. You should see an option for creating a deployment package. Click that option.
Next you should select the machine on the radio group and put in a local path and name for the MSI script.
Click Next and click Finish.
Conclusion
Now you have an MSI script that people can run, they only have to do it once, and they will be able to launch a Windows .NET app from a network server and they will not get a security violation. Note, when the MSI script is run, it will replace any current runtime security policies on the machine level. You can distribute the MSI script over Active Directory, but I will not include that in this article. In part 2 of this article, I will discuss how to do something very similar to what we did in this article except we will be using a strong name key instead of a URL to grant full trust rights to an application.
