Policy and Cfg Files
This article is relevant to entity models that utilize the deprecated Visual Studio integration of Telerik Data Access. The current documentation of the Data Access framework is available here.
Vendors of assemblies can state that applications should use a newer version of an assembly by including a publisher policy file with the upgraded assembly. The publisher policy file specifies assembly redirection and code base settings, and uses the same format as an application configuration file. The publisher policy file is compiled into an assembly and placed in the global assembly cache.
There are three steps involved in the creation of a publisher policy:
- Create a publisher policy file.
- Create a publisher policy assembly.
- Add the publisher policy assembly to the global assembly cache.
A Publisher policy statement describes the compatibility of an assembly issued by the publisher of that shared assembly. A publisher policy is commonly used in service pack scenarios, like Telerik Data Access. For example, the Telerik Data Access team produces a number of small releases that enhances certain features. For maintenance reasons, the publisher may wish to collect all of these fixes into a single service pack release and have all existing customers upgrade to the new service pack.
A publisher policy statement is an XML configuration file wrapped as a separate assembly. There are three reasons for which the publisher policies are shipped as assemblies. The first is to ensure that the policy statement comes from the author of the assembly that the policy is making the compatibility statement about. This is accomplished by requiring that the policy assembly has a strong name generated with the same key-pair as the original assembly. The second reason is the ease of deployment. Publishers or administrators can ship policy statements using the assembly deployment mechanisms provided by the .NET Framework, including the Windows Installer and code download. Finally, assemblies ship policy statements so that they can be versioned. This allows the publisher to ship a subsequent statement if a previous policy is found to not work in some scenarios. In effect, this allows a publisher to change his mind about the compatibility of his assembly independent of when it was shipped.
Telerik Data Access offers policy assembly for each one of the deployed assemblies. The policy assemblies could be easily recognized, since they have the following format: policy.[version major].[version minor].Telerik.OpenAccess.[xxx].dll.
On the other hand, the ".cfg" files are XML configuration files containing the compatibility statement. For example, if you use a text editor to open a ".cfg" file, it should be similar to:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Telerik.OpenAccess.35.Extensions"
publicKeyToken="7ce17eeaf1d59342"
culture="neutral"/>
<bindingRedirect oldVersion="2008.0.0.0-2010.2.714.1"
newVersion="2010.2.714.1"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
In other words, the policy file is a compiled version of the corresponding .cfg file.