- آیا اطلاعات، یک بار نوشته خواهند شد و به کرّات واکشی میشوند؟ (مانند پرفایل کاربران یا اطلاعات یک کالا در یک فروشگاه اینترنتی)
Cache-Aside
میتوان این روش را یکی از متداولترین و یا آشناترین روشهای caching دانست و شاید حداقل یک بار، کارکردن با آن را تجربه کردهایم.
نحوهی کار به این صورت میباشد که:
1- برنامه ابتدا cache را بررسی میکند میکند و اگر اطلاعات مورد نظر در cache یافت شود، اطلاعات به کاربر برگشت داده میشوند.
2- اگر اطلاعات مورد نظر در cache یافت نشود، برنامه همان درخواست را به دیتابیس میفرستد و اطلاعات را به کاربر برمیگرداند؛ همچنین موظف است اطلاعات دریافتی از دیتابیس را در cache ذخیره کند تا در دفعات بعدی آنرا از cache، واکشی کند.
public object GetMyEntity(int key) { // Try to get the entity from the cache. var value = cache.StringGet(key); if (value == null) // Cache miss { // If there's a cache miss, get the entity from the original store and cache it. value = db.StringGet(key); // Avoid caching a null value. if (value != null) { // Put the item in the cache with a custom expiration time that cache.StringSetAsync(key, JsonConvert.SerializeObject(value)); } } return value; }
Read-Through Cache
در این حالت دیتابیس و cache به صورت پشت سر هم (in-line) قرار دارند و نحوه کار به این صورت است که همیشه درخواستها در ابتدا به cache ارسال میشوند. تنها تفاوت این روش با روش قبل این است که برنامهی ما همیشه با cache صحبت میکند.
مزایا و معایب
Write-Through Cache
در این حالت اطلاعات ابتدا در cache ذخیره خواهند شد و بعد از آن در دیتابیس قرار خواهند گرفت. همچنین همانند روش Read-Through، برنامه همیشه با cache صحبت میکند.
این روش همهی مزایای روش Read-Through را دارد به علاوه رفع معایب آن از جمله:
- ناسازگاری دادهها نمیتوانند اتفاق بیفتند؛ زیرا اطلاعات همیشه ابتدا در cache نوشته خواهند شد و بعد در دیتابیس؛ به همین خاطر اطلاعات در هر دو نسخه یکسان هستند.
- بعد از درج اطلاعات جدید، نیازی به warming نیست. به این دلیل که در ابتدا در cache ذخیره خواهند شد.
Vue Lifecycle hooks
new Vue({ el: '#app', data() { return { a: 1 }; }, created: function () { // `this` points to the vm instance console.log('a is: ' + this.a) } });
new Vue({ el: '#app', data() { return { name: 'Sirwan' }; }, beforeCreate: function () { console.log('name is: ' + this.name); console.log(`We don't have access to target element at this point: ${this.$el}`); }, created: function () { // `this` points to the vm instance console.log('name is: ' + this.name); console.log(`We don't have access to target element at this point: ${this.$el}`); } });
beforeMount: function () { console.log(`this.$el doesn't exist yet, but it will soon!`); }, mounted: function () { console.log(this.$el); }
new Vue({ el: '#app', data() { return { name: 'Sirwan', counter: 0 }; }, created: function () { setInterval(() => { this.counter++ }, 1000) }, beforeUpdate: function () { console.log(this.counter); // Logs the counter value every second, before the DOM updates. }, updated: function () { console.log(`new value: ${this.counter}`); } });
new Vue({ el: '#app', data() { return { name: 'Sirwan', counter: 0 }; }, beforeDestroy: function () { }, destroyed() { console.log(this) // There's practically nothing here! } });
const express = require('express') const app = express() const PORT = 3000; app.get('/', (req, res) => { res.send('Hello World') }) app.listen(PORT, () => { console.log(`listening on port ${PORT}!`) })
"scripts": { "start": "node index" },
FROM node ENV NODE_ENV=production COPY . /var/www WORKDIR /var/www RUN npm i EXPOSE 3000 ENTRYPOINT npm start
docker build -f Dockerfile -t alikhll/testnode1 .
docker run -d -p 8080:3000 alikhll/testnode1
dotnet new web dotnet restore dotnet run
FROM microsoft/dotnet ENV ASPNETCORE_URLS http://*:3000 COPY . /var/www WORKDIR /var/www RUN dotnet restore EXPOSE 3000 ENTRYPOINT dotnet run
docker build -f Dockerfile -t alikhll/testasp1 .
docker run -d -p 8080:3000 alikhll/testasp1
docker login
docker push alikhll/testnode1
docker pull alikhll/testnode1
چرا چنین بویی به راه میافتد؟
- استفاده نادرست از الگوهای طراحی شیء گرا
- عدم درک درست مسئولیتهای کلاسهای ایجاد شده
- عدم تشخیص مکانیزمهای مشترک در کد و جداسازی مناسب آنها
public class UserService { public void SaveUser(dynamic userEntity) { var regEx = "blablabla"; var phoneIsValid = Regex.IsMatch(userEntity.PhoneNumber, regEx); if (!phoneIsValid) return; // ... } } public class AddressService { public void SaveAddress(dynamic addressEntity) { var regEx = "blablabla"; var phoneIsValid = Regex.IsMatch(addressEntity.PhoneNumber, regEx); if (!phoneIsValid) return; } }
public class PhoneValidator { public bool IsValid(string phoneNumber) { var regEx = "blablabla"; var phoneIsValid = Regex.IsMatch(phoneNumber, regEx); if (!phoneIsValid) return false; return true; } } public class UserService { public void SaveUser(dynamic userEntity) { var validator = new PhoneValidator(); var phoneIsValid = validator.IsValid(userEntity.PhoneNumber); if (!phoneIsValid) return; // ... } } public class AddressService { public void SaveAddress(dynamic addressEntity) { var validator = new PhoneValidator(); var phoneIsValid = validator.IsValid(addressEntity.PhoneNumber); if (!phoneIsValid) return; // ... } }
شکل دیگر
جمع بندی
Nullable<T>.GetValueOrDefault Method
float? yourSingle = -1.0f; Console.WriteLine( yourSingle.GetValueOrDefault() ); yourSingle = null; Console.WriteLine( yourSingle.GetValueOrDefault() ); // assign different default value Console.WriteLine( yourSingle.GetValueOrDefault( -2.4f ) ); // returns the same result as the above statement Console.WriteLine( yourSingle ?? -2.4f );
در صورتیکه مقداری را به عنوان پیش فرض، به پارامتر این متد ارسال نکنید، مقدار پیش فرض آن از نوع استفاده شده بدست میآید.
شما میتوانید برای دیکشنری نیز یک متد Get امن ایجاد کنید (در صورت عدم وجود کلید، بجای پرتاب استثناء، مقدار پیش فرض بازگشت داده شود).
public static class DictionaryExtensions { public static TValue GetValueOrDefault< TKey, TValue >( this Dictionary< TKey, TValue > dic, TKey key ) { TValue result; return dic.TryGetValue( key, out result ) ? result : default(TValue); } }
و روش استفاده
var names = new Dictionary< int, string > { { 0, "Vahid" } }; Console.WriteLine( names.GetValueOrDefault( 1 ) );
ZipFile in .NET
var startPath = Path.Combine( Environment.GetFolderPath( Environment.SpecialFolder.Desktop ), "Start" ); var resultPath = Path.Combine( Environment.GetFolderPath( Environment.SpecialFolder.Desktop ), "Result" ); var extractPath = Path.Combine( Environment.GetFolderPath( Environment.SpecialFolder.Desktop ), "Extract" ); Directory.CreateDirectory( startPath ); Directory.CreateDirectory( resultPath ); Directory.CreateDirectory( extractPath ); var zipPath = Path.Combine( resultPath, Guid.NewGuid() + ".zip" ); ZipFile.CreateFromDirectory( startPath, zipPath ); ZipFile.ExtractToDirectory( zipPath, extractPath );
C# Preprocessor Directives
#if DEBUG #warning DEBUG is defined #endif
#if DEBUG #error DEBUG is defined #endif
در مثال زیر، در صورتیکه در خط اول break point قرار دهید و با کلید F10 برنامه را اجرا کنید، مشاهده میکنید که دیباگر، خطی را که بعد از دستور line hidden# نوشته شده است، در نظر نمیگیرد (برای دیباگ) اما اجرا میشود و دیباگر بر روی دستور بعد از line default# قرار میگیرد.
Console.WriteLine("Normal line #1."); // Set break point here. #line hidden Console.WriteLine("Hidden line."); #line default Console.WriteLine("Normal line #2.");
Stackalloc
static unsafe void Fibonacci() { const int arraySize = 20; int* fib = stackalloc int[arraySize]; var p = fib; *p++ = *p++ = 1; for ( var i = 2; i < arraySize; ++i, ++p ) { *p = p[-1] + p[-2]; } for ( var i = 0; i < arraySize; ++i ) { System.Console.WriteLine( fib[i] ); } }
هر کامپوننتی در React یک چرخه زندگی دارد. زمانیکه یک کامپوننت را به روش React.createClass یا React.Component تعریف میکنیم و در ReactDOM.render نمونهای از کامپوننت را برای نمایش در مرورگر میسازیم، چرخه حیات آن شروع میشود.
ReactDOMServer
کتابخانه ReactDOMServer جهت ساخت یا render کردن کامپوننتها در سمت سرور استفاده میشود. توسط این کتابخانه میتوانیم کامپوننتها را در سمت سرور ایجاد کنیم و نتیجه آن را که تگهای HTML هستند به مرورگر ارسال کنیم. این روش جهت داشتن صفحههای وب سریعتر و اهداف SEO مفید است. جهت اطلاعات بیشتر و روشهای استفاده به مستندات آن رجوع کنید. در مثال زیر روش استفاده از این کتابخانه به اختصار آمده.
var persons = [ { id: 1, personName: "Parham", personContact: "parhamda@gmail.com" }, { id: 2, personName: "Roham", personContact: "roham@yahoo.com" }, { id: 3, personName: "Raha", personContact: "raha@live.com" } ]; class Person extends React.Component{ render(){ return ( <div> <p>{this.props.personName}</p> <p>{this.props.personContact}</p> </div> ) } } let person1 = persons[0]; let personElement = <Person personName={person1.personName} personContact={person1.personContact}/> console.log(ReactDOMServer.renderToStaticMarkup(personElement));
در کد بالا مواردی که جدید هستند، یکی ساخت یک نمونه از کامپوننت Person است و دیگری ساخت آن در سمت سرور، بدون آن که فعلا نمایشی در مرورگر داشته باشیم. در کنسول میتوانیم خروجی کتابخانه را که تگهای HTML هستند ببینیم. ReactDOMServer دو متد را فراهم کرده که کارکردی مشابه دارند؛ اما در جزئیات متفاوت هستند.
- renderStaticMarkup یک خروجی استاتیک و بدون attributeهای اضافه را تولید میکند که بیشتر برای بررسی یا استفاده در صفحههای وب ایستا مفید هستند.
- renderToString یک خروجی به صورت HTML String ایجاد میکند که برای HTML DOM در سمت کاربر سازگارتر است و مناسب برای صفحات پویا.
در نهایت خروجی از هر نوع که بود، برای اینکه در سمت کاربر قابل مشاهده باشد باید از همان متد ReactDOM.render استفاده کنیم. از آنجایی که این مجموعه جهت معرفی و بررسی ابزارهای اصلی React به صورت مختصر است، از آوردن مثالهای زیاد و پیچیده پرهیز میکنم. در اینجا میتوانید یک نمونه ساده برای استفاده از ReactDOMServer به صورت استاندارد و با جزئیات را بررسی کنید.
متدهای چرخه حیات در React
React چند متد را برای زمانهای قبل و بعد از ساخت شدن یک کامپوننت در DOM دارد که میشود رفتارهایی را برای کامپوننت، در این متدها در نظر گرفت تا در زمان مناسب اجرا شوند. در ادامه این متدها معرفی و کاربرد هر یک بیان میشود.
componentWillMount: این متد قبل از اینکه کامپوننت، تگهای متد render را بسازد اجرا میشود. این متد هم در سمت کلاینت کاربرد دارد و هم در سمت سرور. به همین جهت برای گرفتن log از دادههای کامپوننت و کار با پایگاه داده مکان مناسبی است. به عنوان مثال در قطعه کد زیر دادههای کامپوننت، توسط Ajax ارسال شدهاند.
componentWillMount() { Ajax.post("/componentLog", { name: this.constructor.name, props: this.props }); }
componentDidMount: این متد بعد از اینکه بخش render اجرا شد فراخوانی میشود. همچنین فقط در سمت کلاینت و زمانیکه از ReactDOM.render استفاده میکنیم کاربرد دارد. این متد مناسب برای تعامل کامپوننت با افزونهها و APIها است؛ مانند دریافت اطلاعات مورد نیاز کامپوننت از سایتی دیگر توسط یک API. از این متد در قسمت چهارم مثالی آورده شده.
(componentWillReciveProps(nextProps: این متد زمانی اجرا میشود که دادههای ورودی کامپوننت با مقادیری جدید تغییر کنند.
componentWillReceiveProps(nextProps) { // Do something with new received data and change the state. } ReactDOM.render( <TestComponent someData={newDataEveryFiveSecond()}/>, document.getElementById("divTest") );
در مثال بالا یک کامپوننت داریم که دادههای ورودی خود را از یک تابع میگیرد. این تابع هر پنج ثانیه یک بار یک داده تازه ایجاد میکند و به کامپوننت ارسال میکند. میتوانیم داخل کامپوننت، از متد componentWillReceiveProps جهت دستکاری دادههای رسیده و تغییر وضعیت کامپوننت توسط setState استفاده کنیم.
(shouldComponentUpdate(nextProps, nextState: این متد شبیه به متد componentWillReceiveProps است، البته با تفاوتهایی. این متد هم مقدار ورودی جدید برای پارامترهای کامپوننت میگیرد و هم مقداری برای وضعیتی که کامپوننت دارد. این متد باید یک مقدار بازگشتی false یا true داشته باشد. با این مقدار بازگشتی میتوان کنترل کرد که آیا کامپوننت بر اساس دادههای جدید بروز بشود یا نه.
class ComponentExample extends React.Component { shouldComponentUpdate(nextProps, nextState) { return notEqual(this.props, nextProps) || notEqual(this.state, nextState); } }
در مثال بالا پارامترها و وضعیت جاری کامپوننت، با مقدارهای تازه تغییر یافته و وضعیت جدید مقایسه میشوند. اگر مقادیر مقایسه شده برابر نباشند (یعنی داده تکراری وارد نشده) مقدار بازگشتی true خواهد بود و React کامپوننت را بر اساس وضعیت جدید و دادههای تازه دوباره میسازد.
(componentWillUpdate(nextProps, nextState: این متد زمانیکه کامپوننت ساخته شده، دادههای جدیدی را دریافت کند و یا وضعیت آن تغییر کند و دقیقا قبل از اجرای render فراخوانی میشود. اگر از متد shouldComponentUpdate مقدار false بازگشت داده شود، این متد دیگر اجرا نخواهد شد. باید توجه داشته باشیم که setState را نمیشود در این متد پیادهسازی کرده. به این علت که، زمانیکه وضعیت کامپوننت تغییر میکند، React متد componentWillUpdate و بلافاصله بعد از آن render را اجرا میکند و برای تغییر وضعیت دیگر دیر شده! تفاوت componentWillUpdate با componentWillMount این است که Will Mount در اولین وهله سازی از کامپوننت اجرا میشود، ولی Will Update بعد از هر دوباره سازی (rerender).
(componentDidUpdate(prevProps, prevStat: احتمالا میشود به راحتی حدس زد که این متد دقیقا بعد از دوباره سازی کامپوننتی که ساخته شده فراخوانی میشود.
componentWillUnmount: این متد زمانی اجرا میشود که یک کامپوننت از DOM پاک شود. برای پاک کردن نمونهای از یک کامپوننت که در DOM در حال نمایش است میتوانیم از دستور زیر استفاده کنیم.
ReactDOM.unmountComponentAtNode(document.getElementById("react"));
public Service1(string[] args) { this.args = args; } internal void TestStartupAndStop(string[] args) { this.OnStart(args); Console.ReadLine(); this.OnStop(); } protected override void OnStart(string[] args) { Console.WriteLine("Service Started"); //Do Somthing }
static void Main(string[] args) { if (Environment.UserInteractive) { Service1 service1 = new Service1(args); service1.TestStartupAndStop(args); } else { // Put the body of your old Main method here. ServiceBase[] ServicesToRun; ServicesToRun = new ServiceBase[] { new Service1() }; ServiceBase.Run(ServicesToRun); } }
System.Diagnostics.Debugger.Launch(); // Start Debugger
#if DEBUG System.Diagnostics.Debugger.Launch(); // Start Debugger #endif
درصورتی که Yes را انتخاب نمایید، میتوانید در یک Solution جدید به دیباگ برنامه بپردازید و دیباگر به صورت خودکار کدهای مورد نیاز را برای شروع کار، برای شما بارگذاری خواهد کرد. اما در پروژههای بزرگتر به دلیل وابستگیهای سرویس به کتابخانههای متعدد، امکان دیباگ کامل را هنوز در اختیار نداریم و دیباگ ما در اینجا، محدود به خود سرویس است. برای اینکه بتوانیم دیباگ را کامل در Solution اصلی برنامه انجام دهید، قبل پاسخ دادن به پنجره بالا یک مرحله دیگر از کار باقی مانده است.
Local Storage
با استفاده از Local Storage قادر خواهیم بود تا دادههایی را در سمت کلاینت ذخیره کنیم؛ بدون اینکه بر عملکرد سایت تاثیر بگذارد. منظور از تاثیر بر روی عملکرد این است که در هر رفت به سمت سرور لازم نیست با درخواست ارسالی، دادههای اضافهای ارسال شوند.
با استفاده از Local Storage قادر خواهیم بود حداقل 5 مگابایت داده را ذخیره کنیم.
استفاده از Local Storage با استفاده از دو شیء زیر امکان پذیر میباشد:
- window.localStorage : اطلاعات ذخیره شده در آن فاقد تاریخ انقضاء
میباشند و تا زمانی که اقدام به حذف آن ننمایید، دادههای آن معتبر
میباشند.
- window.sessionStorage : اطلاعات ذخیره شده در آن تا زمان بسته شدن تب مرورگر، معتبر میباشند. با بسته شدن تب فعلی مرورگر، تمامی اطلاعات ذخیره شده از بین خواهند رفت.
نحوه استفاده:
- نحوه افزودن داده در Local Storage به صورت کلید/ مقدار میباشد.
ابتدا نگاهی داشته باشیم به اینترفیس Storage:
interface Storage { readonly attribute unsigned long length; DOMString? key(unsigned long index); getter DOMString? getItem(DOMString key); setter void setItem(DOMString key, DOMString value); deleter void removeItem(DOMString key); void clear(); }
if (typeof(Storage) !== "undefined") { // do ... }
شیء window.localStorage
همانطور که بیان کردیم، در این روش داده دارای تاریخ انقضاء نمیباشد.
() SetItem :
متد setItem برای ذخیره اطلاعات است و نحوه استفاده از آن به صورت زیر میباشد:
localStorage.setItem("lastpost", "localstorage");
localStorage.setItem("visitorCount",15 ); localStorage.setItem("visitorCount", 16);
() getItem :
برای دسترسی به مقدار ذخیره شده میتوانیم از متد getItem به همراه مقدار کلید استفاده کنیم. در صورت موجود نبودن مقدار، null برگردانده خواهد شد.
localStorage.getItem("lastpost");
localStorage.lastpost = "localstorage"; document.getElementById("result").innerHTML = localStorage.lastpost;
و برای حذف اطلاعات ذخیره شده:
localStorage.removeItem("lastpost");
خصوصیت length :
تعداد جفت کلید / مقدارهای جاری را بر میگرداند.
متد Key :
این متد مقداری را از ورودی دریافت کرده و اسم کلید مورد نظر را بر میگرداند. ایندکس آن از صفر شروع خواهد شد. قطعه کد زیر باعث برگرداندن مقدار lastname میشود:
localStorage.setItem("name","uthman" ); localStorage.setItem("lastname","24" ); alert(localStorage.key(1));
این متد باعث پاک شدن تمامی دادههای ذخیره شده خواهد شد.
شی sessionStorage :
از نظر syntax دستوری همانند localStorage میباشد و تفاوت آن فقط در زمان ذخیره سازی است؛ با بسته شدن تب مرورگر، تمامی دادههای ذخیره شده پاک خواهند شد.
کتابخانههای مرتبط :
Locker :
با استفاده از این کتابخانه ، قادر خواهید بود تا اطلاعات را با فرمتهای مورد نظر، بدون convert آنها ذخیره نمایید. نمونهای از آن به صورت زیر خواهد بود:
Lockr.set('website', 'SitePoint'); // string Lockr.set('categories', 8); // number Lockr.set('users', [{ name: 'John Doe', age: 18 }, { name: 'Jane Doe', age: 19 }]);
secStore.js :
با استفاده از کتابخانه SJCL امنیت دادههای ذخیره شده، بالا میروند.
var storage = new secStore , options = { encrypt: true, data: { key: 'some data that is somewhat private' } }; storage.set(options, function(err, results){ if (err) throw err; console.log(results); });
و سایر کتابخانههای مرتبط :
اسمبلیهای نام قوی در برابر دستکاری مقاوم هستند
از آنجائیکه محتویات اسمبلی، هش شده و مقدار هش آن امضا میشود، در نتیجه اگر شخصی به دستکاری اسمبلی اقدام کرده باشد یا اینکه فایل مد نظر آسیب دیده باشد، به راحتی قابل شناسایی است و آن اسمبلی به عنوان اسمبلی صحیح شناسایی نخواهد شد و نمیگذارد در GAC ثبت شود.
موقعیکه برنامه نیاز داشته باشد به اسمبلی نام قوی بایند یا متصل شود، از 4 ویژگی گفته شدهی در قسمت قبلی استفاده میکند تا آن را در GAC بیابد. اگر اسمبلی درخواستی موجود باشد، زیر دایرکتوری آن برگشت داده خواهد شد؛ ولی اگر آن را نیابد، ابتدا در داخل دایرکتوری برنامه و سپس در مسیرهایی که در فایل پیکربندی ذکر شدهاند، به دنبال آن خواهد گشت و در نهایت اگر برنامه توسط فایل MSI نصب شده باشد، محلهای توزیع را از طریق آن جویا خواهد شد و اگر باز به نتیجهای نرسد، اتصال ناموفق گزارش شده و خطای زیر را ایجاد خواهد کرد:
System.IO.FileNotFoundException
System.IO.FileLoadExceptio
- جلوگیری از دستکاری و حفظ امنیت آن
- این اسمبلی تنها یکبار از حافظهی فیزیکی استفاده میکند؛ برعکس توزیع خصوصی که برای هر برنامه باید یک فضای دیسکی داشته باشد.
- توزیع سادهتر برای نسخههای آینده فراهم میشود که بعدا در مورد آن توضیح میدهیم.
سیاستهای انتخاب اسمبلی توسط GAC
موقعی که GAC میخواهد یک اسمبلی را برای برنامه شما بازگرداند، از روی خصوصیاتی چون نام اسمبلی، ورژن، فرهنگ، توکن کلید عمومی و در نهایت بسته به معماری ماشین، یک اسمبلی را برمیگرداند. در صورتیکه اسمبلی خاصی را برای ماشین مورد نظر پیدا نکند، از اسمبلی یک ماشین دیگر استفاده خواهد کرد. در واقع این انتخاب، یک سیاست پیش فرض است که میتواند از طریق ناشر یا مدیر سیستم تغییر پیدا کند و رونویسی شود.
کنترل مدیریت پیشرفته (پیکربندی)
در قسمت بیستم با ساخت فایل پیکریندی و نحوه تنظیم کردن اسکن اسمبلیها در CLR آشنا شدیم. این بار قصد داریم در مورد المانهای دیگر این فایل پیکریندی صحبت کنیم. فایل پیکربندی زیر را بررسی میکنیم:
<?xml version="1.0"?> <configuration> <runtime> <assemblyBinding xmlns="urn:schemasmicrosoftcom:asm.v1"> <probing privatePath="AuxFiles;bin\subdir" /> <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> <dependentAssembly> <assemblyIdentity name="TypeLib" publicKeyToken="1f2e74e897abbcfe" culture="neutral"/> <bindingRedirect oldVersion="3.0.0.03.5.0.0" newVersion="4.0.0.0" /> <publisherPolicy apply="no" /> </dependentAssembly> </assemblyBinding> </runtime> </configuration>
Probing | در
قسمت بیستم گفتیم که در این المان، مکانهایی را که CLR برای پیدا کردن
اسمبلیهای با نام ضعیف، باید اسکن کند، وارد میکنیم که هر مسیر با , از هم جدا شدهاست. برای اسمبلیهای با نام قوی CLR باید داخل GAC را نگاه
کند و در URL هایی که از طریق المان CodeBase مشخص کردهایم. اگر المان
CodeBase مشخص نشود، CLR برای پیدا کردن اسمبلیهای با نام قوی، داخل
دایرکتوریهای این المان را اسکن خواهد کرد. |
Dependent Assembly اول | در
اولین فرزند این المان، Assembly Identity یک اسمبلی با مشخصاتی مثل
Culture و توکن عمومی معرفی میشود و در BindingRedirect به CLR اطلاع
میدهد موقعی که به دنبال نسخه یک این اسمبلی است، نسخهی دو آن را برای
استفاده جایگزین کند. |
Code Base | این
المان میگوید که وقتی CLR سعی در پیدا کردن نسخهی 2 اسمبلی را دارد، آن را
از طریق آدرس مورد نظر پیدا کند. این المان میتواند برای اسمبلیهای با نام
ضعیف هم کار کند. |
Dependent Assembly دوم | این مورد هم همانند سابق است با این تفاوت که گسترهی نسخه 3 تا 3.5 را به نسخهی 4 تغییر میدهد. |
Publisher Policy | اگر
سازمان تولید کننده این اسمبلی فایلی برای تعیین Policy به همراه اسمبلی
ارائه کرده باشد، این المان باعث میشود این فایل ندیده گرفته شود (در مورد
فایل Policy در آینده صحبت میکنیم). |
با وجود این حالت اگر فرض کنیم مدیر یک سیستم متوجه شود که اسمبلی برنامه دچار مشکل شده است و با ناشر تماس بگیرد و ناشر نسخهی جدیدی از آن اسمبلی را در اختیار او بگذارد، مدیر سیستم میتواند به راحتی از طریق فایل پیکربندی، CLR را به استفادهی از اسمبلی جدید به جای اسمبلی قدیمی هدایت کند.
نکته : اگر مدیر بخواهد تمام برنامههای موجود از این اسمبلی جدید استفاده کنند باید فایل machine.config را ویرایش کند.