خیر. شیء this.User با اطلاعات جدول کاربران، تناظر یک به یک ندارد. از نگارشهای پیشین ASP.NET ، هنوز هم اطلاعات شیء User مانند
User.Identity.Name در ASP.NET Core نیز در دسترس هستند. به این ترتیب
زمانیکه کاربری به سیستم وارد شد، دیگر نیازی نیست تا جهت یافتن Name او،
از بانک اطلاعاتی کوئری گرفت. خاصیت Name یاد شده به صورت خودکار از کوکی
رمزنگاری شدهی و یا در اینجا از توکن او دریافت شده و در اختیار برنامه قرار میگیرد. این Name
در ASP.NET Core Identity، اصطلاحا یک User Claim پیشفرض نام دارد و به
صورت خودکار ایجاد و مقدار دهی میشود. روش مقدار دهی اولیهی آن هم در متد createAccessTokenAsync مشخص است. هر زمانیکه این توکن به سمت سرور ارسال میشود، پس از اعتبارسنجی توکن و پذیرش آن، این Claims هم پردازش شده و جزئی از اطلاعات شیء this.User میشوند.
در نگارشهای اول MVC، موتور View پردازش کنندهی صفحات aspx هم ارائه شده بود. این حذف در مطلب جاری، به همین مورد بر میگردد و تنها باقی نگه داشتن موتور razor ( برای مثال در تصویر سوم، به دنبال فایلهای aspx هم میگردد که اضافی است). در ASP.NET Core اساسا موتور رسمی برای پردازش صفحات aspx ارائه نشده. بنابراین نیازی به مطلب فوق نیست.
مطالب
Roslyn #4
بررسی API کامپایل Roslyn
Compilation API، یک abstraction سطح بالا از فعالیتهای کامپایل Roslyn است. برای مثال در اینجا میتوان یک اسمبلی را از Syntax tree موجود، تولید کرد و یا جایگزینهایی را برای APIهای قدیمی CodeDOM و Reflection Emit ارائه داد. به علاوه این API امکان دسترسی به گزارشات خطاهای کامپایل را میسر میکند؛ به همراه دسترسی به اطلاعات Semantic analysis. در مورد تفاوت Syntax tree و Semantics در قسمت قبل بیشتر بحث شد.
با ارائهی Roslyn، اینبار کامپایلرهای خط فرمان تولید شده مانند csc.exe، صرفا یک پوسته بر فراز Compilation API آن هستند. بنابراین دیگر نیازی به فراخوانی Process.Start بر روی فایل اجرایی csc.exe مانند یک سری کتابخانههای قدیمی نیست. در اینجا با کدنویسی، به تمام اجزاء و تنظیمات کامپایلر، دسترسی وجود دارد.
کامپایل پویای کد توسط Roslyn
برای کار با API کامپایل، سورس کد، به صورت یک رشته در اختیار کامپایلر قرار میگیرد؛ به همراه تنظیمات ارجاعاتی به اسمبلیهایی که نیاز دارد. سپس کار کامپایلر شروع خواهد شد و شامل مواردی است مانند تبدیل متن دریافتی به Syntax tree و همچنین تبدیل مواردی که اصطلاحا به آنها Syntax sugars گفته میشود مانند خواص get و set دار به معادلهای اصلی آنها. در اینجا کار Semantic analysis هم انجام میشود و شامل تشخیص حوزهی دید متغیرها، تشخیص overloadها و بررسی نوعهای بکار رفتهاست. در نهایت کار تولید فایل باینری اسمبلی، از اطلاعات آنالیز شده صورت میگیرد. البته خروجی کامپایلر میتواند اسمبلیهای exe یا dll، فایل XML مستندات اسمبلی و یا فایلهای .netmudule و .winmdobj مخصوص WinRT هم باشد.
در ادامه، اولین مثال کار با Compilation API را مشاهده میکنید. پیشنیاز اجرای آن همان مواردی هستند که در قسمت قبل بحث شدند. یک برنامهی کنسول سادهی .NET 4.6 را آغاز کرده و سپس بستهی نیوگت Microsoft.CodeAnalysis را در آن نصب کنید. در ادامه کدهای ذیل را به پروژهی آماده شده اضافه کنید:
در اینجا نحوهی کامپایل پویای یک قطعه کد متنی سیشارپ را به DLL معادل آن مشاهده میکنید. مرحلهی اول اینکار، تولید Syntax tree از رشتهی متنی دریافتی است. سپس متد CSharpCompilation.Create یک وهله از Compilation API مخصوص #C را آغاز میکند. این API به صورت Fluent طراحی شدهاست و میتوان سایر قسمتهای آنرا به همراه یک دات پس از ذکر متد، به طول زنجیرهی فراخوانی، اضافه کرد. برای نمونه در این مثال، نحوهی افزودن ارجاعی را به اسمبلی mscorlib که System.Object در آن قرار دارد و همچنین ذکر نوع خروجی DLL یا DynamicallyLinkedLibrary را ملاحظه میکنید. اگر این تنظیم ذکر نشود، خروجی پیش فرض از نوع .exe خواهد بود و اگر mscorlib را اضافه نکنیم، نوع int سورس کد ورودی، شناسایی نشده و برنامه کامپایل نمیشود.
متدهای تعریف شده توسط Compilation API به یک s جمع، ختم میشوند؛ به این معنا که در اینجا در صورت نیاز، چندین Syntax tree یا ارجاع را میتوان تعریف کرد.
پس از وهله سازی Compilation API و تنظیم آن، اکنون با فراخوانی متد Emit، کار تولید فایل اسمبلی نهایی صورت میگیرد. در اینجا اگر خطایی وجود داشته باشد، استثنایی را دریافت نخواهید کرد. بلکه باید خاصیت Success نتیجهی آنرا بررسی کرده و درصورت موفقیت آمیز نبودن عملیات، خطاهای دریافتی را از مجموعهی Diagnostics آن دریافت کرد. کلاس Diagnostic، شامل اطلاعاتی مانند محل سطر و ستون وقوع مشکل و یا پیام متناظر با آن است.
معرفی مقدمات Semantic analysis
Compilation API به اطلاعات Semantics نیز دسترسی دارد. برای مثال آیا Type A قابل تبدیل به Type B هست یا اصلا نیازی به تبدیل ندارد و به صورت مستقیم قابل انتساب هستند؟ برای درک بهتر این مفهوم نیاز است یک مثال را بررسی کنیم:
تا سطر CSharpCompilation.Create این مثال، مانند قبل است و تا اینجا به Compilation API دسترسی پیدا کردهایم. پس از آن میخواهیم یک Semantic analysis مقدماتی را انجام دهیم. برای این منظور میتوان از متد ClassifyConversion استفاده کرد. این متد یک نوع مبداء و یک نوع مقصد را دریافت میکند و بر اساس اطلاعاتی که از Compilation API بدست میآورد، میتواند مشخص کند که برای مثال آیا نوع کلاس Foo قابل تبدیل به DateTime هست یا خیر و اگر هست چه نوع تبدیلی را نیاز دارد؟
برای مثال نتیجهی بررسی آخرین تبدیل انجام شده در تصویر فوق مشخص است. با توجه به تعریف public static explicit operator DateTime در سورس کد مورد آنالیز، این تبدیل explicit بوده و همچنین user defined. به علاوه متدی هم که این تبدیل را انجام میدهد، مشخص کردهاست.
Compilation API، یک abstraction سطح بالا از فعالیتهای کامپایل Roslyn است. برای مثال در اینجا میتوان یک اسمبلی را از Syntax tree موجود، تولید کرد و یا جایگزینهایی را برای APIهای قدیمی CodeDOM و Reflection Emit ارائه داد. به علاوه این API امکان دسترسی به گزارشات خطاهای کامپایل را میسر میکند؛ به همراه دسترسی به اطلاعات Semantic analysis. در مورد تفاوت Syntax tree و Semantics در قسمت قبل بیشتر بحث شد.
با ارائهی Roslyn، اینبار کامپایلرهای خط فرمان تولید شده مانند csc.exe، صرفا یک پوسته بر فراز Compilation API آن هستند. بنابراین دیگر نیازی به فراخوانی Process.Start بر روی فایل اجرایی csc.exe مانند یک سری کتابخانههای قدیمی نیست. در اینجا با کدنویسی، به تمام اجزاء و تنظیمات کامپایلر، دسترسی وجود دارد.
کامپایل پویای کد توسط Roslyn
برای کار با API کامپایل، سورس کد، به صورت یک رشته در اختیار کامپایلر قرار میگیرد؛ به همراه تنظیمات ارجاعاتی به اسمبلیهایی که نیاز دارد. سپس کار کامپایلر شروع خواهد شد و شامل مواردی است مانند تبدیل متن دریافتی به Syntax tree و همچنین تبدیل مواردی که اصطلاحا به آنها Syntax sugars گفته میشود مانند خواص get و set دار به معادلهای اصلی آنها. در اینجا کار Semantic analysis هم انجام میشود و شامل تشخیص حوزهی دید متغیرها، تشخیص overloadها و بررسی نوعهای بکار رفتهاست. در نهایت کار تولید فایل باینری اسمبلی، از اطلاعات آنالیز شده صورت میگیرد. البته خروجی کامپایلر میتواند اسمبلیهای exe یا dll، فایل XML مستندات اسمبلی و یا فایلهای .netmudule و .winmdobj مخصوص WinRT هم باشد.
در ادامه، اولین مثال کار با Compilation API را مشاهده میکنید. پیشنیاز اجرای آن همان مواردی هستند که در قسمت قبل بحث شدند. یک برنامهی کنسول سادهی .NET 4.6 را آغاز کرده و سپس بستهی نیوگت Microsoft.CodeAnalysis را در آن نصب کنید. در ادامه کدهای ذیل را به پروژهی آماده شده اضافه کنید:
static void firstCompilation() { var tree = CSharpSyntaxTree.ParseText("class Foo { void Bar(int x) {} }"); var mscorlibReference = MetadataReference.CreateFromFile(typeof (object).Assembly.Location); var compilationOptions = new CSharpCompilationOptions(OutputKind.DynamicallyLinkedLibrary); var comp = CSharpCompilation.Create("Demo") .AddSyntaxTrees(tree) .AddReferences(mscorlibReference) .WithOptions(compilationOptions); var res = comp.Emit("Demo.dll"); if (!res.Success) { foreach (var diagnostic in res.Diagnostics) { Console.WriteLine(diagnostic.GetMessage()); } } }
متدهای تعریف شده توسط Compilation API به یک s جمع، ختم میشوند؛ به این معنا که در اینجا در صورت نیاز، چندین Syntax tree یا ارجاع را میتوان تعریف کرد.
پس از وهله سازی Compilation API و تنظیم آن، اکنون با فراخوانی متد Emit، کار تولید فایل اسمبلی نهایی صورت میگیرد. در اینجا اگر خطایی وجود داشته باشد، استثنایی را دریافت نخواهید کرد. بلکه باید خاصیت Success نتیجهی آنرا بررسی کرده و درصورت موفقیت آمیز نبودن عملیات، خطاهای دریافتی را از مجموعهی Diagnostics آن دریافت کرد. کلاس Diagnostic، شامل اطلاعاتی مانند محل سطر و ستون وقوع مشکل و یا پیام متناظر با آن است.
معرفی مقدمات Semantic analysis
Compilation API به اطلاعات Semantics نیز دسترسی دارد. برای مثال آیا Type A قابل تبدیل به Type B هست یا اصلا نیازی به تبدیل ندارد و به صورت مستقیم قابل انتساب هستند؟ برای درک بهتر این مفهوم نیاز است یک مثال را بررسی کنیم:
static void semanticQuestions() { var tree = CSharpSyntaxTree.ParseText(@" using System; class Foo { public static explicit operator DateTime(Foo f) { throw new NotImplementedException(); } void Bar(int x) { } }"); var mscorlib = MetadataReference.CreateFromFile(typeof (object).Assembly.Location); var options = new CSharpCompilationOptions(OutputKind.DynamicallyLinkedLibrary); var comp = CSharpCompilation.Create("Demo").AddSyntaxTrees(tree).AddReferences(mscorlib).WithOptions(options); // var res = comp.Emit("Demo.dll"); // boxing var conv1 = comp.ClassifyConversion( comp.GetSpecialType(SpecialType.System_Int32), comp.GetSpecialType(SpecialType.System_Object) ); // unboxing var conv2 = comp.ClassifyConversion( comp.GetSpecialType(SpecialType.System_Object), comp.GetSpecialType(SpecialType.System_Int32) ); // explicit reference conversion var conv3 = comp.ClassifyConversion( comp.GetSpecialType(SpecialType.System_Object), comp.GetTypeByMetadataName("Foo") ); // explicit user-supplied conversion var conv4 = comp.ClassifyConversion( comp.GetTypeByMetadataName("Foo"), comp.GetSpecialType(SpecialType.System_DateTime) ); }
برای مثال نتیجهی بررسی آخرین تبدیل انجام شده در تصویر فوق مشخص است. با توجه به تعریف public static explicit operator DateTime در سورس کد مورد آنالیز، این تبدیل explicit بوده و همچنین user defined. به علاوه متدی هم که این تبدیل را انجام میدهد، مشخص کردهاست.
مطالب
Roslyn #7
معرفی Workspace API
Workspace، در حقیقت نمایش اجزای یک Solution در ویژوال استودیو است و یک Solution متشکل است از تعدادی پروژه به همراه وابستگیهای بین آنها. هدف از وجود Workspace API در Roslyn، دسترسی به اطلاعات لازم جهت انجام امور Refactoring در سطح یک Solution است. برای مثال اگر قرار است نام خاصیتی تغییر کند و این خاصیت در چندین پروژهی دیگر در حال استفاده است، این نام باید در سراسر Solution جاری یافت شده و تغییر یابد. همچنین برفراز Workspace API تعدادی سرویس زبان مانند فرمت کنندههای کدها، تغییرنام دهندههای سیمبلها و توصیه کنندهها نیز تهیه شدهاند.
همچنین این سرویسها و API تهیه شده، منحصر به ویژوال استودیو نیستند و VS 2015 تنها از آنها استفاده میکند. برای مثال نگارشهای جدیدتر mono-develop لینوکسی نیز شروع به استفادهی از Roslyn کردهاند.
نمایش اجزای یک Solution
در ادامه مثالی را مشاهده میکنید که توسط آن نام Solution و سپس تمام پروژههای موجود در آنها به همراه نام فایلهای مرتبط و همچنین ارجاعات آنها در صفحه نمایش داده میشوند:
در ابتدا نیاز است یک وهله از MSBuildWorkspace را ایجاد کرد. اکنون با استفاده از این Workspace میتوان solution خاصی را گشود و آنالیز کرد. قسمتی از خروجی آن چنین شکلی را دارد:
ایجاد یک Syntax highlighter با استفاده از Classification service
هدف از Classification service، رندر کردن فایلها در ادیتور جاری است. برای این منظور نیاز است بتوان واژههای کلیدی، کامنتها، نامهای نوعها و امثال آنها را به صورت کلاسه شده در اختیار داشت و سپس برای مثال هرکدام را با رنگی مجزا نمایش داد و رندر کرد.
در ادامه مثالی از آنرا ملاحظه میکنید:
با این خروجی:
توضیحات:
در اینجا نیز کار با ایجاد یک Workspace و سپس گشودن Solution ایی مشخص در آن آغاز میشود. سپس در آن به دنبال پروژهای به نام Roslyn04.Tests میگردیم. این پروژه حاوی تعدادی کلاس، جهت بررسی و آزمایش هستند. برای مثال در اینجا فایل Bar.cs آن قرار است آنالیز شود. پس از یافتن آن، ابتدا syntax tree آن دریافت میگردد و سپس به سرویس Classifier.GetClassifiedSpansAsync ارسال خواهد شد. خروجی آن شامل لیستی از Classified Spans است؛ مانند کلمات کلیدی، رشتهها، کامنتها و غیره. در ادامه این لیست تبدیل به یک دیکشنری میشود که کلید آن محل آغاز این span و مقدار آن، مقدار span است. سپس متن syntax tree دریافت شده و حرف به حرف آن در طی یک حلقه بررسی میشود. در این حلقه، مقدار i به محل حروف جاری مورد آنالیز اشاره میکند. اگر این محل در دیکشنری Classified Spans وجود داشت، یعنی یک span جدید شروع شدهاست و بر این اساس، نوع آن span را میتوان استخراج کرد و سپس بر اساس این نوع، رنگ متفاوتی را در صفحه نمایش داد.
سرویس فرمت کردن کدها
این سرویس کار فرمت خودکار کدهای بهم ریخته را انجام میدهد؛ مانند تنظیم فاصلههای خالی و یا ایجاد indentation و امثال آن. در حقیقت Ctlr K+D در ویژوال استودیو، دقیقا از همین سرویس زبان استفاده میکند.
کار کردن با این سرویس از طریق برنامه نویسی به نحو ذیل است:
با این خروجی:
همانطور که ملاحظه میکنید، فایل Qux.cs که فرمت مناسبی ندارد. بنابراین باز شده و syntax tree آن به سرویس Formatter.FormatAsync جهت فرمت شدن ارسال میشود.
سرویس یافتن سیمبلها
یکی دیگر از قابلیتهایی که در ویژوال استودیو وجود دارد، امکان یافتن سیمبلها است. برای مثال این نوع یا کلاس خاص، در کجاها استفاده شدهاست و به آن ارجاعاتی وجود دارد. مواردی مانند Find all references، Go to definition و نمایش Call hierarchy از این سرویس استفاده میکنند.
در این مثال، پروژهی Roslyn04.Tests که حاوی کلاسهای Foo و Qux است، جهت آنالیز باز شدهاست. در اینجا برای رسیدن به Symbols نیاز است ابتدا به Compilation API دسترسی یافت و سپس متادیتاها را بر اساس آن استخراج کرد. سپس متدهای Foo و خاصیت Qux آن یافت شدهاند.
اکنون با استفاده از سرویس SymbolFinder.FindCallersAsync تمام فراخوانهای متد Foo را در سراسر Solution جاری مییابیم.
سپس با استفاده از سرویس SymbolFinder.FindReferencesAsync تمام ارجاعات به خاصیت Qux را در Solution جاری نمایش میدهیم.
سرویس توصیه کننده
Intellisense در ویژوال استودیو از سرویس توصیه کنندهی Roslyn استفاده میکند.
در این مثال سعی شدهاست لیست توصیههای ارائه شده در حین تایپ دات، توسط سرویس Recommender.GetRecommendedSymbolsAtPosition دریافت و نمایش داده شوند. در ابتدای کار، کلاس Foo گشوده شده و سپس Syntax tree و Semantic model آن استخراج میشود. این model پارامتر اول متد سرویس توصیه کنندهاست. سپس نیاز است محل مکانی را به آن معرفی کنیم تا کار توصیه کردن را بر اساس آن شروع کند. برای نمونه در اینجا OperatorToken در حقیقت همان دات مربوط به Console.WriteLine است. پس از یافتن این توکن، امکان دسترسی به مکان آن وجود دارد.
تعدادی از خروجیهای مثال فوق به صورت زیر هستند:
سرویس تغییر نام دادن
هدف از سرویس Renamer.RenameSymbolAsync، تغییر نام یک identifier در کل Solution است. نمونهای از نحوهی کاربرد آنرا در مثال ذیل مشاهده میکنید:
در این مثال، متد Foo کلاس Bar، قرار است به Foo2 تغییرنام یابد. به همین منظور ابتدا پروژهی حاوی فایل Bar.cs باز شده و اطلاعات این کلاس استخراج میگردد. سپس اصل این کلاس تغییر نیافته نمایش داده میشود. در ادامه با استفاده از API کامپایل، به متادیتای متد Foo یا به عبارتی Symbol آن دسترسی پیدا میکنیم. سپس این Symbol به متد یا سرویس Renamer.RenameSymbolAsync ارسال میشود تا کار تغییر نام صورت گیرد. پس از اینکار مجددا متن کلاس تغییر یافته نمایش داده خواهد شد.
سرویس ساده کننده
هدف از سرویس ساده کننده، سادهکردن و کاهش کدهای ارائه شده، از دید Semantics است. برای مثال اگر فضای نامی در قسمت using ذکر شدهاست، دیگر نیازی نیست تا این فضای نام به ابتدای فراخوانی یک متد آن اضافه شود و میتوان این قطعه از کد را سادهتر کرد و کاهش داد.
در این مثال نحوهی ساده سازی castهای اضافی را ملاحظه میکنید. برای مثال اگر نوع متغیری int است، دیگر نیازی نیست در سراسر کد در کنار این متغیر، cast به int را هم ذکر کرد و میتوان این کد را سادهتر نمود.
کدهای کامل این سری را از اینجا میتوانید دریافت کنید:
Roslyn-Samples.zip
Workspace، در حقیقت نمایش اجزای یک Solution در ویژوال استودیو است و یک Solution متشکل است از تعدادی پروژه به همراه وابستگیهای بین آنها. هدف از وجود Workspace API در Roslyn، دسترسی به اطلاعات لازم جهت انجام امور Refactoring در سطح یک Solution است. برای مثال اگر قرار است نام خاصیتی تغییر کند و این خاصیت در چندین پروژهی دیگر در حال استفاده است، این نام باید در سراسر Solution جاری یافت شده و تغییر یابد. همچنین برفراز Workspace API تعدادی سرویس زبان مانند فرمت کنندههای کدها، تغییرنام دهندههای سیمبلها و توصیه کنندهها نیز تهیه شدهاند.
همچنین این سرویسها و API تهیه شده، منحصر به ویژوال استودیو نیستند و VS 2015 تنها از آنها استفاده میکند. برای مثال نگارشهای جدیدتر mono-develop لینوکسی نیز شروع به استفادهی از Roslyn کردهاند.
نمایش اجزای یک Solution
در ادامه مثالی را مشاهده میکنید که توسط آن نام Solution و سپس تمام پروژههای موجود در آنها به همراه نام فایلهای مرتبط و همچنین ارجاعات آنها در صفحه نمایش داده میشوند:
var ws = MSBuildWorkspace.Create(); var sln = ws.OpenSolutionAsync(@"..\..\..\Roslyn.sln").Result; // Print the root of the solution. Console.WriteLine(Path.GetFileName(sln.FilePath)); // Get dependency graph to perform a sort. var g = sln.GetProjectDependencyGraph(); var ps = g.GetTopologicallySortedProjects(); // Print all projects, their documents, and references. foreach (var p in ps) { var proj = sln.GetProject(p); Console.WriteLine("> " + proj.Name); Console.WriteLine(" > References"); foreach (var r in proj.ProjectReferences) { Console.WriteLine(" - " + sln.GetProject(r.ProjectId).Name); } foreach (var d in proj.Documents) { Console.WriteLine(" - " + d.Name); } }
Roslyn.sln > Roslyn01 > References - Program.cs - AssemblyInfo.cs - .NETFramework,Version=v4.6.AssemblyAttributes.cs
ایجاد یک Syntax highlighter با استفاده از Classification service
هدف از Classification service، رندر کردن فایلها در ادیتور جاری است. برای این منظور نیاز است بتوان واژههای کلیدی، کامنتها، نامهای نوعها و امثال آنها را به صورت کلاسه شده در اختیار داشت و سپس برای مثال هرکدام را با رنگی مجزا نمایش داد و رندر کرد.
در ادامه مثالی از آنرا ملاحظه میکنید:
var ws = MSBuildWorkspace.Create(); var sln = ws.OpenSolutionAsync(@"..\..\..\Roslyn.sln").Result; // Get the Tests\Bar.cs document. var proj = sln.Projects.Single(p => p.Name == "Roslyn04.Tests"); var test = proj.Documents.Single(d => d.Name == "Bar.cs"); var tree = test.GetSyntaxTreeAsync().Result; var root = tree.GetRootAsync().Result; // Get all the spans in the document that are classified as language elements. var spans = Classifier.GetClassifiedSpansAsync(test, root.FullSpan).Result.ToDictionary(c => c.TextSpan.Start, c => c); // Print the source text with appropriate colorization. var txt = tree.GetText().ToString(); var i = 0; foreach (var c in txt) { var span = default(ClassifiedSpan); if (spans.TryGetValue(i, out span)) { var color = ConsoleColor.Gray; switch (span.ClassificationType) { case ClassificationTypeNames.Keyword: color = ConsoleColor.Cyan; break; case ClassificationTypeNames.StringLiteral: case ClassificationTypeNames.VerbatimStringLiteral: color = ConsoleColor.Red; break; case ClassificationTypeNames.Comment: color = ConsoleColor.Green; break; case ClassificationTypeNames.ClassName: case ClassificationTypeNames.InterfaceName: case ClassificationTypeNames.StructName: case ClassificationTypeNames.EnumName: case ClassificationTypeNames.TypeParameterName: case ClassificationTypeNames.DelegateName: color = ConsoleColor.Yellow; break; case ClassificationTypeNames.Identifier: color = ConsoleColor.DarkGray; break; } Console.ForegroundColor = color; } Console.Write(c); i++; }
توضیحات:
در اینجا نیز کار با ایجاد یک Workspace و سپس گشودن Solution ایی مشخص در آن آغاز میشود. سپس در آن به دنبال پروژهای به نام Roslyn04.Tests میگردیم. این پروژه حاوی تعدادی کلاس، جهت بررسی و آزمایش هستند. برای مثال در اینجا فایل Bar.cs آن قرار است آنالیز شود. پس از یافتن آن، ابتدا syntax tree آن دریافت میگردد و سپس به سرویس Classifier.GetClassifiedSpansAsync ارسال خواهد شد. خروجی آن شامل لیستی از Classified Spans است؛ مانند کلمات کلیدی، رشتهها، کامنتها و غیره. در ادامه این لیست تبدیل به یک دیکشنری میشود که کلید آن محل آغاز این span و مقدار آن، مقدار span است. سپس متن syntax tree دریافت شده و حرف به حرف آن در طی یک حلقه بررسی میشود. در این حلقه، مقدار i به محل حروف جاری مورد آنالیز اشاره میکند. اگر این محل در دیکشنری Classified Spans وجود داشت، یعنی یک span جدید شروع شدهاست و بر این اساس، نوع آن span را میتوان استخراج کرد و سپس بر اساس این نوع، رنگ متفاوتی را در صفحه نمایش داد.
سرویس فرمت کردن کدها
این سرویس کار فرمت خودکار کدهای بهم ریخته را انجام میدهد؛ مانند تنظیم فاصلههای خالی و یا ایجاد indentation و امثال آن. در حقیقت Ctlr K+D در ویژوال استودیو، دقیقا از همین سرویس زبان استفاده میکند.
کار کردن با این سرویس از طریق برنامه نویسی به نحو ذیل است:
var ws = MSBuildWorkspace.Create(); var sln = ws.OpenSolutionAsync(@"..\..\..\Roslyn.sln").Result; // Get the Tests\Qux.cs document. var proj = sln.Projects.Single(p => p.Name == "Roslyn04.Tests"); var qux = proj.Documents.Single(d => d.Name == "Qux.cs"); Console.WriteLine("Before:"); Console.WriteLine(); Console.WriteLine(qux.GetSyntaxTreeAsync().Result.GetText()); Console.WriteLine(); Console.WriteLine(); // Apply formatting and print the result. var res = Formatter.FormatAsync(qux).Result; Console.WriteLine("After:"); Console.WriteLine(); Console.WriteLine(res.GetSyntaxTreeAsync().Result.GetText()); Console.WriteLine();
Before: using System; namespace Roslyn04.Tests { class Qux { public void Baz() { Console.WriteLine(42); return; } } } After: using System; namespace Roslyn04.Tests { class Qux { public void Baz() { Console.WriteLine(42); return; } } }
سرویس یافتن سیمبلها
یکی دیگر از قابلیتهایی که در ویژوال استودیو وجود دارد، امکان یافتن سیمبلها است. برای مثال این نوع یا کلاس خاص، در کجاها استفاده شدهاست و به آن ارجاعاتی وجود دارد. مواردی مانند Find all references، Go to definition و نمایش Call hierarchy از این سرویس استفاده میکنند.
var ws = MSBuildWorkspace.Create(); var sln = ws.OpenSolutionAsync(@"..\..\..\Roslyn.sln").Result; // Get the Tests project. var proj = sln.Projects.Single(p => p.Name == "Roslyn04.Tests"); // Locate the symbol for the Bar.Foo method and the Bar.Qux property. var comp = proj.GetCompilationAsync().Result; var barType = comp.GetTypeByMetadataName("Roslyn04.Tests.Bar"); var fooMethod = barType.GetMembers().Single(m => m.Name == "Foo"); var quxProp = barType.GetMembers().Single(m => m.Name == "Qux"); // Find callers across the solution. Console.WriteLine("Find callers of Foo"); Console.WriteLine(); var callers = SymbolFinder.FindCallersAsync(fooMethod, sln).Result; foreach (var caller in callers) { Console.WriteLine(caller.CallingSymbol); foreach (var location in caller.Locations) { Console.WriteLine(" " + location); } } Console.WriteLine(); Console.WriteLine(); // Find all references across the solution. Console.WriteLine("Find all references to Qux"); Console.WriteLine(); var references = SymbolFinder.FindReferencesAsync(quxProp, sln).Result; foreach (var reference in references) { Console.WriteLine(reference.Definition); foreach (var location in reference.Locations) { Console.WriteLine(" " + location.Location); } }
اکنون با استفاده از سرویس SymbolFinder.FindCallersAsync تمام فراخوانهای متد Foo را در سراسر Solution جاری مییابیم.
سپس با استفاده از سرویس SymbolFinder.FindReferencesAsync تمام ارجاعات به خاصیت Qux را در Solution جاری نمایش میدهیم.
سرویس توصیه کننده
Intellisense در ویژوال استودیو از سرویس توصیه کنندهی Roslyn استفاده میکند.
var ws = MSBuildWorkspace.Create(); var sln = ws.OpenSolutionAsync(@"..\..\..\Roslyn.sln").Result; // Get the Tests\Foo.cs document. var proj = sln.Projects.Single(p => p.Name == "Roslyn04.Tests"); var foo = proj.Documents.Single(d => d.Name == "Foo.cs"); // Find the 'dot' token in the first Console.WriteLine member access expression. var tree = foo.GetSyntaxTreeAsync().Result; var model = proj.GetCompilationAsync().Result.GetSemanticModel(tree); var consoleDot = tree.GetRoot().DescendantNodes().OfType<MemberAccessExpressionSyntax>().First().OperatorToken; // Get recommendations at the indicated cursor position. // // Console.WriteLine // ^ var res = Recommender.GetRecommendedSymbolsAtPosition( model, consoleDot.GetLocation().SourceSpan.Start + 1, ws).ToList(); foreach (var rec in res) { Console.WriteLine(rec); }
تعدادی از خروجیهای مثال فوق به صورت زیر هستند:
System.Console.Beep() System.Console.Beep(int, int) System.Console.Clear()
سرویس تغییر نام دادن
هدف از سرویس Renamer.RenameSymbolAsync، تغییر نام یک identifier در کل Solution است. نمونهای از نحوهی کاربرد آنرا در مثال ذیل مشاهده میکنید:
var ws = MSBuildWorkspace.Create(); var sln = ws.OpenSolutionAsync(@"..\..\..\Roslyn.sln").Result; // Get Tests\Bar.cs before making changes. var oldProj = sln.Projects.Single(p => p.Name == "Roslyn04.Tests"); var oldDoc = oldProj.Documents.Single(d => d.Name == "Bar.cs"); Console.WriteLine("Before:"); Console.WriteLine(); var oldTxt = oldDoc.GetTextAsync().Result; Console.WriteLine(oldTxt); Console.WriteLine(); Console.WriteLine(); // Get the symbol for the Bar.Foo method. var comp = oldProj.GetCompilationAsync().Result; var barType = comp.GetTypeByMetadataName("Roslyn04.Tests.Bar"); var fooMethod = barType.GetMembers().Single(m => m.Name == "Foo"); // Perform the rename. var newSln = Renamer.RenameSymbolAsync(sln, fooMethod, "Foo2", ws.Options).Result; // Get Tests\Bar.cs after making changes. var newProj = newSln.Projects.Single(p => p.Name == "Roslyn04.Tests"); var newDoc = newProj.Documents.Single(d => d.Name == "Bar.cs"); Console.WriteLine("After:"); Console.WriteLine(); var newTxt = newDoc.GetTextAsync().Result; Console.WriteLine(newTxt);
سرویس ساده کننده
هدف از سرویس ساده کننده، سادهکردن و کاهش کدهای ارائه شده، از دید Semantics است. برای مثال اگر فضای نامی در قسمت using ذکر شدهاست، دیگر نیازی نیست تا این فضای نام به ابتدای فراخوانی یک متد آن اضافه شود و میتوان این قطعه از کد را سادهتر کرد و کاهش داد.
var ws = MSBuildWorkspace.Create(); var sln = ws.OpenSolutionAsync(@"..\..\..\Roslyn.sln").Result; // Get the Tests\Baz.cs document. var proj = sln.Projects.Single(p => p.Name == "Roslyn04.Tests"); var baz = proj.Documents.Single(d => d.Name == "Baz.cs"); Console.WriteLine("Before:"); Console.WriteLine(); Console.WriteLine(baz.GetSyntaxTreeAsync().Result.GetText()); Console.WriteLine(); Console.WriteLine(); var oldRoot = baz.GetSyntaxRootAsync().Result; var memberAccesses = oldRoot.DescendantNodes().OfType<CastExpressionSyntax>(); var newRoot = oldRoot.ReplaceNodes(memberAccesses, (_, m) => m.WithAdditionalAnnotations(Simplifier.Annotation)); var newDoc = baz.WithSyntaxRoot(newRoot); // Invoke the simplifier and print the result. var res = Simplifier.ReduceAsync(newDoc).Result; Console.WriteLine("After:"); Console.WriteLine(); Console.WriteLine(res.GetSyntaxTreeAsync().Result.GetText()); Console.WriteLine();
کدهای کامل این سری را از اینجا میتوانید دریافت کنید:
Roslyn-Samples.zip
در مطلب «محدود کردن کاربرها به آپلود فایلهایی خاص در ASP.NET MVC» تصمیم گیری بر اساس یک لیست سفید صورت میگیرد. برای مثال کاربران فقط قرار است تصویرهایی از نوع png یا jpg را ارسال کنند. اکنون نیاز است حالت کلیتری را درنظر بگیریم که کاربر قرار است هر نوع فایل دلخواهی را ارسال کند. در اینجا نباید امکان آپلود هر نوع فایلی، خصوصا فایلهای اجرایی ASP.NET یا هر نوع موتور اجرایی دیگری که ممکن است روی سرور نصب باشد (مثلا PHP)، وجود داشته باشد. برای این منظور فیلتر دیگری به نام AllowUploadSafeFiles طراحی شده است که سورس آنرا در ذیل مشاهده میکنید:
در این فیلتر، یک سری پسوند خطرناک مانند aspx، asp و امثال آن فیلتر میشوند و اجازه آپلود نخواهند یافت. همچنین فایلهایی مانند web.config یا نام داسی آن معادل web~1.con نیز فرصت آپلود نخواهد یافت.
استفاده از این فیلتر سفارشی به نحو زیر است:
using System; using System.Linq; using System.Collections.Generic; using System.IO; using System.Web.Mvc; namespace SecurityModule { [AttributeUsage(AttributeTargets.Method, AllowMultiple = false)] public sealed class AllowUploadSafeFilesAttribute : ActionFilterAttribute { static readonly IList<string> ExtToFilter = new List<string> { ".aspx", ".asax", ".asp", ".ashx", ".asmx", ".axd", ".master", ".svc", ".php" , ".php3" , ".php4", ".ph3", ".ph4", ".php4", ".ph5", ".sphp", ".cfm", ".ps", ".stm", ".htaccess", ".htpasswd", ".php5", ".phtml", ".cgi", ".pl", ".plx", ".py", ".rb", ".sh", ".jsp", ".cshtml", ".vbhtml", ".swf" , ".xap", ".asptxt" }; static readonly IList<string> NameToFilter = new List<string> { "web.config" , "htaccess" , "htpasswd", "web~1.con" }; static bool canUpload(string fileName) { if (string.IsNullOrWhiteSpace(fileName)) return false; fileName = fileName.ToLowerInvariant(); var name = Path.GetFileName(fileName); var ext = Path.GetExtension(fileName); if (string.IsNullOrWhiteSpace(name)) throw new InvalidOperationException("Uploaded file should have a name."); return !ExtToFilter.Contains(ext) && !NameToFilter.Contains(name) && !NameToFilter.Contains(ext) && //for "file.asp;.jpg" files ExtToFilter.All(item => !name.Contains(item)); } public override void OnActionExecuting(ActionExecutingContext filterContext) { var files = filterContext.HttpContext.Request.Files; foreach (string file in files) { var postedFile = files[file]; if (postedFile == null || postedFile.ContentLength == 0) continue; if (!canUpload(postedFile.FileName)) throw new InvalidOperationException(string.Format("You are not allowed to upload {0} file.", Path.GetFileName(postedFile.FileName))); } base.OnActionExecuting(filterContext); } } }
استفاده از این فیلتر سفارشی به نحو زیر است:
[AllowUploadSafeFiles] public ActionResult UploadFile(HttpPostedFileBase file)
به C# 12 و داتنت 8، ویژگی «آزمایشی» جدیدی به نام Interceptors اضافه شدهاست که به آن «monkey patching» هم میگویند. هدف از آن، جایگزین کردن یک پیاده سازی، با پیاده سازی دیگری است. به این ترتیب توسعه دهندگان داتنتی میتوانند فراخوانی متدهایی خاص را رهگیری کرده (interception) و سپس آنرا به فراخوانی یک پیاده سازی جدید، هدایت کنند.
Interceptor چیست؟
از زمان ارائهی NET 8 preview 6 SDK. به بعد، امکان رهگیری هر متدی از کدهای برنامه، به داتنت اضافه شدهاست؛ به همین جهت از واژهی Interceptor/رهگیر در اینجا استفاده میشود. خود تیم داتنت از این قابلیت در جهت بازنویسی پویای قسمتهایی از کدهای زیرساخت داتنت که از Reflection استفاده میکنند، با نگارشهای کامپایل شدهی مختص به برنامهی شما، کمک میگیرند. به این ترتیب سرعت و کارآیی برنامههای داتنت 8، بهبود قابل ملاحظهای را پیدا کردهاند. برای مثال ahead-of-time compilation (AOT) در داتنت 8 و ASP.NET Core 8x بر اساس این ویژگی پیاده سازی شدهاست. این ویژگی جدید، مکمل source generators است که در نگارشهای پیشین داتنت ارائه شده بود.
بررسی Interceptors با تهیهی یک مثال ساده
فرض کنید میخواهیم فراخوانی متد GetText زیر را رهگیری کرده و سپس آنرا با نمونهی دیگری جایگزین کنیم:
برای اینکار ابتدا نیاز است یک فایل جدید را به نام InterceptsLocationAttribute.cs با محتوای زیر به پروژه اضافه کرد:
همانطور که در مقدمهی بحث هم عنوان شد، این ویژگی هنوز آزمایشی است و نهایی نشده و ویژگی فوق نیز هنوز به داتنت اضافه نشدهاست. به همین جهت فعلا باید آنرا به صورت دستی به پروژه اضافه کرد و احتمالا در نگارشهای بعدی داتنت، امضای آن تغییر خواهد کرد ... یا حتی ممکن است بطور کامل حذف شود!
سپس فرض کنید فراخوانی متد GetText در فایل Program.cs برنامه به صورت زیر انجام شدهاست:
یعنی متد GetText، در سطر چهارم و کاراکتر 20 ام آن فراخوانی شدهاست. این اعداد مهم هستند!
در ادامه از این اطلاعات در رهگیر سفارشی زیر استفاده خواهیم کرد:
این رهگیر که به صورت متدی الحاقی برای کلاس InterceptorsSample دربرگیرندهی متد GetText تهیه میشود، کار جایگزینی فراخوانی آنرا در سطر چهارم و کاراکتر 20 ام فایل Program.cs انجام میدهد. امضای پارامترهای این متد، باید با امضای پارامترهای متد رهگیری شده، یکی باشد.
اکنون اگر برنامه را اجرا کنیم ... با خطای زیر مواجه میشویم:
عنوان میکند که این ویژگی آزمایشی است و باید فایل csproj. را به صورت زیر تغییر داد تا بتوان از آن استفاده نمود:
اینبار برنامه کامپایل شده و اجرا میشود. در این حالت خروجی جدید برنامه، خروجی تامین شدهی توسط رهگیر سفارشی ما است:
سؤال: آیا رهگیری انجام شده، در زمان کامپایل انجام میشود یا در زمان اجرا؟
برای این مورد میتوان به Low-Level C# code تولیدی مراجعه کرد. برای مشاهدهی یک چنین کدهایی میتوانید از منوی Tools->IL Viewer برنامهی Rider استفاده کرده و در برگهی ظاهر شده، گزینهی Low-Level C# آنرا انتخاب نمائید:
همانطور که مشاهده میکنید، این رهگیری و جایگزینی، در زمان کامپایل انجام شده و کامپایلر، بهطور کامل نحوهی فراخوانی متد GetText اصلی را به متد رهگیر ما تغییر داده و بازنویسی کردهاست.
سؤال: آیا این قابلیت واقعا کاربردی است؟!
اکنون شاید این سؤال مطرح شود که ... واقعا چه کسی قرار است مسیر کامل یک فایل، شماره سطر و شماره ستون فراخوانی متدی را به اینگونه در اختیار سیستم رهگیری قرار دهد؟! آیا واقعا این قابلیت، یک قابلیت کاربردی و مناسب است؟!
اینجا است که اهمیت source generators مشخص میشود. توسط source generators دسترسی کاملی به syntax trees وجود دارد و همچنین یکسری اطلاعات تکمیلی مانند FilePath و سپس CSharpSyntaxNodeها که دسترسی به دادههای متد ()GetLocation را دارند که مکان دقیق سطر و ستونهای فراخوانیها را مشخص میکند.
کاربردهای فعلی رهگیرها در دات نت 8
در دات نت 8، این موارد با استفاده از رهگیرها بهینه سازی شده و سرعت آنها افزایش یافتهاند:
- فراخوانیهایی که تمام اطلاعات آنها در زمان کامپایل فراهم است، مانند Regex.IsMatch(@"a+b+") که از یک الگوی ثابت و مشخص استفاده میکند، رهگیری شده و پیاده سازی آن با کدی استاتیک، جایگزین میشود.
- در ASP.NET Minimal API، استفاده از lambda expressions جهت ارائهی تعاریفی مانند:
مرسوم است. این نوع فراخوانیها نیز توسط رهگیرها برای جایگزینی handler آنها با کدهای استاتیک، جهت بالابردن کارآیی و کاهش تخصیصهای حافظه انجام میشود.
- بهبود کارآیی foreach loops جهت استفاده از ریاضیات برداری و SIMD در صورت امکان.
- بهبود کارآیی تزریق وابستگیها، زمانیکه به تعاریف مشخصی مانند ()<provider.Register<MyService ختم میشود.
- بجای استفاده از expression trees در زمان اجرای برنامه، اکنون میتوان کدهای SQL معادل را در زمان کامپایل برنامه تولید کرد.
- بهبود کارآیی Serializers، زمانیکه از یک نوع مشخص مانند ()<Serialize<MyType استفاده میشود و کامپایلر میتواند آنرا با کدهای زمان کامپایل، جایگزین کند.
محدودیتهای رهگیرها در داتنت 8
- رهگیرهای داتنت 8 فقط با متدها کار میکنند.
- مسیر ارائه شده حتما باید یک مسیر کامل و مشخص باشد. یعنی اگر این قطعه کد، به سیستم دیگری منتقل شود، کامپایل نخواهد شد و امکان ارائهی مسیرهای نسبی وجود ندارد.
- امضای متدها، حتما باید یکی باشد. یعنی نمیتوان یک رهگیر جنریک را تعریف کرد.
Interceptor چیست؟
از زمان ارائهی NET 8 preview 6 SDK. به بعد، امکان رهگیری هر متدی از کدهای برنامه، به داتنت اضافه شدهاست؛ به همین جهت از واژهی Interceptor/رهگیر در اینجا استفاده میشود. خود تیم داتنت از این قابلیت در جهت بازنویسی پویای قسمتهایی از کدهای زیرساخت داتنت که از Reflection استفاده میکنند، با نگارشهای کامپایل شدهی مختص به برنامهی شما، کمک میگیرند. به این ترتیب سرعت و کارآیی برنامههای داتنت 8، بهبود قابل ملاحظهای را پیدا کردهاند. برای مثال ahead-of-time compilation (AOT) در داتنت 8 و ASP.NET Core 8x بر اساس این ویژگی پیاده سازی شدهاست. این ویژگی جدید، مکمل source generators است که در نگارشهای پیشین داتنت ارائه شده بود.
بررسی Interceptors با تهیهی یک مثال ساده
فرض کنید میخواهیم فراخوانی متد GetText زیر را رهگیری کرده و سپس آنرا با نمونهی دیگری جایگزین کنیم:
namespace CS8Tests; public class InterceptorsSample { public string GetText(string text) { return $"{text}, World!"; } }
namespace System.Runtime.CompilerServices; [AttributeUsage(AttributeTargets.Method, AllowMultiple = true, Inherited = false)] public sealed class InterceptsLocationAttribute : Attribute { public InterceptsLocationAttribute(string filePath, int line, int character) { } }
سپس فرض کنید فراخوانی متد GetText در فایل Program.cs برنامه به صورت زیر انجام شدهاست:
using CS8Tests; var example = new InterceptorsSample(); var text = example.GetText("Hello"); Console.WriteLine(text); //Hello, World!
در ادامه از این اطلاعات در رهگیر سفارشی زیر استفاده خواهیم کرد:
using System.Runtime.CompilerServices; namespace CS8Tests; public static class MyInterceptor { [InterceptsLocation("C:\\Path\\To\\CS8Tests\\Program.cs", 4, 20)] public static string InterceptorMethod(this InterceptorsSample example, string text) { return $"{text}, DNT!"; } }
اکنون اگر برنامه را اجرا کنیم ... با خطای زیر مواجه میشویم:
error CS9137: The 'interceptors' experimental feature is not enabled in this namespace. Add '<InterceptorsPreviewNamespaces>$(InterceptorsPreviewNamespaces);CS8Tests</InterceptorsPreviewNamespaces>' to your project.
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>net8.0</TargetFramework> <ImplicitUsings>enable</ImplicitUsings> <Nullable>enable</Nullable> <!--<NoWarn>Test001</NoWarn>--> <InterceptorsPreviewNamespaces>$(InterceptorsPreviewNamespaces);CS8Tests</InterceptorsPreviewNamespaces> </PropertyGroup> </Project>
Hello, DNT!
سؤال: آیا رهگیری انجام شده، در زمان کامپایل انجام میشود یا در زمان اجرا؟
برای این مورد میتوان به Low-Level C# code تولیدی مراجعه کرد. برای مشاهدهی یک چنین کدهایی میتوانید از منوی Tools->IL Viewer برنامهی Rider استفاده کرده و در برگهی ظاهر شده، گزینهی Low-Level C# آنرا انتخاب نمائید:
using CS8Tests; using System; using System.Runtime.CompilerServices; [CompilerGenerated] internal class Program { private static void <Main>$(string[] args) { Console.WriteLine(new InterceptorsSample().InterceptorMethod("Hello")); } public Program() { base..ctor(); } }
سؤال: آیا این قابلیت واقعا کاربردی است؟!
اکنون شاید این سؤال مطرح شود که ... واقعا چه کسی قرار است مسیر کامل یک فایل، شماره سطر و شماره ستون فراخوانی متدی را به اینگونه در اختیار سیستم رهگیری قرار دهد؟! آیا واقعا این قابلیت، یک قابلیت کاربردی و مناسب است؟!
اینجا است که اهمیت source generators مشخص میشود. توسط source generators دسترسی کاملی به syntax trees وجود دارد و همچنین یکسری اطلاعات تکمیلی مانند FilePath و سپس CSharpSyntaxNodeها که دسترسی به دادههای متد ()GetLocation را دارند که مکان دقیق سطر و ستونهای فراخوانیها را مشخص میکند.
کاربردهای فعلی رهگیرها در دات نت 8
در دات نت 8، این موارد با استفاده از رهگیرها بهینه سازی شده و سرعت آنها افزایش یافتهاند:
- فراخوانیهایی که تمام اطلاعات آنها در زمان کامپایل فراهم است، مانند Regex.IsMatch(@"a+b+") که از یک الگوی ثابت و مشخص استفاده میکند، رهگیری شده و پیاده سازی آن با کدی استاتیک، جایگزین میشود.
- در ASP.NET Minimal API، استفاده از lambda expressions جهت ارائهی تعاریفی مانند:
app.MapGet("/products", handler: (int? page, int? pageLength, MyDb db) => { ... })
- بهبود کارآیی foreach loops جهت استفاده از ریاضیات برداری و SIMD در صورت امکان.
- بهبود کارآیی تزریق وابستگیها، زمانیکه به تعاریف مشخصی مانند ()<provider.Register<MyService ختم میشود.
- بجای استفاده از expression trees در زمان اجرای برنامه، اکنون میتوان کدهای SQL معادل را در زمان کامپایل برنامه تولید کرد.
- بهبود کارآیی Serializers، زمانیکه از یک نوع مشخص مانند ()<Serialize<MyType استفاده میشود و کامپایلر میتواند آنرا با کدهای زمان کامپایل، جایگزین کند.
محدودیتهای رهگیرها در داتنت 8
- رهگیرهای داتنت 8 فقط با متدها کار میکنند.
- مسیر ارائه شده حتما باید یک مسیر کامل و مشخص باشد. یعنی اگر این قطعه کد، به سیستم دیگری منتقل شود، کامپایل نخواهد شد و امکان ارائهی مسیرهای نسبی وجود ندارد.
- امضای متدها، حتما باید یکی باشد. یعنی نمیتوان یک رهگیر جنریک را تعریف کرد.
مسیرراهها
React 16x
پیش نیاز ها
- قسمت 1 : معرفی و شروع به کار
- قسمت 2 : بررسی پیشنیازهای جاوا اسکریپتی - بخش 1
- قسمت 3 : بررسی پیشنیازهای جاوا اسکریپتی - بخش 2
کامپوننت ها
- قسمت 4 : کامپوننتها - بخش 1 - کار با عبارات JSX
- قسمت 5 : کامپوننتها - بخش 2 - نمایش لیستها و مدیریت رویدادها و حالات
- قسمت 6 : کامپوننتها - بخش 3 - یک تمرین
ترکیب کامپوننت ها
- قسمت 7 : ترکیب کامپوننتها - بخش 1 - ارسال دادهها، مدیریت رخدادها
- قسمت 8 : ترکیب کامپوننتها - بخش 2 - مدیریت state
- قسمت 9 : ترکیب کامپوننتها - بخش 3 - Lifecycle Hooks
- قسمت 10 : ترکیب کامپوننتها - بخش 4 - یک تمرین
طراحی یک گرید
- قسمت 11 : طراحی یک گرید - بخش 1 - کامپوننت صفحه بندی
- قسمت 12 : طراحی یک گرید - بخش 2 - فیلتر کردن اطلاعات
- قسمت 13 : طراحی یک گرید - بخش 3 - مرتب سازی اطلاعات
- قسمت 14: طراحی یک گرید - بخش 4 - پویاسازی تعاریف ستونها
مسیریابی
- قسمت 15 :مسیریابی - بخش 1 - تعریف و تنظیم مسیریابیها
- قسمت 16 : مسیریابی - بخش 2 - پارامترهای مسیریابی
- قسمت 17 : مسیریابی - بخش 3 - یک تمرین
کار با فرم ها
- قسمت 18 : کار با فرمها - بخش 1 - دریافت ورودیها از کاربر
- قسمت 19 : کار با فرمها - بخش 2 - اعتبارسنجی ورودیهای کاربران
- قسمت 20 : کار با فرمها - بخش 3 - بهبود کیفیت کدهای فرم لاگین
- قسمت 21 : کار با فرمها - بخش 4 - چند تمرین
ارتباط با سرور
- قسمت 22 : ارتباط با سرور - بخش 1 - برپایی تنظیمات
- قسمت 23 : ارتباط با سرور - بخش 2 - شروع به کار با Axios
- قسمت 24 : ارتباط با سرور - بخش 3 - نکات تکمیلی کار با Axios
- قسمت 25 : ارتباط با سرور - بخش 4 - یک تمرین
احراز هویت و اعتبارسنجی کاربران
- قسمت 26 : احراز هویت و اعتبارسنجی کاربران - بخش 1 - ثبت نام و ورود به سیستم
- قسمت 27 : احراز هویت و اعتبارسنجی کاربران - بخش 2 - استخراج و نمایش اطلاعات JWT و خروج از سیستم
- قسمت 28 : احراز هویت و اعتبارسنجی کاربران - بخش 3 - فراخوانی منابع محافظت شده و مخفی کردن عناصر صفحه
- قسمت 29 : احراز هویت و اعتبارسنجی کاربران - بخش 4 - محافظت از مسیرها
React Hooks
- قسمت 30 : React Hooks - بخش 1 - معرفی useState و useEffect
- قسمت 31 : React Hooks - بخش 2 - مقایسه حالتهای مختلف مدیریت حالت با useState Hook
- قسمت 32 : React Hooks - بخش 3 - نکات ویژهی برقراری ارتباط با سرور
- قسمت 33 : React Hooks - بخش 4 - useContext Hook
توزیع برنامه
مدیریت پیشرفتهی حالت در React با Redux و Mobx
Redux
Redux
- قسمت اول : Redux چیست؟
- قسمت دوم : بررسی توابع Redux
- قسمت سوم : روش اتصال Redux به برنامههای React
- قسمت چهارم : انجام اعمال async با Redux
- قسمت پنجم : Redux Hooks
MobX
- قسمت ششم : MobX چیست؟
- قسمت هفتم : بررسی مفاهیم Mobx
- قسمت هشتم : تنظیمات پروژههای React برای کار با Mobx decorators
- قسمت نهم : مثالی از کتابخانهی mobx-react
- قسمت دهم : MobX Hooks و اعمال Async در Mobx
مطالب تکمیلی
- ساخت یک مثال Todo با MobX و React
- روش یکی کردن پروژههای React و ASP.NET Core
- آپلود فایلها توسط برنامههای React به یک سرور ASP.NET Core به همراه نمایش درصد پیشرفت
- روش کار با فایلهای ایستا در برنامههای React
- روش کار با فایلهای پویای ارائه شدهی توسط یک برنامهی ASP.NET Core در برنامههای React
- استفاده از قالب مخصوص Redux Toolkit جهت ایجاد پروژههای React/Redux
- تبدیل یک قالب HTML معمولی به قالب React
- React component lifecycle
- React reconciliation
ASP.NET Core in .NET 8 is your complete solution for modern web development. It handles all of your web development needs from the frontend to the backend. You can build beautiful, richly interactive web experiences with Blazor, and high-performance backend APIs and services that are reliable and secure. ASP.NET Core in .NET 8 is perfect for building cloud-native apps, and great tooling in Visual Studio and Visual Studio Code supercharges your productivity. With ASP.NET Core in .NET 8, every developer is a full stack developer!
نظرات مطالب
EF Code First #12
- Context زمانی تشکیل خواهد شد که کار وهله سازی کنترلر متناظر و موجودی با موفقیت انجام شده باشد.
+ زمانیکه runAllManagedModulesForAllRequests در وب کانفیگ به true تنظیم شده تمام درخواستها به موتور ASP.NET نگاشت میشوند. میشود این وضعیت را کنترل کرد؛ مراجعه کنید به قسمت « تنظیمات ثانویه پس از فعال سازی RouteExistingFiles»
در کل تهیه یک برنامه ASP.NET MVC نیاز به رعایت یک سری موارد دارد که پیشتر در این سایت بحث شده: «چک لیست تهیه یک برنامه ASP.NET MVC». یکی از نکات آن هم «پوشههای Content و Scripts از سیستم مسیریابی تعریف شده در Global.asax خارج شوند» است.
+ زمانیکه runAllManagedModulesForAllRequests در وب کانفیگ به true تنظیم شده تمام درخواستها به موتور ASP.NET نگاشت میشوند. میشود این وضعیت را کنترل کرد؛ مراجعه کنید به قسمت « تنظیمات ثانویه پس از فعال سازی RouteExistingFiles»
در کل تهیه یک برنامه ASP.NET MVC نیاز به رعایت یک سری موارد دارد که پیشتر در این سایت بحث شده: «چک لیست تهیه یک برنامه ASP.NET MVC». یکی از نکات آن هم «پوشههای Content و Scripts از سیستم مسیریابی تعریف شده در Global.asax خارج شوند» است.