Windows 10 معرفی شد
با قابلیت اجرای Windows Store apps بر روی دسکتاپ
Exception و خوانایی کد
تکه کد زیر را در نظر بگیرید: یک Action معمولی در Asp.Net MVC که یک نام را دریافت کرده و یک کارمندرا ایجاد میکند:
public ActionResult CreateEmployee(string name) { try { ValidateName(name); // ادامه کدها return View("با موفقیت ثبت شد"); } catch (ValidationException ex) { return View("خطا", ex.Message); } } private void ValidateName(string name) { if (string.IsNullOrWhiteSpace(name)) throw new ValidationException("نام نمیتواند خالی باشد"); if (name.Length > 100) throw new ValidationException("نام نمیتواند طولانی باشد"); }
در این قطعه کد، در متد ValidateName، در صورت معتبر نبودن ورودی، یک Exception رخ میدهد و بلاک کد try/catch، این exception را دریافت کرده و خطای مناسبی را به کاربر نشان خواهد داد. تا اینجا ظاهرا همه چیز مرتب است و مشکلی ندارد! احتمالا کدهای مشابه به این کد را زیاد دیدهاید. در اینجا متد ValidateName، صادق نیست. در قسمت اول، در مورد Honesty صحبت کردیم. به عبارت سادهتر شما از امضای این متد نمیتوانید به نوع خروجی و کاری که قرار است انجام دهد، پی ببرید. در واقع شما همیشه باید پیاده سازی متد را گوشهای، در ذهن خود داشته باشید و برای اطمینان از کاری که متد انجام میدهد، همیشه باید به بدنهی متد برگردیم. اگر بهخاطر داشته باشید، توابع برنامه نویسی را به توابع ریاضی تشبیه کردیم. پس میتوانیم بگوییم:
به عبارت دیگر وقتی از exceptionها برای کنترل flow برنامه استفاده میکنید، مشابه کاری را انجام میدهید که دستور GOTO انجام میداد. این دستور در روشهای قبل از برنامه نویسی ساخت یافته وجود داشت و توسط یک دانشمند هلندی به نام آقای دیکسترا حذف شد. وقتی از دستور GOTO یا JUMP استفاده میکنیم، فهمیدن flow برنامه پیچیدگیهای زیادی را خواهد داشت. چراکه فراخوانی قطعههای کد و متدها، وابستگی شدیدی خواهند داشت و البته میتوان گفت استفاده از exceptionها برای کنترل جریان برنامه، میتوانند از GOTO هم بدتر باشند؛ چرا که exception میتواند از لایههای مختلف کد نیز عبور کند.
امیدوارم تا اینجا به یک عقیدهی مشترک رسیده باشیم. خوب راهکار چیست؟ تصور کنید که تکه کد بالا را به صورت زیر تبدیل کنیم:
public ActionResult CreateEmployee(string name) { string error = ValidateName(name); if (error != string.Empty) return View("خطا", error); // ادامه کدها return View("با موفقیت ثبت شد"); } private string ValidateName(string name) { if (string.IsNullOrWhiteSpace(name)) return "نام نمیتواند خالی باشد"; if (name.Length > 100) return "طول نام نمیتواند بیشتر از 100 کاراکتر باشد"; return string.Empty; }
با refactor ای که انجام دادیم، متد ValidateName را به یک تابع ریاضی تبدیل کردیم. به این معنا که هر آنچه را که از امضای متد، مشخص است، انجام میدهد و در این حالت چیزی مخفی نیست. توجه داشته باشید که این راهکار نهایی ما نیست و لطفا مقاله را تا انتها بخوانید!
موارد استفاده Exception
با همهی بدیهایی که از Exceptionها گفتیم، با این حساب پس چه زمانی از آن استفاده کنیم؟
- Exceptionها واقعا برای موارد استثنائی هستند.
- Exceptionها برای شرایطی هستند که به معنای واقعی یک باگ باشند.
- منتظر رخ دادن Exception نباشیم!
در توضیح مورد سوم، در اعتبار سنجی دادههای کاربر (Validation) انتظار دادهی نادرستی را میتوان داشت، پس نمیتوانیم آن را یک حالت استثنایی بدانیم. معماری زیر را در نظر بگیرید
دیتایی که به API ما ارسال خواهد شد، همیشه شامل عملیات Filter یا به عبارتی Validation است و از آنجایی که میتوان انتظار استفادهی نادرست یا دیتای نادرست را داشت، نمیتوانیم این را حالتی از استثنائات در نظر بگیریم؛ ولی بر خلاف آن، وقتی در دامین پروژه و ارتباط بین دامینهای مختلف، دیتایی رد و بدل میشود که معتبر نیست، میتوانیم آن را جزء استثناءها در نظر بگیریم. به مثال زیر دقت کنید:
public ActionResult UpdateEmployee(int employeeId, string name) { string error = ValidateName(name); if (error != string.Empty) return View("Error", error); Employee employee = GetEmployee(employeeId); employee.UpdateName(name); } public class Employee { public void UpdateName(string name){ if (name == null) throw new ArgumentNullException(); // ادامه کدها } }
در قطعه کد بالا تصور این است که کلاس Employee و متد UpdateName خارج از دامین میباشند. همانطورکه مشاهده میکنید، ما در action controller، از خالی نبودن نام اطمینان حاصل کردیم و سپس آن را به متد UpdateName ارجاع دادیم. ولی اگه به بدنهی متد UpdateName دقت کنید، میبینید که مجددا از خالی نبودن نام اطمینان حاصل کردهایم و در صورت خالی بودن، یک Exception را صادر میکنیم! به این مدل چک کردنها در دامینهای مختلف، معمولا guard clause گفته میشود و یک نوع قرارداد بین برنامه نویس هاست. اگر طبق تعریفی که بالاتر ارائه کردیم هم چک کنیم، میتوانیم حدس بزنیم که خالی بودن نام، نشان یک باگ در نرم افزار است!
مفهوم fail fast
تا اینجا متوجه شدیم که از exceptionها باید در شرایط استثنائی استفاده کنیم. خوب با توجه به این مساله، چه طور میتوانیم آنها را Handle کنیم؟ این سؤال ما را به مفهومی به نام fail fast میرساند. این مفهوم به ما میگوید:
- کار جاری را به محض یک اتفاق استثنائی باید متوقف کنیم.
- رعایت این نکته در نهایت ما را به یک نرم افزار پایدار خواهد رساند.
برای درک هر چه بهتر این موضوع، بیایید به عکس این حالت نگاه کنیم؛ اصطلاحا Fail Silently.
متد زیر را ببینید:
public void ProcessItems(List<Item> items) { foreach (Item item in items) { try { Process(item); } catch (Exception ex) { Logger.Log(ex); } } }
در قطعه کد بالا، در نگاه اول احتمالا حس نرم افزار پایدارتر و بدون خطا را خواهیم داشت. اما در واقع اینطور نیست. احتمال اینکه خطا از چشم برنامه نویس به دور باشد و بعد از اجرا باعث شود که یکپارچگی دادهها را به هم بریزد وجود دارد. در واقع هیچ راهی برای زمانیکه این عملیات نباید انجام شود، در نظر گرفته نشدهاست. طبق صحبتهایی که بالاتر داشتیم، شرایط غیر منتظره، در واقع یک باگ در نرم افزار است و هیچ مزیتی در جلوگیری از وقوع این باگ بدون حل مشکل نیست!
به صور خلاصه مهمترین مزیت Fail Fast را میتوانیم به صورت زیر خلاصه کنیم:
- مسیر رسیدن به خطاها سر راستتر میشود.
- نرم افزار به پایداری مناسبی خواهد رسید.
- از اعتبار دیتای ذخیره شده اطمینان خواهیم داشت.
کجا exceptionها را به دام بیندازیم؟
در یکی از حالتهای زیر:
- لاگ کردن
- متوقف کردن عملیات
- هیچ گاه در بلاک catch هیچ منطقی را پیاده نکنید.
حالت دیگر در استفاه از کتابخانههای دیگران (3rd parties) است. به طور مثال در استفاده از EF ممکن است به دلیل عدم برقراری ارتباط با دیتابیس، خطایی را دریافت کنید. در این حالت با توجه به نکات فوق، با این استثنائات برخورد کنید:
- جلوی این نوع استثنائات را در پایینترین حد ممکن در کد خود بگیرید.
- Exception هایی را catch کنید که میدانید در حالت استثناء، چه کاری را میتوانید انجام دهید.
این به این معنی میباشد که به صورت کلی همه نوع Exception ای را به صورت کلی نگیرید و نوع Exception اختصاصی را در بلاک catch قرار دهید. الان که قرار شد در بعضی از حالتها جلوی استثنائات را بگیریم، خوب است ببینیم چطور باید اینکار را انجام بدیم.
قطعه کد زیر را در نظر بگیرید:
public void CreateCustomer(string name) { Customer customer = new Customer(name); bool result = SaveCustomer(customer); if (!result) { MessageBox.Show("Error connecting to the database. Please try again later."); } } private bool SaveCustomer(Customer customer) { try { using (MyContext context = new MyContext()) { context.Customers.Add(customer); context.SaveChanges(); } return true; } catch (DbUpdateException ex) { if (ex.Message == "Unable to open the DB connection") return false; else throw; } }
همانطور که مشاهده میکنید، در حالتیکه خطایی از نوع DbUpdateException رخ میدهد، مقدار بازگشتی متد را برابر با false میکنیم. اما مشکلی که وجود دارد این است که اینکار به اندازهی کافی خوانا نیست. همچنین honest بودن متد را نقض کردهایم. به علاوه مشکل بزرگتر دیگر این است که ما با بازگرداندن یک مقدار bool، میتوانیم به متد بالاتر اطلاع بدهیم که کار مورد نظر انجام شده یا نه، اما در مورد دلیل انجام نشدن آن، هیچ کاری نمیتوانیم بکنیم. پیشنهاد من برای مقدار بازگشتی متدهایی که احتمال انجام نشدن کاری در آنها میرود، استفاده از یک نوع اختصاصی میباشد.
در اینجا من این نوع را با نام کلاس Result معرفی میکنم. انتظاری که از این نوع اختصاصی داریم:
- Honest بودن متد را نگه دارد.
- خروجی متد را به همراه وضعیت اجرا شدن برگرداند.
- شکل یکسانی را برای خطاها داشته باشد.
- فقط جلوی خطاهای غیر منتظره را بگیرد.
برای مثال کد بالا را به شکل زیر refactor میکنیم:
private Result SaveCustomer(Customer customer) { try { using (var context = new MyContext()) { context.Customers.Add(customer); context.SaveChanges(); } return Result.Ok(); } catch (DbUpdateException ex) { if (ex.Message == "Unable to open the DB connection") Result.Fail(ErrorType.DatabaseIsOffline); if (ex.Message.Contains("IX_Customer_Name")) return Result.Fail(ErrorType.CustomerAlreadyExists); throw; } }
به عبارتی با این روش میتوانیم از انجام شدن/نشدن عملیات اطمینان حاصل کنیم و خروجی/دلیل انجام نشدن را نیز میتوانیم برگردانیم.
اگر به امضای متدهای زیر نگاه کنیم، میتوانیم آنها را طبق الگوی CQS دستهبندی کنیم:
به عنوان نمونه یک پیاده سازی از این کلاس را در اینجا قرار دادهام. قطعا میتوانیم پیاده سازیهای بهتری را از این کلاس داشته باشیم. خوشحال میشوم که نظرات خود رو با ما به اشتراک بگذارید. امیدوارم که این قسمت و صحبتهایی که در مورد استثنائات داشتیم، توانسته باشد دیدگاه جدیدی را به کدهایتان بدهد. در ادامهی این سری مطالب، مفاهیم پارادایم برنامه نویسی تابعی را بیشتر مورد بررسی قرار خواهیم داد.
Feature Toggle
"Feature Toggling" is a set of patterns which can help a team to deliver new functionality to users rapidly but safely
public interface IFeatureToggle { bool FeatureEnabled {get;} }
class ShowMessageToggle : IFeatureToggle
{
public bool FeatureEnabled {
get{
return bool.Parse(ConfigurationManager.AppSettings["ShowMessageEnabled"]);
}
}
class Program { static void Main(string[] args) { var toggle = new ShowMessageToggle(); if (toggle.FeatureEnabled) { Console.WriteLine("This feature is enabled") } else { Console.WriteLine("This feature is disabled"); } } }
Install-Package FeatureToggle
MyAwesomeFeature : SimpleFeatureToggle {}
<add key="MyAwesomeFeature " value="true" />
if (!myAwesomeFeature.FeatureEnabled) { // code to disable stuff (e.g. UI buttons, etc) }
ترجمه بخشی از متن اصلی به نقل از خبرگزاری دانشجو :
یافته تکان دهنده کسپراسکای این است که Equation قابلیت آلوده کردن سفتافزار یک درایو سخت یا کد سطح پایینی که نقش واسط بین سختافزار و نرمافزار را بازی میکند را داراست.
این بدافزار سفتافزار درایو سخت را برنامهریزی مجدد میکند و سکتورهای پنهانی روی درایو ایجاد میکند که فقط میتوانند از طریق یک API سری مورد دسترسی قرار گیرند. حذف این بدافزار پس از نصب غیرممکن است، فرمت کردن دیسک و نصب مجدد سیستم عامل هیچ تأثیری بر روی آن ندارد و سکتورهای پنهان همچنان باقی میمانند.
درایوهای ساخته شده توسط سیگیت، وسترن دیجیتال، هیتاچی، سامسونگ، آیبیام، میکرون و توشیبا میتوانند توسط ۲ پلتفورم بدافزار Equation یعنی Equationdrug و Grayfish دستکاری شوند.
بنا بر این گزارش، Equation دانشی از این درایوها در اختیار دارد که بسیار بیشتر از اسناد عمومی منتشر شده توسط تولید کنندگان آنها است.
Equation مجموعه دستورات ATA یکتای مورد استفاده توسط تولید کنندگان درایوهای سخت را برای فرمت کردن محصولات آنها میداند. اغلب دستورات ATA عمومی هستند، چرا که از استانداردی استفاده میکنند که این اطمینان را ایجاد میکند که درایو سخت با هر نوع کامپیوتری سازگار است. اما دستورات ATA ی غیر مستندی وجود دارند که توسط تولید کنندگان برای اعمالی مانند ذخیرهسازی داخلی و تصحیح خطا به کار میروند. در حقیقت، آنها یک سیستم عامل بسته هستند. دستیابی به چنین کدهای ATA، نیازمند دسترسی به این اسناد است که هزینه زیادی در بر دارد. احتمال اینکه کسی بتواند با استفاده از اطلاعات عمومی، سیستم عامل درایو سخت را بازنویسی کند تقریباً صفر است.
بنا بر اظهارات رایو، قابلیت برنامهریزی مجدد سفتافزار فقط یک مدل درایو سخت به طرز باورنکردنی پیچیده است. اما دارا بودن چنین قابلیتی برای انواع زیادی از درایوها از تولیدکنندگان مختلف تقریباً غیرممکن است.
به نظر میرسد که Equation بسیار بسیار جلوتر از صنعت امنیت است. تشخیص این نوع نفوذ تقریباً غیرممکن است. پاک کردن کامل درایو یا تعویض سفتافزار آن نیز چندان مفید نیست، چرا که برخی از انواع ماژولها در برخی سفتافزارها دائمی هستند و نمیتوانند مجدداً فرمت گردند.
1. شاید یکی از آزاردهندهترین مشکلات، برخورد با پیغامهای خطا، هنگام عملیات migration باشد. یکی از دهها نوع خطا، زمانی رخ میدهد که متد seed در حال اجراست. در این حالت هیچ نوع break-point ایی به کمک ما نخواهد آمد.
سوال ایجاست که آیا میتوان این بخش را دیباگ نمود؟ بهترین راه حل، اجرای آپدیت از طریق متدها(یا اکشن ها) است.
فراخوانی migration بسیار ساده است. باید یک نمونه از کلاس Configuration را ساخته و در جایی از پروژه قرار دهیم و صد
البته مطمئن باشیم که migration فعال است.
var configuration = new Configuration(); var migrator = new DbMigrator(configuration); migrator.Update();
اگر بخواهید این تغییرات بر روی دیتابیسی با اسم و رسم انجام شود، از کد زیر بهره بگیرید:
var configuration = new Configuration(); configuration.TargetDatabase = new DbConnectionInfo( "Server=MyServer;Database=MyDatabase;Trusted_Connection=True;", "System.Data.SqlClient"); var migrator = new DbMigrator(configuration); migrator.Update();
2. خطای :
Duplicate type name within an assembly.
معمولا بخاطر وجود break-point این مشکل رخ میدهد. یا break-pointهای درون seed را حذف کنید یا جای آنها را تغییر دهید. [اینجا]
3. خطای :
Validation failed for one or more entities. See 'EntityValidationErrors' property for more details.
این مشکل میتواند دلایل مختلفی داشته
باشد. کد درون متد seed را داخلtry/catch قرا ر دهید و علت آن را بررسی کنید:
try { var user = new ApplicationUser { UserName = "Admin", Phone = "09120000000", Email = "m@gmail.com" }; usermanager.Create(user, "09120000000"); usermanager.AddToRole(user.Id, "admin"); } catch (DbEntityValidationException dbEx) { foreach (var validationErrors in dbEx.EntityValidationErrors) { foreach (var validationError in validationErrors.ValidationErrors) { Trace.TraceInformation("Property: {0} Error: {1}", validationError.PropertyName, validationError.ErrorMessage); } } }
فراموش نکنید، seed را به کمک حالتی که در شماره 1 گفته شد اجرا کنید تا بتوانید از BreakPoint استفاده کنید.
4.خطای :
More than one context type was found in the assembly 'Ex1_CodeFirst'
این خطا وقتی ظاهر میشود که چندین Context برای
پروژه جاری داشته باشیم و ویژوال استودیو نتواند Context مورد نظر ما را تشخیص
دهد. بهتر است هنگام اجرای migration نام context مورد نظر را بنویسیم (مثلا MyConfiguration نام کانتکست شماست) :
Update-Database -ConfigurationTypeName MyConfiguration
There is already an object named 'UserProfile' in the database.
یعنی مدل شما پس از اینکه جدولی با همین نام (در این جا به عنوان مثال UserProfile) از پیش موجود بوده، تغییر کرده است؛ پس migration آپدیت شدنی نیست. ابتدا این دستور را مینویسیم (پیش از آنکه تغییراتمان را روی کلاس مربوط به جدول UserProfile اعمال کنیم):
Add-Migration Initial –IgnoreChanges
update-database –verbose
گاهی این مشکل زمانی پیش میآید که واقعا تغییری در جدول نامبرده انجام ندادهایم. در این حالت روش پلهای زیر را به کار میبریم:
- پاک کردن یا ریست کردن migration (در شماره 9 همین مقاله این کار در چند مرحله توضیح داده شده است. در مرحله سوم حتما از Add-Migration Initial –IgnoreChanges استفاده کنید)
- بعد از آپدیت دیتابیس باید فایل زیر دارای محتویات باشد
محتویات این فایل دقیقا شرایط فعلی جدول شماست.
- اگر این فایل ایجاد نشده است مراحل را تکرار کنید تا محتویات درون آن را ببینید.
- حالا تغییری را در یکی از مدلهای خود انجام دهید. احتمالا با مشکل آپدیت شدن مواجه میشوید و پیغام زیر را دوباره خواهید دید:
There is already an object named 'UserProfile' in the database
- جدولی را که پیغام خطا به آن اشاره کرده، در فایل فوق بیابید و محدوده create آن را کامنت کنید تا ساخته نشود.
- دیتابیس را آپدیت کنید، احتمالا پیغام خطای فوق برای جدول دیگری نمایش داده میشود. آن را هم کامنت کنید و دیتابیس را آپدیت کنید و اگر باز هم خطا بود مکانیزم بالا را تا جایی تکرار کنید که خطایی نبینید .
- حالا جدولی را که تغییراتی در آن داده بودید، در دیتابیس چک کنید که تغییرات اعمال شده باشد.
- هر آنچه را در فایل initial کامنت کرده بودید، از کامنت خارج کنید و دیتابیس را آپدیت کنید .
- برای آزمایش، یک آیتم به یکی از مدلها اضافه کنید و ببینید که migration درست کار میکند یا خیر.
Unable to update database to match the current model because there are pending changes and automatic migration is disabled. Either write the pending model changes to a code-based migration or enable automatic migration. Set DbMigrationsConfiguration.AutomaticMigrationsEnabled to true to enable automatic migration. You can use the Add-Migration command to write the pending model changes to a code-based migration.
7.خطای :
Automatic migration was not applied because it would result in data loss.
AutomaticMigrationDataLossAllowed = true;
Introducing FOREIGN KEY constraint 'FK_dbo.ProductProductGroups_dbo.ProductGroups_ProductGroupId' on table 'ProductProductGroups' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints. Could not create constraint or index. See previous errors.
9. راه حل برای خطاهای عجیبی که شاید نیاز به صرف زمان بیشتر برای کشف و برطرف کردن داشته باشند :
بهتر نیست مایگریشن خود را از نو بسازید؟
روش به روز رسانی و بازسازی migration [اینجا ]:
- پاک کردن فولدر Migrations در پروژه
- پاک کردن جدولی به نام MigrationHistory_ در دیتابیس (ممکن است زیر مجموعه جدولهای system باشد)
- اجرای دستور زیر کنسول پکیچ منیجر ویژوال استودیو :
Enable-Migrations -EnableAutomaticMigrations -Force
- اجرای دستور زیر :
Add-Migration Initial
دسترسی بر اساس کاربر و نقش آن
انتشار رادار فناوری اطلاعات Vol 27
چرا از آنگولار به ری اکت + ری داکس سوئیچ کردم!
در حین توسعه نکات زیادی باید مورد توجه قرار بگیرد اول اینکه ری اکت نیازمند و محتاج کتابخانههای متفرقه ای هست که باید با انتخاب خودتان استفادده شوند حال اگر در نظر بگیریم در یکی از آپدیتها ناسازگاری صورت بگیرد میتواند کل پروژه را تحت تاثیر قرار بدهد ولی در انگیولار از آنجا یک دستی کار توسط انگیولار تامین میشود کمتر این مشکلات دیده میشود ، همین الانش هم گاها مشکلاتی در این حالت رخ میدهد وای به حال اینکه توسط هیچ منبعی این یک دستی صورت نگیرد. حال تصور کنید در آپدیت عظیم یک پروژه چگونه یک مشکل کوچک میتواند کل کار را برای مدتی بر زمین بزند با این ادعا که کتابخانههای متن باز و رایگان تحت لایسنسهای مختلف داریم.
در لینکی که قرار دادید نوشته است که کامپوننتهای خود را کوچک نگه دارید یعنی اینکه توسعه دهنده میداند که اگر یک کامپوننت بخواهد بزرگ شود به چه دردسر زیادی میرسد و چه مخلوطی از کدها را خواهد داشت.
استفاده از تایپ اسکریپت برای انگیولار یک نقطه ضعف نیست بلکه یک مزیت محسوب میشود. استفاده از تایپ اسکریپ باعث میشود نگهداری کد سادهتر باشد و کدها را در قالب سادهتر و با سرعت بیشتری میتوان نوشت. هر روز نسخه جدید از مرورگها با پشتیبانی از فناوریهای جدید میآیند ولی بنا به مسائلی چون عدم پشتیبانی مرورگرها و یا قدیمی بودن مرورگر کاربر مجبور هستیم کدها را به شکل قدیمی بنویسیم و شاید این کدهای جدید باعث سرعت و کارایی بهتر باشند ولی با تایپ اسکریپت میتوان در آینده تنها یا یک ترانسپایل ساده به هر ورژن از ES تبدیل کنیم بدون اینکه نیاز به بازنویسی کد داشته باشیم که مستلزم وقت و هزینه خواهد بود. پس کدی که الان نوشته میشود در واقع کد به روز برای آینده هم محسوب میشود.
از نظر جنبه مالی همه پروژها به همین صورت هستند و ری اکت هم مستثنی نیست. همه کتابخانه هایی که متن باز هستند اگر به سود دهی نرسند و یا دیگر راضیشان نکند ان را رها میکنند. ابزرهای متن باز هم بدین صورت هستند هیچ شرکتی نمیآید پول و زمانش را صرف چیزی کند که برایش هیچ منفعتی به دنبال نداشته باشد و این قانون اول تجارت است. آیا فیس بوک همانند مایکروسافت یا گوگل نیست؟
ولی در نهایت هر دو ابزار و دیگر ابزارها هستند و تیم سازنده با توجه به نیازها باید ابزار خود را انتخاب کند.
روش کاهش چشمگیر میزان مصرف اینترنت ویندوز 8
ویندوز 10 دارای قابلیتی است به نام «Windows Update Delivery Optimization». این مورد سیستم شما را تبدیل به یک «به اشتراک گذارندهی به روز رسانیها» در شبکه و یا اینترنت میکند (چیزی شبیه به تورنت).
اگر از نسخهی سازمانی استفاده میکنید، این قابلیت فقط در شبکهی داخلی فعال است که سبب صرفه جویی قابل ملاحظهای برای دریافت به روز رسانیها در یک شرکت یا مجموعه خواهد شد. در مورد سایر نسخهها، خیر و این به اشتراک گذاری در سطح اینترنت است.
برای خاموش کردن آن مسیر ذیل را طی کنید:
Choose how updates are delivered, and then use the toggle to turn Delivery Optimization off