We've previously discussed where the security policy files are located on your disk. Depending on how you install the CLR, you may find that the actual security .config files are missing -- what does the CLR do if it can't find them?
Even if there is a .config file for a particular policy level, if we find a valid .cch file for that level we'll use it instead. The cch files are esentially just a pre-compiled version of the policy level, which we use to speed up loading policy by avoiding parsing the XML in the .config file. (One of the checks we use when determining if the .cch file is valid is to compare its timestamp with the policy file's ... if the policy XML is more recent than the cache, we'll consider the cache invalid).
If there is no valid .cch file for a policy level, the next step is to check for the appropriate .config file. Given the title of this post, I'm going to go ahead and assume that they're missing too :-)
At this point, we need to use the default policy for the given level. Our first attempt is to look for a .default file for that level (v2.0 only). If the machine has one of these, we'll use the custom defaults. Otherwise, we fall back to hard coded policy defaults that are built into the runtime. The hard-coded defaults exactly match the default policy that ships with the framework.
So to summarize, the policy search order is:
With that information we can see what happens if the framework installs without any policy files. The first time managed code is run on the machine, the CLR will go through its search, and fall to step four ... the built in defaults. We'll use them and compile them into a .cch file for that policy level -- which means the next time managed code runs, we'll fnd .cch files with the default policy and succeed at step one.
If you'd really like to get your security.config files with the default policy, throwing a caspol -all -reset will write them out for you.