تبلیغات
تبلیغات متنی
رسانه حرف تو - مقایسه و اشتراک تجربه خرید
آموزشگاه آرایشگری مردانه شفیع رسالت
تاثیر رنگ لباس بر تعاملات انسانی
محبوبترینها
خرید سوسیس پرکن اصل با گارانتی
تشخیص دیسک و صفحه اصلی از تقلبی (6 راه ساده)
بهترین روش های چاپ جعبه محصولات + ویژگی ها و کاربردها
بهترین روش های چاپ جعبه محصولات + ویژگی ها و کاربردها
ده راهنمایی برای نوازندگان مبتدی یوکللی
بررسی دلایل قانع کننده برای خرید صنایع دستی اصفهان
راه های جلوگیری از جریمه های قبض برق
آشنایی با سایت قو ایران بهترین سایت آگهی و تبلیغات در کشور
بهترین شرکت‌های مهندسی در آلمان
صفحه اول
آرشیو مطالب
ورود/عضویت
هواشناسی
قیمت طلا سکه و ارز
قیمت خودرو
مطالب در سایت شما
تبادل لینک
ارتباط با ما
مطالب سایت سرگرمی سبک زندگی سینما و تلویزیون فرهنگ و هنر پزشکی و سلامت اجتماع و خانواده تصویری دین و اندیشه ورزش اقتصادی سیاسی حوادث علم و فناوری سایتهای دانلود گوناگون
مطالب سایت سرگرمی سبک زندگی سینما و تلویزیون فرهنگ و هنر پزشکی و سلامت اجتماع و خانواده تصویری دین و اندیشه ورزش اقتصادی سیاسی حوادث علم و فناوری سایتهای دانلود گوناگون
آمار وبسایت
تعداد کل بازدیدها :
1806710524
سيستم پيكربندی ASP.NET 2.0
واضح آرشیو وب فارسی:راسخون:
سيستم پيكربندی 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:WindowsMicrosoft.NETFrameworkv2.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 را نشان می دهد .<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"> <connectionStrings> <add name="MyConnectionString1" connectionString="Data Source providerName="System.Data.SqlClient" /> </connectionStrings></configuration> نحوه بازيابی اطلاعات يك 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 استفاده می گردد :<configuration> <system.web> <sessionState mode="Off|InProc|StateServer|SQLServer|Custom" ../> </system.web>...</configuration> در ادامه به بررسی مختصر هر يك از گزينه های فوق خواهيم پرداخت . 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_MACHINESYSTEMCurrentControlSetServicesaspnet_stateParametersPort برای استفاده از روش فوق كافی است كه مقدار Inproc به StateServer در فايل web.config تغيير داد . همچنين می بايست از خصلت StateConnectionString به منظور مشخص نمودن IP و شماره پورتی كه Session State Service بر روی آن اجراء شده است ، استفاده نمود .<configuration> <system.web> <sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424"/> </system.web></configuration> 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 را مشخص نمود . <configuration> <system.web> <sessionState mode="Custom" CustomProvider="CustomStateProvider"> <providers> <add name="CustomStateProvider" type="CustomStateProviderAssembly, CustomStateProviderNamespace.CustomStateProviderSateProvider"/> </providers> </sesisonState> </system.web></configuration> مثال : كد زير يك نمونه از پيكربندی sessionState در فايل web.config را نشان می دهد : <sessionState mode="StateServer" cookieless="false" timeout="20" stateConnectionString="tcpip=TestSessionStore:42424" stateNetworkTimeout="60" sqlConnectionString=""/> توضيحات : • 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 را نشان می دهد : <configuration> <connectionStrings> <add name = "TestSessionState" connectionString = "data source=TestSessionServer; user id=TestWebUser;password=test" /> </connectionStrings> <system.web> <sessionState mode="SQLServer" sqlConnectionString="TestSessionState" cookieless="false" timeout="20" /> </system.web></configuration> پيكربندی ترجمه 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 Attributes --><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 فايل موقت را در مسير[WinNTWindows]Microsoft.NETFramework[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 می باشند . يك فايل ممكن است شامل تعريف بيش از يك نوع مرورگر باشد . فايل های فوق در زمان نصب فريمورك در آدرس [WinNTWindows]Microsoft.NETFrameworkxxxxxCONFIGBrowsers نصب می گردند . ( در 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 برای تعريف پيام های خطاء سفارشی و سياست نمايش جزئيات خطاء استفاده می گردد . نحوه استفاده از عنصر فوق به صورت زير است : <customErrors defaultRedirect="[url]" mode="[on/off/remote]"> <error statusCode="[statuscode]" redirect="[url]" /></customErrors>rs> توضيحات : • defaultRedirect : آدرس صفحه ای را كه پس از بروز خطاء مرورگر كاربران به آن هدايت می گردند را مشخص می نمايد . • mode : مقدار نسبت داده شده به اين خصلت وضعيت نمايش خطاء سفارشی را مشخص می نمايد . در صورتی كه مقدار اين خصلت on باشد ، خطاهای سفارشی نمايش داده می شوند . در صورتی كه مقدار mode معادل off باشد ، خطاهای سفارشی نمايش داده نخواهند شد و در صورتی كه مقدار اين خصلت remote در نظر گرفته شود ، خطاهای سفارشی صرفا" برای كاربران از راه دور نمايش داده می شود . • customeErrors : اين بخش شامل چندين زيرعنصر <error> است كه از آنان به منظور تعريف خطاهای سفارشی استفاده می گردد . هر زير عنصر <error> می تواند شامل يك خصلت statusCode و يك URL باشد . <configuration> <system.web> <customErrors mode="RemoteOnly" defaultRedirect="/DefaultErrorPage.htm"> <error statusCode="500" redirect="/error/ServerError.htm"/> <error statusCode="404" redirect="/error/Filenotfound.aspx"/> <error statusCode="403" redirect="/error/Forbidden.aspx"/> </customErrors> </system.web></configuration>
این صفحه را در گوگل محبوب کنید
[ارسال شده از: راسخون]
[مشاهده در: www.rasekhoon.net]
[تعداد بازديد از اين مطلب: 509]
-
گوناگون
پربازدیدترینها