در قسمت قبل یاد گرفتیم که اگر یک ناشر، باگی را در یک اسمبلی برطرف کند، باید مدیر سیستم با تغییر فایل پیکربندی، نسخه‌ی جدید اسمبلی را به CLR معرفی کند. ولی اگر ناشر بخواهد این اسمبلی را در اختیار همه‌ی کاربرانش قرار دهد و به همه‌ی کاربران بگوید که باید فایل را تغییر دهید، این روش آن چنان راحت و مناسب نیست. به همین دلیل ناشر باید یک فایل تعیین سیاست داشته باشد، تا این کار راحت صورت بگیرد.
بیایید فرض کنیم که شما، ناشر این اسمبلی جدید با رفع باگ‌های اسمبلی قبلی هستید. موقعیکه شما یک اسمبلی جدید را توزیع می‌کنید، به همراه آن فایل پیکربندی جدیدی را تشکیل داده و ارسال می‌کنید. این فایل پیکربندی جدید دقیقا شبیه به همان فایل پیکربندی است که با آن آشنا شدیم، منتها همنام اسمبلی مورد نظر می‌باشد؛ مثل dotnettips.config برای dotnettips.dll.

<configuration>
     <runtime>
        <assemblyBinding xmlns="urn:schemas­microsoft­com:asm.v1">
           <dependentAssembly>
                <assemblyIdentity name="SomeClassLibrary"  publicKeyToken="32ab4ba45e0a69a1" culture="neutral"/>
                <bindingRedirect   oldVersion="1.0.0.0" newVersion="2.0.0.0" />
                <codeBase version="2.0.0.0"  href="http://www.Wintellect.com/SomeClassLibrary.dll"/>
             </dependentAssembly>
        </assemblyBinding>
     </runtime>
  </configuration>

در واقع این فایل، تنها یک تعیین سیاست برای این اسمبلی است و تنها از همین المان‌هایی که در بالا می‌بینید، می‌شود استفاده کرد و المان‌هایی غیر از آن‌ها مثل Probing یا publisher policy در اینجا قابل استفاده نیست. خطوط بالا به CLR میگویند، هر موقع به نسخه‌ی یک این اسمبلی ارجاعی را داشتی، از نسخه‌ی 2 آن استفاده کن. برای ساخت فایل بالا می‌توانید از طریق دستور زیر نیز اقدام کنید:

AL.exe /out:Policy.1.0.SomeClassLibrary.dll
          /version:1.0.0.0          
/keyfile:MyCompany.snk         
/linkresource:SomeClassLibrary.config

تشریح دستور بالا به شکل زیر است:

سوئییچ out باعث ساخت فایل PE با نام مشخص شده می‌باشد که تنها شامل یک manifest می‌شود و شامل 5 بخش می‌شود:
  بخش اول شامل عبارت policy است تا بگویید که این اسمبلی شامل یک فایل اطلاعاتی درباره سیاست‌های تعیین شده است.  بخش دوم و سوم مربوط به ورژن اسمبلی است که به ترتیب major و minor آن مشخص می‌شوند و این سیاست‌ها فقط روی این نسخه‌ها اتفاق می‌افتد. ادامه شماره نسخه‌ها چون revision number و ... اهمیتی ندارد و فقط همان دو مقدار اول شرط اصلی هستند. بخش چهارم هم شامل نام اسمبلی مربوطه می‌شود و بخش پنجم هم پسوند اسمبلی است.

سوئیچ version تنها مشخص کننده ورژن فایل پیکربندی است و هیچ ارتباطی با ورژن خود اسمبلی ندارد. این ورژن به این دلیل است که مثلا امروز ناشر دوست دارد که CLR به جای اسمبلی 1.0.0، نسخه‌ی 2.0.0 آن مورد استفاده قرار بگیرد. ولی در آینده تصمیم می‌گیرد از نسخه‌ی 1.0.0 به نسخه‌ی 2.5.0 هدایت شود و در اینجاست که بالاترین نسخه‌ی فایل پیکربندی مورد استفاده قرار می‌گیرد.

سوئیچ KeyFile بدیهی است که فایل سیاست‌های یک اسمبلی با نام قوی نیز باید با جفت کلید عمومی و خصوصی که برای خود اسمبلی مورد نظر استفاده می‌کنید، امضاء شود و بدین ترتیب CLR این اطمینان را کسب کند که واقعا این فایل پیکربندی متعلق به آن است.

سوئیچ linkresource هم میگوید که فایل پیکربندی قرار است جدای از اسمبلی باشد و ناشر باید این فایل را به همراه نسخه‌ی جدید اسمبلی ارسال و توزیع کند. شما نمی‌توانید با استفاده از سوئیچ EmbedResource فایل پیکربندی را داخل اسمبلی قرار دهید؛ چون CLR انتظار دارد این فایل جدا باشد. (در مورد این سوئیچ‌ها در قسمت شانزدهم توضیح داده‌ایم)

در صورتی که اسمبلی جدید ناشر، باگ‌های بیشتری به همراه داشته باشد، به طوریکه ادمین میخواهد فعلا این فایل سیاست‌های تعیین شده جدید را موقتا لغو کند، می‌تواند تگ زیر را در فایل پیکربندی اصلی به کار ببرد:

<publisherPolicy apply="no"/>