نحوه استفاده صحیح از لوسین در ASP.NET
یک نکتهی تکمیلی: روش نمایش خودکار آرگومانهای نامدار در Rider
اگر از Rider استفاده میکنید و علاقمندید تا خودش کار تکمیل و نمایش آرگومانهای نامدار را انجام دهد، روش کار به صورت زیر است:
الف) ویژگی فرمت کردن کدها را در حالت ذخیره سازی تغییرات، فعال کنید:
با اینکار، هربار که تغییرات را ذخیره میکنید، تنظیمات کدنویسی، به صورت خودکار به فایلهای ذخیره نشده، اعمال میشوند.
ب) به قسمت Settings -> Editor -> Cody Style -> C# -> Syntax Style مراجعه کرده و در قسمت تنظیمات آرگومانها، حداقل گزینههای Literal values و String literal values را بر روی named argumets قرار دهید تا نکات مطلب جاری، به صورت خودکار اعمال شوند:
همانطور که در مثال before/after تصویر فوق هم مشخص است، مزیت اینکار، مفهوم پیدا کردن اعداد و رشتههای وارد شده به عنوان آرگومانهای متدها هستند.
معرفی Bit Platform
وب اسمبلی چیست؟
<BlazorMode> ... </BlazorMode> <WebAppDeploymentType> ... </WebAppDeploymentType>
- وجود سیستم Exception handling در سرور و کلاینت (این موضوع به گونه ای بر اساس Best Practiceها پیاده سازی شده که اپلیکیشن را از بروز هر خطایی که بخواهد موجب Crash کردن برنامه شود ایزوله کرده)
- وجود سیستم User Authentication بر اساس JWT که شما در همان ابتدا که از این تمپلیت پروژه جدیدی میسازید صفحات SignIn ، SignUp را خواهید داشت.
- پکیج Bit Blazor UI که بالاتر درمورد آن صحبت کرده ایم از همان ابتدا در TodoTemplate نصب و تنظیم شده تا بتوانید به راحتی صفحات جدید با استفاده از آن بسازید.
- کانفیگ استاندارد Swagger در سمت سرور.
- ارسال ایمیل در روند SignUp.
- وجود خاصیت AutoInject برای سادهسازی تزریق وابستگی ها.
- و بسیاری موراد دیگر که در داکیومنتهای پروژه میتوانید آنهارا ببینید.
- شما میتوانید این پروژه را در گیتهاب مشاهده کنید.
- برای اشکالات یا قابلیت هایی که میخواهید برطرف شود Issue ثبت کنید.
- پروژه را Fork کنید و Star دهید.
- ایشوهایی که وجود دارد را برطرف کنید و Pull Request ارسال کنید.
- برای در جریان بودن از روند توسعه در جلسات برنامه ریزی (Planning Meeting) و گزارشات هفتگی (Standup Meeting ) که همه اینها در Microsoft Teams برگزار میشود شرکت کنید.
نسخه جدید برنامه Eazfuscator به همراه دو قابلیت جالب یکی کردن و همچنین مدفون نمودن اسمبلیها ارائه شده است:
یکی کردن چند اسمبلی با هم
Eazfuscator برای یکی کردن اسمبلیها از برنامه معروف ILmerge استفاده میکند با این تفاوت که دیگر نیازی نیست تا پارامترهای آنرا تنظیم کرد و بسیاری از مسایل را به صورت خودکار مدیریت میکند.
جهت فعال کردن این قابلیت، یکی از روشهای کار به صورت زیر است:
فایلی به نام ObfuscationSettings.cs را به پروژه خود اضافه کرده، سپس محتویات آنرا حذف نموده و با چند سطر زیر جایگزین و کامپایل کنید:
using System;
using System.Reflection;
[assembly: Obfuscation(Feature = "merge with file1.dll", Exclude = false)]
[assembly: Obfuscation(Feature = "merge with file2.dll", Exclude = false)]
[assembly: Obfuscation(Feature = "merge with file3.dll", Exclude = false)]
همانطور که ملاحظه میکنید این چند سطر حاوی نام اسمبلیهایی میباشند که قرار است با اسمبلی جاری یکی شوند.
سپس اسمبلی جاری را (میخواهد فایل exe باشد یا یک dll ، فرقی نمیکند) بر روی Eazfuscator کشیده و رها کنید. پس از چند لحظه اسمبلی نهایی تولید شده شامل تمام کلاسها و منابع اسمبلیهایی خواهد بود که در فایل ObfuscationSettings.cs ذکر شدهاند؛ به همراه Obfuscation خودکار آنها.
مدفون کردن اسمبلیها در یک اسمبلی
قابلیت دیگر این برنامه دفن (embedding) چند اسمبلی در اسمبلی نهایی است. برای فعال سازی آن روش کار همانند قبل است با این تفاوت که بجای merge with باید نوشت embed . برای مثال:
[assembly: Obfuscation(Feature = "embed Common.dll", Exclude = false)]
به این ترتیب اسمبلیهای ذکر شده پس از رمزنگاری و فشرده شدن به صورت منابع اسمبلی جاری ذخیره خواهند شد. مدیریت استفاده از آنها هم خودکار است و نیازی نیست تا کاری در این مورد صورت گیرد.
برای نمونه برنامه معروف LINQPad از همین روش استفاده میکند و لازم به ذکر است که ... هنوز که هنوز است هیچ ک.ر.ک. کارسازی برای فعال سازی قسمت intellisense آن که رایگان نیست ارائه نشده و تمام وصلههای جدید ارائه شده کار نمیکنند ...
تفاوت مدفون کردن با یکی کردن چیست؟
در حالت یکی کردن اسمبلیها، سربار اولیه بارگذاری برنامه همانند روش مدفون سازی وجود ندارد. اما این سربار آنقدر ناچیز است که کسی آنرا احساس نخواهد کرد. مورد دیگر، عدم پشتیبانی از روش مدفون سازی در سایر سکوهای کاری مانند ویندوز فون، Compact Framework و غیره است. اما باید درنظر داشت که برای مثال ILMerge روی اسمبلیهای دارای XAML کار نمیکند (مطابق مستندات رسمی آن). بنابراین همیشه نمیتوان از روش یکی سازی استفاده کرد و محدودیتهای خاص خودش را دارد.
در کل روش مدفون سازی به دلیل Obfuscation ، فشرده سازی و رمزنگاری همزمان، امنیت بیشتری را نسبت به حالت Obfuscation تنها ارائه میدهد (حداقل شخص "علاقمند" به مطالعه این نوع اسمبلیها باید از چند لایه رد شود و تجربه برنامه LINQPad ثابت کرده که این روش در مقیاس کلان (در انظار عمومی هزاران علاقمند) بسیار موفق بوده است).
راهنمای نظم بخشیدن به کدهای CSS
یک مثال: نمونهای از نحوهی تعریف و استفادهی از File Scoped Types
فرض کنید دو فایل جدید را به نامهای File1.cs و File2.cs به پروژهی جاری اضافه کردهایم.
محتوای فایل File1.cs به صورت زیر است:
namespace CS11Tests; file static class Post { public static string GetTitle() => "Title from File1.cs"; } internal static class InternalClassFromFile1 { public static string GetTitle() => Post.GetTitle(); }
namespace CS11Tests; file static class Post { public static string GetTitle() => "Title from File2.cs"; } internal static class InternalClassFromFile2 { public static string GetTitle() => Post.GetTitle(); }
using System.Security.AccessControl; using CS11Tests; using static System.Console; WriteLine(InternalClassFromFile1.GetTitle()); WriteLine(InternalClassFromFile2.GetTitle());
امکان partial تعریف کردن نوعهای محدود به یک فایل در C# 11
در اینجا میتوان نوعهای محدود به یک فایل را partial نیز تعریف کرد؛ به شرطی که تمام تعاریف آنها داخل همان فایل قرار گیرند:
namespace CS11Tests; file static partial class Post { internal static string GetFileScopeTitle() => "Title from File3.cs"; } file static partial class Post { internal static string AnotherGetFileScopeTitle() => "Another Title from File3.cs"; }
یک سؤال: اگر در یک فایل، file class Post و در فایلی دیگر، کلاس هم نام داخلی internal class Post را تعریف کردیم، آیا میتوان از نمونهی همنام internal، در کلاس file دار استفاده کرد؟
پاسخ: خیر!
فرض کنید در File4.cs چنین تعریفی را داریم:
namespace CS11Tests; internal static class Post { public static string GetTitle() => "Title from File4.cs"; }
namespace CS11Tests; file static class Post { internal static string GetFileScopeTitle() => CS11Tests.Post.GetTitle() + "Title from File3.cs"; }
خروجی کامپایلر C# 11 در مورد سطح دسترسی file
<SourceFileNameWithoutExtension>F$index$_TypeName
internal static class <File1>F3A5590C89B71B2DB20A548228781187A11D076C0CC91E851A4EE796FFE808F8F__Post { public static string GetTitle() { return "Title from File1.cs"; } }
- جهت کدهای تولیدی توسط ابزارها: گاهی از اوقات، تولید کنندههای کد، از یک نام مشخص مانند DataSet، بارها و بارها استفاده میکنند. برای جلوگیری از تداخل اینها، عموما از تعریف تو در توی کلاسها استفاده میشود و یا نام آنها را با ایندکسهایی مانند DateSet1، DateSet2 و امثال آنها مشخص میکنند. وجود واژهی کلیدی file، کار ابزارهای تولید کنندهی کد را سادهتر میکند.
- برای ساده سازی تعریف متدهای الحاقی: با استفاده از سطح دسترسی فایل میتوان از تداخل متدهای الحاقی هم نام و همچنین شلوغ شدن intellisense جلوگیری کرد. به این ترتیب میتوان کلاسهای حاوی Extension method مختص به یک فایل را ایجاد کرد که در سایر قسمتهای برنامه قابل دسترسی نباشند.
- کاهش تعریف کلاسهای تو در تو: همانطور که عنوان شد، یکی از روشهای مقابلهی با مشکل تعریف کلاسهای هم نام در یک فضای نام مشخص، تعریف nested classes است. با ارائهی واژهی کلیدی file، میتوان یک سطح فرو رفتگی تعریف کلاسها را کاهش داد و به کدهای تمیزتری رسید.
- امکان کپسوله سازیهای بهتر: عموما کامپوننتها و ماژولها، از چند کلاس تشکیل میشوند. با وجود واژهی کلیدی file، میتوان به سطح بالاتری از خصوصی سازی نوعها، بدون نیاز به تعریف نوعهای private و یا nested private رسید.
- سهولت نوشتن کلاسهای آزمونهای واحد: عموما هر کلاس آزمون، از نوعها و دادههای خاص خودش استفاده میکنند و در اینجا میتوان سطح دسترسی این تعاریف را بسیار محدود و مختص به همان فایل Test کرد.
افزونهی AOP جدید برای StructureMap
there’s the long awaited StructureMap.AutoFactory library that adds the “auto factory” feature to StructureMap that many folks that came from Windsor had requested over the years. Check out the documentation for the library on the StructureMap website.