.NET Core 2.1.6 is available for download and usage in your environment. This release includes .NET Core 2.1.6, ASP.NET Core 2.1.6 and .NET Core SDK 2.1.500. All fixes of note can be seen in the 2.1.6 commits list.
The Open XML SDK provides tools for working with Office Word, Excel, and PowerPoint documents. It supports scenarios such as:
- High-performance generation of word-processing documents, spreadsheets, and presentations.
- Document modification, such as adding, updating, and removing content and metadata.
- Search and replace content using regular expressions.
- Splitting up (shredding) a file into multiple files, and combining multiple files into a single file.
- Updating cached data and embedded spreadsheets for charts in Word/PowerPoint.
اشتراکها
کتاب درک رمزنگاری اطلاعات
Cryptography has crept into everything, from web browsers and email programs to cell phones, bank cards, cars and even into medical implants. Thus, an increasing number of people have to understand how crypto schemes work and how they can be used in practice. We wanted to create a book that teaches modern applied cryptography to readers with a technical background but without an education in pure mathematics.
نظرات مطالب
کار با اسکنر در برنامه های تحت وب (قسمت اول)
یک نکتهی تکمیلی
کتابخانهی « DNTScanner.Core » امکان کار با اسکنر را در برنامههای NET 4x. و همچنین NET Core. ویندوزی میسر میکند.
مثالها
- روش استفاده از آن در برنامههای کنسول
- روش استفادهی از آن در یک برنامهی وب ASP.NET Core که قسمت اسکنر آن به صورت یک کلاینت کنسول تهیه شدهاست و ارتباط بین این دو از طریق SignalR.Core برقرار میشود.
کتابخانهی « DNTScanner.Core » امکان کار با اسکنر را در برنامههای NET 4x. و همچنین NET Core. ویندوزی میسر میکند.
مثالها
- روش استفاده از آن در برنامههای کنسول
- روش استفادهی از آن در یک برنامهی وب ASP.NET Core که قسمت اسکنر آن به صورت یک کلاینت کنسول تهیه شدهاست و ارتباط بین این دو از طریق SignalR.Core برقرار میشود.
How to Level Up Your Coding with GitHub Copilot?
TL;DR: AI coding tools like GitHub Copilot are revolutionizing development by offering smart code suggestions, error detection, and seamless integration with popular IDEs. With 70% of developers embracing AI for increased productivity, you can boost your coding efficiency and focus on creative solutions with AI assistance.
پیشنهادها
استفاده از spatial data در EF
پشتیبانی از spatial data به EF 5 اضافه شد. نیاز است به کمک مآخذ ذیل، یک مطلب جدید در مورد آن تهیه شود:
- Basic Spatial Data with SQL Server and Entity Framework 5.0
- Using spatial data types with Entity Framework 5.0
- Using Spatial Data with SQL Server 2012, Entity Framework 5 and ASP.NET MVC
- Spatial Data Type Support in Entity Framework 5
- Using Spatial Data in ASP.Net MVC with SQL Server 2012, Entity Framework 5 and Infragistics jQuery Map
- Spatial Data and the Entity Framework
- Spatial data and Entity Framework - from real world usage
- Entity Framework Spatial Part 1: Loading data
- Spatial Data type support in Entity Framework 5.0
- Creating a Geometry Point in Entity Framework
- Spatial - Code First
- Spatial Types in the Entity Framework
- How To: Using spatial data with Entity Framework and Connector/Net
الگوی decorator، امکان محصور کردن یک شیء مفروض را با لایهای بر فراز آن میسر میکند. برای مثال بجای اینکه در تمام متدهای سرویسی از try/catch استفاده کنیم، میتوانیم این متدها را با یک ExceptionHandlingDecorator مزین کنیم و یا از این دست اعمال تکراری میتوان به لاگ کردن ورودی و خروجیهای یک متد و یا کش کردن اطلاعات آنها نیز اشاره کرد. حتی عملیاتی مانند تشخیص خواص تغییر یافتهی یک شیء در Entity framework نیز به کمک همین مزین کنندهها که شیء اصلی در حال استفاده را با ایجاد لایهای بر روی آنها محصور میکنند، انجام میشود. به این عملیات Aspect oriented programming و یا AOP نیز میگویند؛ در اینجا واژهی Aspect به اعمال مشترک و متداول موجود در برنامه اشاره میکند. در این مطلب قصد داریم نمونهای از این تزئین کنندهها را به کمک سیستم تزریق وابستگیهای NET Core. پیاده سازی کنیم.
پیاده سازی الگوی Decorator به کمک سیستم تزریق وابستگیهای NET Core.
مثال زیر را در نظر بگیرید که در آن یک سرویس تعریف شدهاست و در این بین استثنائی رخ دادهاست.
میخواهیم بدون تغییری در کدهای این کلاس، به متدهای آن در حین اجرای نهایی، یک try/catch را به همراه logging، اضافه کنیم. به همین جهت نیاز خواهیم داشت تا یک محصور کننده (تزئین کننده یا decorator در اینجا) را برای آن طراحی کنیم:
این محصور کننده نیز دقیقا همان ITaskService را پیاده سازی میکند؛ اما در سازندهی آن یک ITaskService را نیز دریافت میکند. علت اینجا است که توسط آن بتوان متدهای ITaskService تزریقی را اجرا کرد و بر روی آن اعمالی مانند کش کردن، لاگ کردن و مدیریت استثناءها و غیره را انجام داد. برای مثال در متد Run آن مشاهده میکنید که متد Run همان وهلهی تزریقی اجرا شدهاست؛ اما درون یک try/catch به همراه لاگ کردن جزئیات استثنای رخ داده.
مزیت اینکار، پیاده سازی اصل DRY یا Don't repeat yourself است. کاری که برای رفع این مشکل قرار است انجام دهیم، استفاده از یک تزئین کننده (محصور کننده)، کپسوله سازی اعمال تکراری و سپس اتصال آن به قسمتهای مختلف برنامه است. همچنین در این حالت اصل open closed principle نیز بهتر رعایت خواهد شد. از این جهت که کدهای تکراری برنامه به یک لایهی دیگر منتقل شدهاند و دیگر نیازی نیست برای تغییر آنها، کدهای قسمتهای اصلی برنامه را تغییر داد (کدهای برنامه باز خواهند بود برای توسعه و بسته برای تغییر).
پس از طراحی این تزئین کننده، اکنون نوبت به معرفی آن به سیستم تزریق وابستگیهای NET Core. است:
روش انجام اینکار را نیز در «قسمت ششم - دخالت در مراحل وهله سازی اشیاء توسط IoC Container» بیشتر بررسی کردهایم.
در اینجا هم میتوان در صورت نیاز اصل کلاس MyTaskService را بدون هیچ نوع تزئین کنندهای از سیستم تزریق وابستگیها دریافت کرد و یا اگر وهلهای از سرویس ITaskService را از آن درخواست کردیم، ابتدا شیء MyTaskServiceDecorator وهله سازی شده و سپس توسط آن یک نمونهی محصور شده و تزئین شدهی MyTaskService به فراخوان بازگشت داده خواهد شد.
ساده سازی معرفی تزئین کنندهها به سیستم تزریق وابستگیهای NET Core. به کمک Scrutor
در «قسمت هشتم - ساده سازی معرفی سرویسها توسط Scrutor» با کتابخانهی Scrutor آشنا شدیم. یکی دیگر از قابلیتهای آن، امکان ساده سازی تعریف تزئین کنندها است:
در اینجا معادل کدهایی را که با روش factory خود NET Core. نوشتیم، ملاحظه میکنید. ابتدا نیاز است خود سرویس اصلی غیر تزئین شده، به نحو متداولی به سیستم معرفی شود. سپس متد الحاقی جدید <,>Decorate را با همان اینترفیس و اینبار با Decorator مدنظر معرفی میکنیم. کاری که Scrutor در اینجا انجام میدهد، یافتن سرویس ITaskService معرفی شدهی پیشین و تعویض آن با MyTaskServiceDecorator میباشد. بنابراین نیاز است تعریف services.AddTransient پیش از تعریف services.Decorate انجام شده باشد. این روش تمیزتر از روش قبلی به نظر میرسد و شامل وهله سازی مستقیم MyTaskServiceDecorator به همراه فراهم آوردن تمام پارامترهای سازندهی آن توسط ما نیست.
پیاده سازی الگوی Decorator به کمک سیستم تزریق وابستگیهای NET Core.
مثال زیر را در نظر بگیرید که در آن یک سرویس تعریف شدهاست و در این بین استثنائی رخ دادهاست.
public interface ITaskService { void Run(); } public class MyTaskService : ITaskService { public void Run() { throw new InvalidOperationException("An exception from the MyTaskService!"); } }
using System; using Microsoft.Extensions.Logging; namespace CoreIocServices { public class MyTaskServiceDecorator : ITaskService { private readonly ILogger<MyTaskServiceDecorator> _logger; private readonly ITaskService _decorated; public MyTaskServiceDecorator( ILogger<MyTaskServiceDecorator> logger, ITaskService decorated) { _logger = logger; _decorated = decorated; } public void Run() { try { _decorated.Run(); } catch (Exception ex) { _logger.LogCritical(ex, "An unhandled exception has been occurred."); } } } }
مزیت اینکار، پیاده سازی اصل DRY یا Don't repeat yourself است. کاری که برای رفع این مشکل قرار است انجام دهیم، استفاده از یک تزئین کننده (محصور کننده)، کپسوله سازی اعمال تکراری و سپس اتصال آن به قسمتهای مختلف برنامه است. همچنین در این حالت اصل open closed principle نیز بهتر رعایت خواهد شد. از این جهت که کدهای تکراری برنامه به یک لایهی دیگر منتقل شدهاند و دیگر نیازی نیست برای تغییر آنها، کدهای قسمتهای اصلی برنامه را تغییر داد (کدهای برنامه باز خواهند بود برای توسعه و بسته برای تغییر).
پس از طراحی این تزئین کننده، اکنون نوبت به معرفی آن به سیستم تزریق وابستگیهای NET Core. است:
namespace CoreIocSample02 { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddTransient<MyTaskService>(); services.AddTransient<ITaskService>(serviceProvider => new MyTaskServiceDecorator( serviceProvider.GetService<ILogger<MyTaskServiceDecorator>>(), serviceProvider.GetService<MyTaskService>()) );
در اینجا هم میتوان در صورت نیاز اصل کلاس MyTaskService را بدون هیچ نوع تزئین کنندهای از سیستم تزریق وابستگیها دریافت کرد و یا اگر وهلهای از سرویس ITaskService را از آن درخواست کردیم، ابتدا شیء MyTaskServiceDecorator وهله سازی شده و سپس توسط آن یک نمونهی محصور شده و تزئین شدهی MyTaskService به فراخوان بازگشت داده خواهد شد.
ساده سازی معرفی تزئین کنندهها به سیستم تزریق وابستگیهای NET Core. به کمک Scrutor
در «قسمت هشتم - ساده سازی معرفی سرویسها توسط Scrutor» با کتابخانهی Scrutor آشنا شدیم. یکی دیگر از قابلیتهای آن، امکان ساده سازی تعریف تزئین کنندها است:
namespace CoreIocSample02 { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddTransient<ITaskService, MyTaskService>(); services.Decorate<ITaskService, MyTaskServiceDecorator>();
اشتراکها
Reflector 10 منتشر شد
What's new in this release?
- Full C#7.0 support
- .NET Core support
For more information, please see the release notes.
Upgrading to .NET Reflector 10
.NET Reflector 10 is a major upgrade from .NET Reflector 9. If your current license includes a valid support and upgrades package for .NET Reflector 10, the same license serial number will automatically activate .NET Reflector 10.
If your v9.x license does not include support and upgrades, Reflector will upgrade to a 14-day trial of v10.0.
فرض کنید قرارداد IService را تدارک دیدهاید و بر اساس آن سرویسهای A و B را به سیستم تزریق وابستگیهای برنامههای NET Core. تزریق کردهاید (برای مثال در برنامه دو DbContext را تعریف کردهاید و یک اینترفیس IUnitOfWork را دارید). اکنون اگر از این سیستم، یک پیاده سازی IService را درخواست کنید، چه اتفاقی رخ میدهد؟ در حالت معمول آن، آخرین سرویسی را که ثبت کردهاید، یعنی وهلهای از سرویس B را بازگشت خواهد داد. در ادامه قصد داریم با این قابلیت امکان ثبت چندین سرویس مشتق شدهی از یک اینترفیس، بیشتر آشنا شویم.
ثبت پیاده سازیهای متعدد یک اینترفیس در سیستم تزریق وابستگیهای NET Core.
داشتن چندین پیاده سازی از یک اینترفیس، شاید یکی از اهداف اصلی وجود آنها باشد. برای نمونه قرار داد ارسال پیامی را در برنامه، مانند IMessageService به صورت زیر طراحی و سپس بر اساس آن، دو پیاده سازی ارسال پیامها را از طریق ایمیل و SMS، اضافه میکنیم:
در ادامه برای معرفی آنها به سیستم تزریق وابستگیهای NET Core.، به نحو متداول زیر عمل خواهیم کرد و هر دوی این پیاده سازیها را بر اساس اینترفیس آنها معرفی میکنیم:
در این حالت اگر این سرویسها را به صورت زیر به یک کنترلر تزریق کنیم، انتظار دریافت کدام سرویسها را خواهید داشت؟
در این حالت اگر بر روی سازندهی این کنترلر یک break-point را قرار دهیم، پارامترهای تزریق شدهی در سازندهی کلاس به صورت زیر خواهند بود:
همانطور که مشاهده میکنید، هر دو پارامتر، با وهلهای از آخرین سرویس معرفی شدهی از نوع IMessageService مقدار دهی شدهاند؛ یعنی SmsService در اینجا. در ادامه روشهای مختلفی را برای رفع این مشکل بررسی میکنیم.
روش اول: سیستم تزریق وابستگیهای NET Core. از سازندههای IEnumerable پشتیبانی میکند
برای مدیریت دریافت سرویسهایی که از یک اینترفیس مشتق شدهاند، خود NET Core. بدون نیاز به تنظیمات اضافهتری، روش تزریق IEnumerableها را در سازندههای کلاسها پشتیبانی میکند:
در اینجا نیز اگر بر روی سازندهی این کنترلر یک break-point را قرار دهیم، پارامتر تزریق شدهی در سازندهی کلاس به صورت زیر خواهد بود:
به این ترتیب لیست وهلههای تمام سرویسهایی از نوع IMessageService در اختیار ما قرار گرفتهاست و برای اهدافی مانند پیاده سازی الگوهایی در ردهی chain of responsibility و یا الگوی استراتژی، مفید است. در این حالت اگر نیاز به سرویس از نوع خاصی وجود داشت، میتوان از روش زیر استفاده کرد:
و یا اگر از روش Service Locator استفاده میکنید، serviceProvider به همراه متد ویژهی GetServices که لیست تمام سرویسهایی از نوعی خاص را بر میگرداند نیز هست:
روش دوم: دریافت شرطی وهلههای مورد نیاز با «دخالت در مراحل وهله سازی اشیاء توسط IoC Container»
روش «دخالت در مراحل وهله سازی اشیاء توسط IoC Container» را در قسمت قبل بررسی کردیم. یکی دیگر از مثالهایی را که در این مورد میتوان ارائه داد، شرطی کردن بازگشت وهلهها است که برای سناریوی مطلب جاری بسیار مفید است:
الف) برای شرطی کردن بازگشت وهلهها، بهتر است این شرط را بجای رشتهها و یا اعدادی خاص، بر اساس یک enum مشخص انجام دهیم:
در اینجا یک enum جدید را تعریف کردهایم تا مقایسهها را در زمان بازگشت سرویسی خاص، بر اساس اعضای مشخص آن انجام دهیم.
ب) سپس هر دو سرویس مشتق شدهی از یک اینترفیس را به صورت معمولی ثبت میکنیم:
اینکار سبب خواهد شد تا بتوانیم در حین بررسی شرطهای رسیده، برای مثال دستور ()<serviceProvider.GetService<EmailService را صادر کنیم.
ج) اکنون میتوان مرحلهی شرطی کردن بازگشت این وهلهها را به صورت زیر، با دخالت در مراحل وهله سازی اشیاء، پیاده سازی کرد:
در اینجا پارامتر ارسالی به متد AddTransient را از نوع <Func<MessageServiceType, IMessageService انتخاب کردهایم. این مورد نیز دقیقا مانند «مثال 2: وهله سازی در صورت نیاز وابستگیهای یک سرویس به کمک Lazy loading» قسمت قبل عمل میکند. یعنی تا زمانیکه این Func، در قسمتی از کدهای برنامه فراخوانی نشود، سرویسی را نیز بازگشت نخواهد داد.
د) مرحلهی آخر کار، روش استفادهی از این امضایء ویژهی Lazy load شدهاست:
دقیقا همان امضای Func ای را که در متد AddTransient معرفی تنظیمات تزریق وابستگیها تعریف کردیم، به سازندهی یک کنترلر تزریق میکنیم. تا اینجای کار هنوز هیچکدام از سرویسهای از نوع IMessageService وهله سازی نشدهاند (روش دیگر پیاده سازی وهله سازی با تاخیر و در صورت نیاز). اکنون برای وهله سازی آنها باید به صورت زیر عمل کرد:
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: CoreDependencyInjectionSamples-07.zip
ثبت پیاده سازیهای متعدد یک اینترفیس در سیستم تزریق وابستگیهای NET Core.
داشتن چندین پیاده سازی از یک اینترفیس، شاید یکی از اهداف اصلی وجود آنها باشد. برای نمونه قرار داد ارسال پیامی را در برنامه، مانند IMessageService به صورت زیر طراحی و سپس بر اساس آن، دو پیاده سازی ارسال پیامها را از طریق ایمیل و SMS، اضافه میکنیم:
namespace CoreIocServices { public interface IMessageService { void Send(string message); } public class EmailService : IMessageService { public void Send(string message) { // ... } } public class SmsService : IMessageService { public void Send(string message) { //todo: ... } } }
namespace CoreIocSample02 { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddTransient<IMessageService, EmailService>(); services.AddTransient<IMessageService, SmsService>(); }
using CoreIocServices; using Microsoft.AspNetCore.Mvc; namespace CoreIocSample02.Controllers { public class MessagesController : Controller { private readonly IMessageService _emailService; private readonly IMessageService _smsService; public MessagesController(IMessageService emailService, IMessageService smsService) { _emailService = emailService; _smsService = smsService; } } }
همانطور که مشاهده میکنید، هر دو پارامتر، با وهلهای از آخرین سرویس معرفی شدهی از نوع IMessageService مقدار دهی شدهاند؛ یعنی SmsService در اینجا. در ادامه روشهای مختلفی را برای رفع این مشکل بررسی میکنیم.
روش اول: سیستم تزریق وابستگیهای NET Core. از سازندههای IEnumerable پشتیبانی میکند
برای مدیریت دریافت سرویسهایی که از یک اینترفیس مشتق شدهاند، خود NET Core. بدون نیاز به تنظیمات اضافهتری، روش تزریق IEnumerableها را در سازندههای کلاسها پشتیبانی میکند:
using System.Collections.Generic; using CoreIocServices; using Microsoft.AspNetCore.Mvc; namespace CoreIocSample02.Controllers { public class MessagesController : Controller { private readonly IEnumerable<IMessageService> _messageServices; public MessagesController(IEnumerable<IMessageService> messageServices) { _messageServices = messageServices; }
به این ترتیب لیست وهلههای تمام سرویسهایی از نوع IMessageService در اختیار ما قرار گرفتهاست و برای اهدافی مانند پیاده سازی الگوهایی در ردهی chain of responsibility و یا الگوی استراتژی، مفید است. در این حالت اگر نیاز به سرویس از نوع خاصی وجود داشت، میتوان از روش زیر استفاده کرد:
var emailService = _messageServices.OfType<EmailService>().First();
var messageServices = serviceProvider.GetServices<IMessageService>();
روش دوم: دریافت شرطی وهلههای مورد نیاز با «دخالت در مراحل وهله سازی اشیاء توسط IoC Container»
روش «دخالت در مراحل وهله سازی اشیاء توسط IoC Container» را در قسمت قبل بررسی کردیم. یکی دیگر از مثالهایی را که در این مورد میتوان ارائه داد، شرطی کردن بازگشت وهلهها است که برای سناریوی مطلب جاری بسیار مفید است:
الف) برای شرطی کردن بازگشت وهلهها، بهتر است این شرط را بجای رشتهها و یا اعدادی خاص، بر اساس یک enum مشخص انجام دهیم:
namespace CoreIocServices { public enum MessageServiceType { EmailService, SmsService }
ب) سپس هر دو سرویس مشتق شدهی از یک اینترفیس را به صورت معمولی ثبت میکنیم:
namespace CoreIocSample02 { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddTransient<EmailService>(); services.AddTransient<SmsService>();
ج) اکنون میتوان مرحلهی شرطی کردن بازگشت این وهلهها را به صورت زیر، با دخالت در مراحل وهله سازی اشیاء، پیاده سازی کرد:
namespace CoreIocSample02 { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddTransient<EmailService>(); services.AddTransient<SmsService>(); services.AddTransient<Func<MessageServiceType, IMessageService>>(serviceProvider => key => { switch (key) { case MessageServiceType.EmailService: return serviceProvider.GetRequiredService<EmailService>(); case MessageServiceType.SmsService: return serviceProvider.GetRequiredService<SmsService>(); default: throw new NotImplementedException($"Service of type {key} is not implemented."); } });
د) مرحلهی آخر کار، روش استفادهی از این امضایء ویژهی Lazy load شدهاست:
namespace CoreIocSample02.Controllers { public class MessagesController : Controller { private readonly Func<MessageServiceType, IMessageService> _messageServiceResolver; public MessagesController(Func<MessageServiceType, IMessageService> messageServiceResolver) { _messageServiceResolver = messageServiceResolver; }
public IActionResult Index() { var emailService = _messageServiceResolver(MessageServiceType.EmailService); //use emailService ... return View(); }
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: CoreDependencyInjectionSamples-07.zip