Deploying Policy on v1.0 and 1.1 of the CLR

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.

.NET Configuration Applet Deployment Wizard

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.

Comments (9)

  1. Fred says:


    I don’t thing msi just copy a file in a directory because the installation does not apply a policy to a code group if it already exists on the target computer.

    The target policy is not overrided.

    There should be some kind of validation somewhere.

  2. Shawn says:

    Hi Fed,

    Actually, the MSI will overwrite any existing policy, which is one of the reasons that it isn’t as ideal a solution as what ClickOnce provides. Since the policy is overridden by each MSI file, then you run into an issue where each application that requires you to update your policy will overwrite any other apps that have already modified the policy. For this reason, its a good idea to also provide instructions on the website for manual updating of the policy (so that advanced users can do this for more than one application).


  3. Fred says:

    Hi Shawn,

    OK, I redo that again and effectively the policy is overrided.

    I don’t understand, because I made a try yesterday and I concluded differently.



  4. Shawn says:

    Hmm … well, I can think of two possibilities.

    1. You didn’t have the correct permissions to overwrite the policy

    2. You accidentally created a deployment package for a different policy level than most of the policy is on. By default, the security policy lives in the Machine level, if you created an Enterprise level MSI, this won’t touch the machine level one.


  5. Melissa says:

    Creating the msi file works slick, but my testing indicates running the msi once installs it, second time uninstalls it, third time installs it, etc. We’re planning on adding this to the login script, but even standard msi switches to force installation (msiexec /i <filename.msi>) it still toggles install then uninstall.


  6. Joao Maia says:


    I am trying to deploy a hosted component on version 1.1 of the CLR using this method, but I came across a potential problem. In order for it to work, I had to create two fully trusted code groups: one with a Strong Name condition for my dll, and another with a zone condition for the site it will be hosted in.

    The problem is that this component is part of a product my company is selling to several customers, and the name of the site changes from customer to customer (depends on which server the site is installed on). So, I’m guessing that I cannot just create the fully trusted code groups in my machine and then create the msi, because in our customer’s production machines, the zone code group will have a different condition…

    Any ideas on how to get around this problem ?



  7. Hi Jim,

    If you’re trusting based upon strong name, then you could also simply add the StrongName code group as a child of the AllCode root code group.  (ie, don’t put it under a Zone group at all).  This way, no matter what zone your strong named assembly is loaded from, it will always be granted trust.