سيستم پيكربندي ASP.NET 2.0

پياده كنندگان برنامه هاي وب كه از فن آوري ASP كلاسيك به منظور پياده سازي برنامه هاي وب در گذشته اي نه چندان دور استفاده مي كردند ( و شايد هم اينك نيز استفاده مي نمايند ) ، به ياد دارند كه اطلاعات پيكربندي برنامه هاي فوق به صورت باينري و در محلي با نام متابيس IIS ، ذخيره مي گردد . پياده كنندگان برنامه هاي وب براي اعمال تغييرات لازم در متابيس از دو گزينه متداول استفاده مي كردند : نوشتن اسكريپت هاي مورد نياز و يا استفاده از كنسول مديريتي برنامه IIS ( سرويس دهنده وب مايكروسافت ) .
برخلاف ASP كلاسيك ، در ASP.NET 1.x حضور متابيس ها كم رنگ گرديد و در مقابل ، استفاده از يك سيستم پيكربندي مبتني بر xml مورد توجه قرار گرفت . عليرغم اين كه سيستم فوق داراي انعطاف بمراتب بيشتري نسبت به نسخه قبلي است ولي امكانات مديريتي مناسبي را به منظور ويرايش فايل هاي پيكربندي در اختيار پياده كنندگان برنامه هاي وب قرار نمي دهد . تنها گزينه موجود براي ويرايش يك فايل پيكربندي ، برخورد با فايل پيكربندي به عنوان يك فايل xml و بهنگام سازي آن فايل بر اساس ماهيت فايل هاي xml است . مهمترين مشكل رويكرد فوق ، برخورد با تمامي بخش هاي فايل پيكربندي به عنوان گره هاي xml است .
در ASP.NET 2.0 ، امكانات و پتانسيل هاي متعددي به منظور مديريت پيكربندي برنامه هاي وب ارائه شده است با اين هدف كه بتوان با سادگي و سرعت بيشتري پيكربندي يك برنامه وب را انجام داد .خواندن و ويرايش فايل هاي پيكربندي در يك ماشين محلي و يا از راه دور از جمله مهمترين ويژگي هاي ارائه شده در ASP.NET 2.0 مي باشد .
اطلاعات پيكربندي يك برنامه ASP.NET در دو فايل مهم Xml ذخيره مي گردد . از Xml براي تشريح خصلت ها و رفتار جنبه هاي مختلف برنامه هاي ASP.NET استفاده مي‌شود . سيستم پيكربندي ASP.NET از دو فايل پيكربندي استفاده مي نمايد :
• machine.config : فايل پيكربندي سرويس دهنده
• Web.Config : فايل پيكربندي برنامه
با توجه به ماهيت فايل هاي پيكربندي ( فايل هائي از نوع xml ) ، عناصري كه مسئوليت تشريح پيكربندي را برعهده دارند نسبت به حروف بزرگ و كوچك حساس مي باشند .
در مثال زير ، يك نمونه فايل web.config به همراه بخش مربوط به معرفي <sessionState> يك برنامه وب نشان داده شده است .

<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
   <system.web>
       <sessionState
           mode="InProc"
           stateConnectionString="tcpip=127.0.0.1:42424"
           stateNetworkTimeout="10"
           sqlConnectionString="data source=127.0.0.1; user id=sa; password=test"
           cookieless="false"
           timeout="20"
       />
    </system.web>
</configuration>

مزاياي استفاده از يك فايل xml براي پيكربندي (در مقابل يك متابيس باينري )
• امكان خواندن اطلاعات پيكربندي وجود داشته و مي توان به سادگي و با استفاده از يك ويرايشگر متن نظير NotePad آنان را ويرايش نمود ( گرچه توصيه مي گردد كه در اين رابطه از ويژوال استوديو 2005 و يا اديتوري كه قادر به تشخيص تگ هاي xml مي باشد ، استفاده گردد). فايل پيكربندي را مي توان به سادگي از يك سرويس دهنده به سرويس دهنده ديگر منتقل نمود . ويژگي فوق در يك Web Farm بسيار مفيد و موثر مي باشد .
• پس از انجام تغييرات مورد نياز در يك فايل پيكربندي ، ASP.NET به صورت اتوماتيك تغييرات ايجاد شده را تشخيص و آنان را در ارتباط با برنامه اعمال خواهد كرد . ASP.NET بدين منظور يك نمونه جديد از برنامه را ايجاد و كاربران را به برنامه جديد هدايت مي نمايد .
• پس از اعمال تغييرات در پيكربندي يك برنامه ASP.NET ، ضرورتي ندارد كه مديريت برنامه سرويس دهنده وب را متوقف و مجددا" فعاليت آن را آغاز نمايد .
• سيستم پيكربندي ASP.NET قابل توسعه است و اطلاعات مرتبط با يك برنامه را مي توان به سادگي ذخيره و بازيابي نمود .
• اطلاعات حساس ذخيره شده در سيستم پيكربندي ASP.NET 2.0 را مي توان در صورت تمايل به صورت رمزشده ذخيره نمود ( اقدامي در جهت افزايش امنيت و ايمن سازي برنامه هاي وب خصوصا" اطلاعات حساس مرتبط با آنان ) .

فايل پيكربندي سرويس دهنده : machine.config

هر سرويس دهنده ASP.NET داراي يك فايل پيكربندي با نام machine.config است كه در زمان نصب فريمورك بر روي سيستم ايجاد مي گردد . فايل فوق در مسير C:\Windows\Microsoft.NET\Framework\v2.0xxxxx نصب و از محتويات آن به عنوان تنظيمات پيش فرض در تمامي برنامه هاي ASP.NET نصب شده بر روي سرويس دهنده استفاده مي گردد . با توجه به نقش مهم اين فايل در عملكرد تمامي برنامه هاي موجود بر روي كامپيوتر ( ويندور ، وب ) لازم است كه تغيير در فايل فوق با دقت خاصي انجام شود و نسبت به نوع كار و دامنه متاثر از تغييرات شناخت كافي وجود داشته باشد .
در صورتي كه بر روي سيستم چندين نسخه از فريمورك دات نت نصب شده باشد ، هر نسخه داراي فايل پيكربندي machine.config مختص به خود است . مثلا" در صورتي كه بر روي كامپيوتر نسخه هاي ASP.NET 1.1 ، ASP.NET 1.0 و ASP.NET 2.0 نصب شده باشد ، هر نسخه فريمورك داراي فايل machine.config مختص به خود است . اين بدان معني است كه بر روي سرويس دهنده فوق سه فايل پيكربندي machine.config وجود خواهد داشت .
علاوه بر فايل machine.config ، فريمورك دات نت دو فايل ديگر را به اسامي machine.config.default و machine.config.comments نيز نصب مي نمايد . از فايل اول به عنوان نسخه backup فايل machine.config استفاده مي گردد. در صورتي كه بخواهيم به تنظيمات اوليه برگرديم ، كافي است تنظيمات موجود در فايل machine.config.default را به فايل machine.config كپي نمود . در فايل دوم ( machine.config.Comments ) ، هر بخش از فايل پيكربندي تشريح مي گردد .
ASP.NET runtime ، از دو فايل فوق استفاده نمي نمايد و صرفا" بدين جهت نصب شده اند تا در صورت ضرورت از آنان به منظور برگشت به حالت اوليه استفاده نمود ( default factory setting ) .

فايل پيكربندي برنامه : web.config

برخلاف فايل machine.config ، هر برنامه ASP.NET داراي نسخه اختصاصي تنظيمات پيكربندي مختص به خود است كه در فايلي با نام web.config ذخيره مي گردد . در صورتي كه برنامه وب داراي چندين Subfolder باشد ، هر subfolder داراي فايل web.config مختص به خود است كه محتويات آن از تنظيمات موجود در فايل پيكربندي parent به ارث رسيده است و يا تنظيمات مورد نظر را خود تعريف مي نمايد .
براي بهنگام سازي سرويس دهندگان در farm ( بر اساس تنظميات جديد ) ، مي توان به سادگي فايل web.config را به دايركتوري مربوط به برنامه كپي نمود . در چنين مواردي ضرورتي به دستيابي سرويس دهنده محلي و راه اندازي آن وجود نداشته و برنامه ادامه فعاليت خود را به صورت طبيعي و بر اساس تنظيمات جديد انجام خواهد داد .

نحوه بكارگيري پيكربندي

زماني كه ASP.NET runtime ، تنظميات پيكربندي را براي يك درخواست وب بكار مي گيرد ، فايل machine.config در يك مجموعه تركيب و اطلاعات فوق در ارتباط با برنامه مورد نظر بكار گرفته مي شوند . تنظيمات پيكربندي از برنامه وب parent به ارث برده مي شود . فايل machine.config به عنوان parent تمامي برنامه هاي وب در نظر گرفته مي شود .
پيكربندي هر برنامه وب منحصربفرد است گرچه اين تنظيمات از parent به ارث رسيده باشند . مثلا" در صورتي كه فايل web.config موجود در فهرست ريشه يك وب سايت مقدار session timeout را معادل ده دقيقه تعريف نمايد ، تنظميات پيش فرض در فايل machine.config كه مقدار session timeout را بيست دقيقه تعريف كرده است ، ناديده مي گيرد .

تشخيص تغيير در فايل پيكربندي

ASP.NET به صورت اتوماتيك تغييرات ايجاد شده در فايل هاي machine.config و web.config را تشخيص مي دهد . تشخيص فوق توسط رويداد file-change كه توسط سيستم عامل محقق مي گردد ، انجام مي شود .
زماني كه يك برنامه ASP.NET فعاليت خود را آغاز مي نمايد ، تنظيمات پيكربندي خوانده شده و در ASP.NET Cache ذخيره مي شوند .در ادامه يك file dependency در entry مربوط به cache در فايل machine.config و يا web.config قرار مي گيرد . پس از تشخيص تغيير در فايل هاي machine.config و يا web.config ، يك application domain جديد توسط ASP.NET ايجاد تا به درخواست هاي جديد سرويس دهد . application domain قديم پس از پاسخگوئي به درخواست هاي جاري از بين خواهد رفت .

فرمت فايل پيكربندي

شايد تنها تفاوت اصلي فايل هاي web.config و machine.config ، نام آنان باشد و شكل و ساختار دو فايل فوق مشابه است . فايل هاي پيكربندي به چندين بخش تقسيم و هر بخش توسط يك xml element سطح بالا مشخص مي گردد . عنصر ريشه xml يك فايل پيكربندي ، <configuration> ناميده مي شود .
در مثال زير ، يك فايل نمونه web.config نشان داده شده است ( مقادير بين علائم [] ، در يك فايل پيكربندي واقعي ، با مقادير واقعي جايگزين مي گردند ) .

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
       <configSections>
            <section name="[sectionSettings]" type="[Class]"/>
            <sectionGroup name="[sectionGroup]">
                  <section name="[sectionSettings]" type="[Class]"/>
             </sectionGroup>
       </configSections>
   </configuration>

عنصر ريشه Xml يك فايل پيكربندي همواره <configuration> ناميده مي شود . هر section handler به همراه تنظميات مربوطه در يك <SectionGroup> قرار مي گيرند . <SectionGroup> يك ساختار سازماني درون فايل پيكربندي را ارائه مي نمايد تا به كمك آن بتوان پيكربندي مورد نياز را در گروه هاي منحصربفرد انجام داد . به عنوان نمونه بخش <system.web> درون فايل پيكربندي ، مكاني را كه اطلاعات آن در ارتباط با ASP.NET مي باشد ، مشخص مي نمايد.

Connection String

در ASP.NET 1.x ، اطلاعات مربوط به connection string در بخش <appSetting> ذخيره مي گرديد . در ASP.NET 2.0 ، تمامي اطلاعات در ارتباط با connection-string در يك بخش جديد با نام <connectionStrings> ذخيره مي گردد .
ذخيره اطلاعات connection - string در بخش <appSetting> داراي چالش هاي مختص به خود است :
• زماني كه اطلاعات connection string در بخش appSetting ذخيره مي گردد ، براي يك كنترل مرتبط با داده نظير SqlCacheDependency و يا MembershipProvider امكان دستيابي به اطلاعات وجود ندارد .
• ايمن سازي Connection string با استفاده از الگوريتم هاي رمزنگاري چالش هاي خاص خود را دارد .
• ويژگي فوق صرفا" در ارتباط با برنامه هاي ASP.NET نبوده و تمامي برنامه هاي دات نت نظير Windows Forms , Web Service و ساير موارد ديگر را نيز شامل مي شود .
با توجه به اين كه اطلاعات connection string مستقل از بخش appSetting ذخيره مي گردد ، مي توان آنان را با استفاده از مجموعه متد ConnectionString بازيابي نمود .
كد زير نحوه ذخيره connection string در فايل Web.config را نشان مي دهد .

نحوه بازيابي اطلاعات يك connection string در برنامه :

Public Sub Page_Load (sender As Object, e As EventArgs)
...
Dim dbConnection as New _
SqlConnection(ConfigurationSettings.ConnectionStrings("MyConnectionString1"))
...
End Sub

پيكربندي Session State

state management يكي از مسائل مهم در زمان پياده سازي برنامه هاي وب است كه مي بايست با توجه به اهميت آن به درستي با ابعاد آن آشنا گرديد . در گذشته اي نه چندان دور ( ده سال پيش ) ، با اين كه براي پياده سازي برنامه هاي كامپيوتري از معماري client-server استفاده مي گرديد ولي عملا" در معماري فوق ما داراي يك fat client و يك fat server مي باشيم كه براي ذخيره state از امكانات موجود در سمت سرويس دهنده و يا سرويس گيرنده استفاده مي شود . با توجه به اين كه در معماري فوق ، يك ارتباط دائم بين سرويس گيرندگان و سرويس دهنده وجود دارد براي ذخيره و نگهداري state با مشكل خاصي مواجه نمي شويم .
در برنامه هاي وب گفتگوي بين يك سرويس گيرنده و يك سرويس دهنده از طريق پروتكل HTTP انجام مي شود و جملگي به خوبي مي دانيم كه اين پروتكل يك پروتكل stateless است و ارتباط با يك سرويس دهنده از راه دور در زمان مورد نياز ايجاد و در ادامه و پس از سرويس دهي ، غيرفعال مي شود . با اين كه HTTP 1.1 از يك روش Keep-alive استفاده مي نمايد ولي سرويس دهنده نمي تواند درخواست هاي ايجاد شده توسط يك سرويس گيرنده را تشخيص دهد .
براي ذخيره و نگهداري state از گزينه هاي متعددي استفاده مي گردد كه session يك نمونه در اين زمينه است .شي Session متداولترين محلي است كه مي توان اطلاعات مربوط به وضعيت برنامه و كاربران را در آن ذخيره و نگهداري نمود . براي پياده سازي session از يك Hashtable استفاده مي گردد و داده بر اساس تركيب زوج كليد و مقدار ذخيره مي شود .
Session در ASP.NET 2.0 يك مفهوم جديد نيست و متاثر از ماهيت پروتكل HTTP است ( Stateless ) و قبل از ASP.NET و حتي ASP كلاسيك وجود داشته است .

داده Session در چه مكاني ذخيره مي گردد ؟

شي Session يك روش موثر براي ذخيره و نگهداري وضعيت يك برنامه و يا كاربران آن را ارائه مي نمايد. ASP.NET به همراه سه Storage Provider ارائه شده است :
• In-Process Session State Store : اطلاعات session در Cache ( حافظه ) ذخيره مي گردد .
• Out-of-Process Session State Store : اطلاعات Session در State Server Service ذخيره مي گردد ( asp_net_state.exe )
• Sql Session State Store : اطلاعات session در بانك اطلاعاتي SQL ذخيره مي گردد . براي پيكربندي از aspnet_regsql.exe استفاده مي گردد .
در ASP.NET 2.0 ، يك قابليت جديد با نام custome به مجموعه فوق اضافه شده است . با استفاده از گزينه فوق ، پياده كنندگان مي توانند داده session را در يك مكان دائم ذخيره نمايند . مثلا" ASP.NET 2.0 امكان ذخيره داده session را در برخي بانك هاي اطلاعاتي نظير Oracle,DB2 و يا Sybase ندارد . در صورتي كه بخواهيم داده session را در يكي از بانك هاي اطلاعاتي فوق و يا يك فايل XML ذخيره نمائيم ، مي توان از يك Provider class سفارشي استفاده نمود .
براي پيكربندي اطلاعات session از عنصر <sessiononState > در فايل web.config استفاده مي گردد :

در ادامه به بررسي مختصر هر يك از گزينه هاي فوق خواهيم پرداخت .
In-Process Session State Store : متداولترين و در عين حال سريعترين روش پيكربندي session state در ASP.NET 2.0 مي باشد ( مقدار mode برابر inproc در نظر گرفته مي شود ) .در اين روش داده Session در cache داخلي HttpRuntime ذخيره شده و به صورت live قابل دستيابي است . با توجه به اين كه داده session در حافطه ذخيره مي گردد ، به سرعت مي توان به آن دستيابي داشت ( ضرورتي ندارد داده از يك مكان ديگر به درون حافظه انتقال يابد ). داده seesion تا زمان اعتبار session در حافظه موجود مي باشد و پس از time out فضاي اشغال شده آزاد مي گردد .
Out-of-Process Session State Store : داده session در يك process كه به عنوان يك سرويس ويندوز اجراء مي گردد ، نگهداري مي شود ( aspnet_state.exe ) .
State Service به صورت پيش فرض اجراء نمي گردد و براي فعال كردن آن مي توان از دستور net start aspnet_sate استفاده نمود . به صورت پيش فرض ، سرويس فوق از پورت 42424 استفاده مي نمايد . در صورت ضرورت مي توان با استفاده از كليد ريجستري زير آن را تغيير داد .

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\Port

براي استفاده از روش فوق كافي است كه مقدار Inproc به StateServer در فايل web.config تغيير داد . همچنين مي بايست از خصلت StateConnectionString به منظور مشخص نمودن IP و شماره پورتي كه Session State Service بر روي آن اجراء شده است ، استفاده نمود .

Sql Session State Store : داده session در يك بانك اطلاعاتي SQL ذخيره مي گردد .

<configuration>
<system.web>
    <sessionState
      mode="SQLServer"
     sqlConnectionString="data source= TestSessionServer;
      user id=TestWebUser;password=Test"
      cookieless="false"
      timeout="20"
     />
</system.web>
</configuration>.

Custom State Store :معماري Sessin state در ASP.NET 2.0 بگونه اي طراحي شده است كه امكان افزودن Provider به آن وجود دارد ( مشتق شده از كلاس SessionStateStoreProviderBase ) . در صورتي كه بخواهيم Provider اختصاصي خود را ايجاد و يا از يك third-party provider استفاده نمائيم ، مي بايست مقدار خصلت mode را Custome در نظر گرفت . در چنين مواردي ، لازم است كه custom provider assembly مشتق شده از كلاس SessionStateStoreProviderBase را مشخص نمود .

مثال : كد زير يك نمونه از پيكربندي sessionState در فايل web.config را نشان مي دهد :

توضيحات :

• mode : نوع ذخيره سازي اطلاعات session را مشخص مي نمايد . در اين رابطه از پنج گزينه Off, InProc, StateServer, SQLServer و Custom استفاده مي گردد . كه مقدار پيش فرض InProc است .
• cookieless : مشخص مي نمايد كه آيا از HTTP cookieless Session Key management حمايت مي گردد .
• timeout : مدت زمان حيات Session را مشخص مي نمايد . مقدار timeoute بر اساس زمان درخواست ارزيابي مي گردد . مثلا" در صورتي كه مقدار timeout بيست دقيقه باشد و در خواستي در ساعت ده و ده دقيقه دريافت گردد ، timeout در ساعت ده و سي دقيقه به اتمام مي رسد .
• stateConnnectionString :از خصلت فوق به منظور مشخص نمودن آدرس TCP/IP و پورت جهت ارتباط يا Windows Service providing state management استفاده مي گردد ( در مواردي كه mode=StateServer در نظر گرفته شود ) .
• stateNetworkTimeout : مقدار timeout ( بر حسب ثانيه ) را در زمان ذخيره state در يك out-of-process session ( نظير StateServer ) ، مشخص مي نمايد .
• sqlConnectionString : از خصلت فوق جهت ارتباط با بانك اطلاعاتي SQL Server براي ذخيره و بازيابي داده session استفاده مي گردد ( در مواردي كه mode=SQLServer در نظر گرفته شود) .
پيكربندي Session State با استفاده از Connection string : كد زير يك نمونه از پيكربندي Session State با استفاده از connection string را نشان مي دهد :

پيكربندي ترجمه

ASP.NET ، صفحات وب ، سرويس هاي وب ، http handlers ، فايل هاي برنامه ( نظير Global.asax ) و فايل هاي منبع را به صورت پويا ترجمه مي نمايد . فايل هاي فوق به صورت پويا و همزمان با اولين درخواست ، ترجمه مي گردند .
هر نوع تغيير در فايل ترجمه شده پويا باعث مي گردد كه تمامي منابع متاثر از تغييرات شوند و به صورت پويا invalidated و مجددا" ترجمه گردند . مكانيزم فوق پياده كنندگان را قادر مي سازد كه به سرعت برنامه هاي وب را با حداقل overhead اجراء نمايند. چراكه پس از تشخيص تغييرات و ترجمه پويا ، مي توان بلافاصله از امكانات برنامه ها استفاده نمود .
پتانسيل ترجمه پويا در ASP.NET 2.0 نسبت به ASP.NET 1.x افزايش و فايل هاي ديگري نظير كلاس فايل ها را نيز تحت پوشش قرار مي دهد .
براي پيكربندي تنظيمات ترجمه از بخش <compilation> در فايل هاي web.config و يا machine.config استفاده مي گردد . ASP.NET engine ، در زمان مورد نياز صفحه را ترجمه و كد توليد شده را در code cache ذخيره مي نمايد .از cache فوق در زمان اجراي صفحات ASP.NET استفاده مي گردد .
كد زير گرامر بخش <compilatioin> را نشان مي دهد .

<compilation
     tempDirectory="directory"
     debug="[true|false]"
     strict="[true|false]"
     explicit="[true|false]"
     batch="[true|false]"
     batchTimeout="timeout in seconds"
     maxBatchSize="max number of pages per batched compilation"
     maxBatchGeneratedFileSize="max combined size in KB"
     numRecompilesBeforeAppRestart="max number of recompilations ?
      defaultLanguage="name of a language as specified in a <compiler/> element below"
      <compilers>
          <compiler language="language"
              extension="ext"
              type=".NET Type"
              warningLevel="number"
              compilerOptions="options"/>
     </compilers>
     <assemblies>
            <add assembly="assembly"/>
     </assemblies>
     <codeSubDirectories>
            <codeSubDirectory directoryName="sub-directory name"/>
     </codeSubDirectories>
     <buildproviders>
            <buildprovider
                extension="file extension"
                type="type reference"/>
     </buildproviders>
</compilation>

توضيحات :

• batch : نوع ترجمه را مشخص مي نمايد (مقدار پيش فرض True است ) .
• maxBatchSize : حداكثر تعداد صفحات و يا كلاس را كه مي توان در يك batch ترجمه نمود، مشخص مي نمايد. ( مقدار پيش فرض 1000 )
• maxBatchGeneratedFileSize : حداكثر اندازه خروجي يك batch assembley ترجمه شده را نشان مي دهد ( مقدار پيش فرض 3000 )
• batchTimeout : زمان ( بر حسب ثانيه ) ترجمه batch را مشخص مي نمايد . در صورتي كه زمان فوق قبل از اتمام ترجمه به پايان رسيده باشد ، يك exception محقق مي گردد ( مقدار پيش فرض پانزده ثانيه است) .
• debug : آيا مي بايست اسمبلي هاي توليد شده را ترجمه ويا ديباگ نمود ؟ (مقدار پيش فرض False ).
• defaultLanguage : زبان برنامه نويسي پيش فرض نظير VB و يا #C براي استفاده در فايل هاي ترجمه پويا را مشخص مي نمايد.
• tempDirectory : دايركتوري مورد نظر براي استفاده موقت در حين ترجمه را مشخص مي نمايد . به صورت پيش فرض ، ASP.NET فايل موقت را در مسير
[WinNT\Windows]\Microsoft.NET\Framework\[version]\Temporary ASP.NET ايجاد مي نمايد .
• compilers : بخش <compilers> ، مي تواند شامل چندين زير عنصر <compile> باشد كه از آنان به منظور ايجاد يك تعريف جديد كمپايل استفاده مي گردد .
• numRecompilesBeforeAppRestart : تعداد دفعات ترجمه ، قبل از راه اندازي برنامه مشخص مي نمايد .

قابليت هاي مرورگر

شناسائي و استفاده از پتانسيل مرورگرها براي برنامه هاي وب ضروري است . browser capabilities component بگونه اي طراحي شده است تا بتواند از مرورگرهاي مختلفي نظير opera , netscape و IE حمايت نمايد . با استفاده از <browserCaps> مي توان تنظيمات پيكربندي را براي browser capabilities component مشخص نمود . از عنصر فوق مي توان در سطوح متفاوتي ‌نظير ماشين ، سايت ، برنامه و زير دايركتوري ها استفاده نمود .
پس از دريافت يك درخواست از يك مرورگر ، browser capabilities component قابليت هاي مرورگر را از طريق هدر درخواست شناسائي و براي هر نوع مرورگر يك مجموعه از تنطيمات مرتبط با برنامه را ترجمه مي نمايد . تنظيمات فوق را مي توان به صورت ايستا انجام و يا از هدر درخواست ارسالي استفاده نمود . يك برنامه مي تواند در صورت ضرورت تنظيمات فوق را را توسعه و يا تغيير دهد .
در ASP.NET 2.0 تمامي اطلاعات مربوط به قابليت هاي مرورگر در "فايل هاي تعريف مرورگر" ارائه مي گردند . اين نوع فايل ها ، فايل هائي با انشعاب browser.* و فرمت xml مي باشند . يك فايل ممكن است شامل تعريف بيش از يك نوع مرورگر باشد . فايل هاي فوق در زمان نصب فريمورك در آدرس
[WinNT\Windows]\Microsoft.NET\Framework\xxxxx\CONFIG\Browsers نصب مي گردند . ( در ASP.NET 1.x ، اطلاعات مربوط به پتانسيل هر مرورگر در فايل هاي machine.config و web.config ذخيره مي گردد ).
هر مرورگر به عنوان يك موجوديت و با استفاده از عنصر <browser> تعريف و داراي يك id مختص به خود است كه يك كلاس از مرورگر را به همراه كلاس parent مشخص مي نمايد . <browsers> ، عنصر ريشه در فايل هاي تعريف مرورگر است و از خصلت id به منظور تمايز بين تعاريف هر يك از مرورگر ها ( در صورتي كه بيش از يك مورد در يك فايل تعريف شده باشد ) ، استفاده مي گردد .
قبل از اجراي يك برنامه ASP.NET ، فريمورك تمامي تعاريف مرورگر را در يك اسمبلي ترجمه و آنان را در GAC ذخيره مي نمايد .
در صورت تغيير فايل هاي تعريف مرورگر در سطح سيستم ، تغييرات به صورت اتوماتيك بر روي هر يك از برنامه هاي ASP.NET اعمال نخواهد شد . بنابراين ، اين مسئوليت پياده كنندگان و يا ابزارهاي نصب است كه اطلاعات فوق را بهنگام نمايند . اطلاعات بهنگام شده مرورگر را مي توان با استفاده از برنامه aspnet_regbrowsers.exe براي تمامي برنامه هاي ASP.NET ارسال نمود . پس از اجراي برنامه فوق ، اطلاعات مرورگر مجددا" ترجمه و اسمبلي جديد در GAC ذخيره مي گردد . از اسمبلي فوق تمامي برنامه هاي ASP.NET استفاده مي نمايند .

خطاهاي سفارشي

در صورت بروز اشكال در هر يك از صفحات ASP.NET ، يك صفحه خطاء نمايش داده مي شود كه در آن كد نوشته شده به همراه مكان ( شماره خط ) بروز خطاء نشان داده مي شود . نمايش كد منبع و مكان بروز خطاء در يك صفحه چالش هاي مختص به خود را دارد :
• نمايش كد منبع و پيام خطاء براي كاربران عادي هيچگونه ارزش اطلاعاتي ندارد، پس چرا مي بايست آنان را نمايش داد ؟
• نمايش كد منبع و پيام خطاء بيش از همه مهاجمان فرصت طلب را خوشحال خواهد كرد چراكه شرايط مناسبي براي ارتقاء دانش آنان به منظور برنامه ريزي حملات فراهم مي گردد .
ASP.NET با ارائه يك زيرساخت مناسب امكان پيشگيري از نمايش اينگونه خطاها را در اختيار پياده كنندگان برنامه هاي وب قرار مي دهد . بدين منظور از بخش <customeErrors> در فايل web.config براي تعريف پيام هاي خطاء سفارشي و سياست نمايش جزئيات خطاء استفاده مي گردد . نحوه استفاده از عنصر فوق به صورت زير است :

توضيحات :

• defaultRedirect : آدرس صفحه اي را كه پس از بروز خطاء مرورگر كاربران به آن هدايت مي گردند را مشخص مي نمايد .
• mode : مقدار نسبت داده شده به اين خصلت وضعيت نمايش خطاء سفارشي را مشخص مي نمايد . در صورتي كه مقدار اين خصلت on باشد ، خطاهاي سفارشي نمايش داده مي شوند . در صورتي كه مقدار mode معادل off باشد ، خطاهاي سفارشي نمايش داده نخواهند شد و در صورتي كه مقدار اين خصلت remote در نظر گرفته شود ، خطاهاي سفارشي صرفا" براي كاربران از راه دور نمايش داده مي شود .
• customeErrors : اين بخش شامل چندين زيرعنصر <error> است كه از آنان به منظور تعريف خطاهاي سفارشي استفاده مي گردد . هر زير عنصر <error> مي تواند شامل يك خصلت statusCode و يك URL باشد .