A lot of the time, someone has written an application that won’t run under the CLR’s default security settings and needs to provide a mechanism for their users to modify the policy easily in order to allow their application to run.
For Whidbey, ClickOnce solves this scenario, but for v1.0 and 1.1 of the CLR, there isn’t as elegant of a solution. What you can do on older versions of the CLR is create a MSI file that contains a snapshot of the modified policy. When this MSI file is installed, it overwrites the user’s existing security policy with the one that you specified.
In order to do this, first modify your local security policy to match the policy you want your users to have (see: My application works from my local machine, but throws a SecurityException when I move it to a network share for more details on this). If you modified the policy in the .NET Configuration Control Panel applet, you’re ready for the next step; if you used caspol, open up the control panel applet.
Once you’ve got the .NET Configuration Applet opened, right click on the Runtime Security Policy node and choose Create Deployment Package. Choose the policy level that you’d like to export (most likely machine), and specify a path where the MSI file should be created. Click on finish and the wizard will package up your policy for you.
Now that you have this MSI file, it’s up to you to figure out how to push it to your users. For an application deployed from a website, you might provide a link to the MSI file and tell your users to click on it the first time they run the application. In a corporate environment, there may be infrastructure already in place to push this update to all desktops.
Of course when ClickOnce ships, the solution to this problem will be to package your application for ClickOnce deployment, and allow the permission elevation infrastructure provide the extra trust your application needs.