فایل EntityFramework.BulkInsert.pdb را از پوشه‌ی bin برنامه حذف کنید. این فایل و اطلاعات موجود در آن، فقط بر روی سیستمی که اصل کتابخانه بر روی آن کامپایل شده معتبر است. برای مثال در این فایل ثبت شده فایل BulkInsertExtention.cs در مسیر c:\prog\lib\user12\bluk قرار دارد که فقط بر روی سیستم نویسنده‌ی اصلی این کتابخانه معتبر است. اگر شما هم نیاز به فایل pdb معتبری دارید، سورس این کتابخانه را دریافت کنید. دستی آن‌را کامپایل کرده و سپس ارجاعی را به اسمبلی نهایی بدهید. اینبار به صورت خودکار فایل pdb معتبری در پوشه‌ی bin برنامه‌ی شما قرار خواهد گرفت.
ارائه‌ی NET 5. یا پایان NET Standard.
تا پیش از ارائه‌ی NET 5.، پیاده سازی‌های مجزایی از دات نت مانند Full .NET Framework ،.NET Core ،Xamarin و غیره وجود داشتند و دارند. در این حالت برای اینکه بتوان یک class library قابل اجرای بر روی تمام این‌ها را ارائه داد، نیاز به ارائه‌ی API ای بود که بین تمام آنها به اشتراک گذاشته شود و این دقیقا هدف وجودی NET Standard. است؛ اما ... مشکلات زیر را نیز به همراه دارد:
هر زمانیکه نیاز به افزودن یک API جدید باشد، نیاز خواهد بود تا یک نگارش جدید از NET Standard. ارائه شود. سپس تمام نگارش‌های مختلف دات نت باید سعی کنند به صورت مجزایی این API جدید را پیاده سازی کنند. این پروسه بسیار کند است. همچنین همواره باید مراجع مختلف را دقیق بررسی کنید که برای مثال کدام نگارش از دات نت، کدام نگارش از NET Standard. را پیاده سازی کرده‌است.
با ارائه‌ی NET 5.، وضعیت کاملا فرق کرده‌است. در اینجا یک «کد پایهی اشتراکی» را برای تمام نگارش‌های مختلف دات نت داریم و این نگارش می‌خواهد مخصوص دسکتاپ یا برنامه‌های موبایل باشد، تفاوتی نمی‌کند. اکنون که تمام نگارش‌های مختلف دات نت بر فراز یک کد اشتراکی پایه کار می‌کنند، دیگر نیازی به ارائه‌ی مجزای یک API استاندارد و سپس پیاده سازی مجزای دیگری از آن، نیست.
نگارش‌های ویژه‌ی NET 5.، مخصوص سکوهای کاری مختلف
همانطور که عنوان شد، NET 5. در اصل یک «مجموعه کد اشتراکی» بین NET Core ،Mono ،Xamarin. و سایر پیاده سازی‌های دات نت است. اما سکوهای کاری مختلف، مانند Android، iOS، ویندوز و غیره، به همراه کدهای قابل توجهی که مختص به آن سیستم عامل‌های خاص باشند نیز هستند. برای رفع این مشکل، یکسری TFM یا target framework name/Target Framework Moniker ارائه شده‌اند. برای مثال net5.0 یکی از آنها است. زمانیکه از این TFM استفاده می‌کنید، یعنی در حال کار با API ای هستید که در تمام نگارش‌های چندسکویی مختلف دات نت، مهیا و قابل استفاده‌است. نام جدید «net5.0» جایگزین کننده‌ی نام‌های قدیمی «netcoreapp» و «netstandard» است.
در اینجا اگر نیاز به کار با API مخصوص ویندوز را نیز داشتید، می‌توانید از TFM مخصوص آن که net5.0-windows نام دارد استفاده کنید. «net5.0-windows» به این معنا است که به تمام امکانات net5.0 دسترسی دارید؛ به علاوه‌ی API ای که مختص به سیستم عامل ویندوز است (مانند Windows Forms و WPF). در دات نت 6، دو TFM جدید net6.0-android و net6.0-ios را نیز شاهد خواهیم بود.
کار کردن با این اسامی و درک آنها نیز ساده‌است. برای مثال net6.0-ios به این معنا است که این قطعه کد و اسمبلی آن، می‌تواند تمام کتابخانه‌های مخصوص net5.0 و net6.0 را نیز استفاده کند؛ اما نه کتابخانه‌هایی که به صورت اختصاصی برای net5.0-windows و یا net6.0-android کامپایل شده‌اند.
این توضیحات به معنای پایان کار «NET Standard.» است. پس از NET Standard 2.1. فعلی، دیگر هیچ نگارش جدیدتری از آن ارائه نخواهد شد و البته net5.0 و تمام نگارش‌های پس از آن، قابلیت استفاده‌ی از کتابخانه‌های مبتنی بر NET Standard 2.1. و پیش از آن‌را نیز دارا هستند. بنابراین از این پس، net5.0 را به عنوان پایهی به اشتراک گذاری کدها مدنظر داشته باشید.
سؤال: اگر امروز خواستیم کتابخانه‌ای را تولید کنیم، باید از کدام TFM استفاده کرد؟
net5.0 و تمام نگارش‌های پس از آن، از کتابخانه‌های مبتنی بر NET Standard 2.1. و قبل از آن نیز پیشیبانی می‌کنند. در این حالت تنها دلیل تغییر TFM کتابخانه‌های قدیمی موجود به net5.0، می‌تواند دسترسی به یکسری API جدید باشد. اما در مورد کتابخانه‌های جدید چطور؟ آیا باید برای مثال از netstandard2.0 استفاده کرد و یا از net5.0؟ این مورد بستگی به نوع پروژه‌ی در حال تهیه دارد:
- اجزای مختلف یک برنامه: اگر از کتابخانه‌ها برای شکستن برنامه‌ی خود به چندین قسمت استفاده می‌کنید، بهتر است از نام جدید netX.Y استفاده کنید (مانند net5.0). که در اینجا X.Y، منظور پایین‌ترین شماره نگارش NET. ای است که برنامه‌ی شما قرار است بر مبنای آن تهیه شود.
- کتابخانه‌های با قابلیت استفاده‌ی مجدد: اگر قرار است از کتابخانه‌ی شما در NET 4x. نیز استفاده شود، با netstandard2.0 شروع کنید. بهتر است netstandard1x را فراموش کنید؛ چون دیگر پشتیبانی نمی‌شود. اگر نیازی به پشتیبانی از NET 4x. ندارید، می‌توانید یا از netstandard2.1 و یا از net5.0 استفاده کنید و اگر در این حالت نیازی به پشتیبانی از NET Core 3x. ندارید، می‌توانید مستقیما با net5.0 شروع کنید.
بنابراین به صورت خلاصه:
- netstandard2.0 امکان اشتراک کدها را بین NET 4x. و سایر سکوهای کاری میسر می‌کند.
- netstandard2.1 امکان اشتراک کدها را بین Mono ،Xamarin و NET Core 3x. میسر می‌کند.
- net5.0، مخصوص نگارش فعلی و آینده‌ی دات نت است.
و یا حتی می‌توانید یک کتابخانه را به صورت multi-targeting با پشتیبانی از تمام TFMهای یاد شده‌ی فوق نیز تولید کنید:
تا پیش از ارائه‌ی NET 5.، پیاده سازی‌های مجزایی از دات نت مانند Full .NET Framework ،.NET Core ،Xamarin و غیره وجود داشتند و دارند. در این حالت برای اینکه بتوان یک class library قابل اجرای بر روی تمام این‌ها را ارائه داد، نیاز به ارائه‌ی API ای بود که بین تمام آنها به اشتراک گذاشته شود و این دقیقا هدف وجودی NET Standard. است؛ اما ... مشکلات زیر را نیز به همراه دارد:
هر زمانیکه نیاز به افزودن یک API جدید باشد، نیاز خواهد بود تا یک نگارش جدید از NET Standard. ارائه شود. سپس تمام نگارش‌های مختلف دات نت باید سعی کنند به صورت مجزایی این API جدید را پیاده سازی کنند. این پروسه بسیار کند است. همچنین همواره باید مراجع مختلف را دقیق بررسی کنید که برای مثال کدام نگارش از دات نت، کدام نگارش از NET Standard. را پیاده سازی کرده‌است.
با ارائه‌ی NET 5.، وضعیت کاملا فرق کرده‌است. در اینجا یک «کد پایهی اشتراکی» را برای تمام نگارش‌های مختلف دات نت داریم و این نگارش می‌خواهد مخصوص دسکتاپ یا برنامه‌های موبایل باشد، تفاوتی نمی‌کند. اکنون که تمام نگارش‌های مختلف دات نت بر فراز یک کد اشتراکی پایه کار می‌کنند، دیگر نیازی به ارائه‌ی مجزای یک API استاندارد و سپس پیاده سازی مجزای دیگری از آن، نیست.
نگارش‌های ویژه‌ی NET 5.، مخصوص سکوهای کاری مختلف
همانطور که عنوان شد، NET 5. در اصل یک «مجموعه کد اشتراکی» بین NET Core ،Mono ،Xamarin. و سایر پیاده سازی‌های دات نت است. اما سکوهای کاری مختلف، مانند Android، iOS، ویندوز و غیره، به همراه کدهای قابل توجهی که مختص به آن سیستم عامل‌های خاص باشند نیز هستند. برای رفع این مشکل، یکسری TFM یا target framework name/Target Framework Moniker ارائه شده‌اند. برای مثال net5.0 یکی از آنها است. زمانیکه از این TFM استفاده می‌کنید، یعنی در حال کار با API ای هستید که در تمام نگارش‌های چندسکویی مختلف دات نت، مهیا و قابل استفاده‌است. نام جدید «net5.0» جایگزین کننده‌ی نام‌های قدیمی «netcoreapp» و «netstandard» است.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>
</Project> کار کردن با این اسامی و درک آنها نیز ساده‌است. برای مثال net6.0-ios به این معنا است که این قطعه کد و اسمبلی آن، می‌تواند تمام کتابخانه‌های مخصوص net5.0 و net6.0 را نیز استفاده کند؛ اما نه کتابخانه‌هایی که به صورت اختصاصی برای net5.0-windows و یا net6.0-android کامپایل شده‌اند.
این توضیحات به معنای پایان کار «NET Standard.» است. پس از NET Standard 2.1. فعلی، دیگر هیچ نگارش جدیدتری از آن ارائه نخواهد شد و البته net5.0 و تمام نگارش‌های پس از آن، قابلیت استفاده‌ی از کتابخانه‌های مبتنی بر NET Standard 2.1. و پیش از آن‌را نیز دارا هستند. بنابراین از این پس، net5.0 را به عنوان پایهی به اشتراک گذاری کدها مدنظر داشته باشید.
سؤال: اگر امروز خواستیم کتابخانه‌ای را تولید کنیم، باید از کدام TFM استفاده کرد؟
net5.0 و تمام نگارش‌های پس از آن، از کتابخانه‌های مبتنی بر NET Standard 2.1. و قبل از آن نیز پیشیبانی می‌کنند. در این حالت تنها دلیل تغییر TFM کتابخانه‌های قدیمی موجود به net5.0، می‌تواند دسترسی به یکسری API جدید باشد. اما در مورد کتابخانه‌های جدید چطور؟ آیا باید برای مثال از netstandard2.0 استفاده کرد و یا از net5.0؟ این مورد بستگی به نوع پروژه‌ی در حال تهیه دارد:
- اجزای مختلف یک برنامه: اگر از کتابخانه‌ها برای شکستن برنامه‌ی خود به چندین قسمت استفاده می‌کنید، بهتر است از نام جدید netX.Y استفاده کنید (مانند net5.0). که در اینجا X.Y، منظور پایین‌ترین شماره نگارش NET. ای است که برنامه‌ی شما قرار است بر مبنای آن تهیه شود.
- کتابخانه‌های با قابلیت استفاده‌ی مجدد: اگر قرار است از کتابخانه‌ی شما در NET 4x. نیز استفاده شود، با netstandard2.0 شروع کنید. بهتر است netstandard1x را فراموش کنید؛ چون دیگر پشتیبانی نمی‌شود. اگر نیازی به پشتیبانی از NET 4x. ندارید، می‌توانید یا از netstandard2.1 و یا از net5.0 استفاده کنید و اگر در این حالت نیازی به پشتیبانی از NET Core 3x. ندارید، می‌توانید مستقیما با net5.0 شروع کنید.
بنابراین به صورت خلاصه:
- netstandard2.0 امکان اشتراک کدها را بین NET 4x. و سایر سکوهای کاری میسر می‌کند.
- netstandard2.1 امکان اشتراک کدها را بین Mono ،Xamarin و NET Core 3x. میسر می‌کند.
- net5.0، مخصوص نگارش فعلی و آینده‌ی دات نت است.
و یا حتی می‌توانید یک کتابخانه را به صورت multi-targeting با پشتیبانی از تمام TFMهای یاد شده‌ی فوق نیز تولید کنید:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>net5.0;netstandard2.1;netstandard2.0;net461</TargetFrameworks>
</PropertyGroup>
</Project> نسخه native، منظور کامپایل مستقیم کدهای سی‌شارپ به کدهای ماشین هستند. در حال حاضر اگر صحبت از #C می‌شود، منظور #CLR C است. یعنی کدهای شما ابتدا به IL ترجمه می‌شوند و بعد IL توسط JIT Compiler به کدهای ماشین ترجمه خواهد شد. در نسخه native این دو مرحله حذف و تبدیل به یک مرحله خواهند شد. البته برای مقاصد سیستمی جهت دسترسی بیشتر به سخت افزار و همچنین بالابردن سرعت اجرایی کدها. برای رقابت با ++C با ارائه زبانی که type safe است؛ برای کارهای async بهینه سازی شده‌است، سرعت توسعه با آن بالاتر است و ابزارهای بهتری برای آن تدارک دیده شده‌اند. ضمنا استاندارد آن در اختیار مایکروسافت است و تغییرات آتی آن ساده‌تر خواهند بود و سریعتر.
دات نت 6 به همراه source generatorهای توکاری است که می‌توانند کار serialization و deserialization نوع JSON را با کارآیی بسیار بیشتری انجام دهند؛ با آزمایش‌هایی که این بهبود را در حد 40 درصد سریعتر نسبت به حالت متداول آن نمایش می‌دهند و ... این مساله بسیار مهم است. از این جهت که این روزها، JSON را در همه‌جا مشاهده می‌کنیم؛ در Web APIها، در تنظیمات برنامه‌ها، در ارسال پیام‌ها بین برنامه‌ها و غیره. بنابراین هرگونه بهبودی در زمینه‌ی کارآیی serialization و deserialization آن، تاثیر بسیار قابل ملاحظه‌ای را بر روی کارآیی کلی یک برنامه بجا خواهد گذاشت.
System.Text.Json source generator چیست؟
پایهی تمام اعمال serialization و deserialization در دات نت، استفاده از Reflection است که در زمینه‌ی ارائه‌ی برنامه‌هایی با کارآیی بالا و با مصرف حافظه‌ی پایین، بهینه عمل نمی‌کند. راه‌حل جایگزین استفاده از Reflection که در زمان اجرای برنامه رخ می‌دهد، به همراه دات نت 5 ارائه شد و source generators نام دارد. Source generators امکان تولید فایل‌های #C را در زمان کامپایل برنامه میسر می‌کنند که نسبت به راه‌حل Reflection که در زمان اجرای برنامه فعال می‌شود، کارآیی بسیار بیشتری را ارائه می‌کنند. برای مثال به همراه دات نت 6، علاوه بر روش پیش‌فرض مبتنی بر Reflection ارائه شده‌ی توسط System.Text.Json، راه حل جدید امکان استفاده‌ی از source generators توکار آن نیز پیش بینی شده‌است. کار اصلی آن، انجام تمام مراحلی است که پیشتر توسط Reflection در زمان اجرای برنامه صورت می‌گرفت، اینبار در زمان کامپایل برنامه و ارائه‌ی آن به صورت از پیش آماده شده و مهیا.
مزایای این روش شامل موارد زیر است:
- بالا رفتن سرعت برنامه
- کاهش زمان آغاز اولیه‌ی برنامه
- کاهش میزان حافظه‌ی مورد نیاز برنامه
- عدم نیاز به استفاده‌ی از System.Reflection و System.Reflection.Emit
- ارائه‌ی Trim-compatible serialization که سبب کاهش اندازه‌ی نهایی برنامه می‌شود. برای مثال در برنامه‌های Blazor می‌توان با فعالسازی Trimming، کدهای استفاده نشده را از فایل‌های بایناری نهایی حذف کرد. استفاده از source generators، با این روش سازگاری کاملی دارد.
مثالی از نحوه‌ی کار با JSON در دات نت 6، توسط source generators آن
فرض کنید قصد داریم اعمال serialization و deserialization از نوع JSON را بر روی نمونه‌های کلاس زیر انجام دهیم:
اولین کاری که در این زمینه باید انجام شود، ایجاد یک کلاس خالی، با نامی دلخواه، اما مشتق شده‌ی از JsonSerializerContext است. در این حالت اخطارهایی را در IDE خود مبتنی بر نیاز به پیاده سازی تعدادی از متدهای این کلاس پایه دریافت می‌کنیم. اما ... ما قصد نداریم این متدها را پیاده سازی کنیم؛ Source generator قرار است اینکار را انجام دهد. به همین جهت این کلاس را partial تعریف کرده (تا source generator بتواند آن‌را در فایلی دیگر تکمیل کند) و همچنین آن‌را مزین به ویژگی JsonSerializable از نوع کلاسی که می‌خواهیم آن‌را serialize کنیم، خواهیم کرد تا سبب فعال شدن source generator بر روی این کلاس شویم:
و ... همین! کدهای این کلاس partial توسط source generator در زمان کامپایل برنامه به صورت خودکار تولید و تکمیل می‌شوند.
پس از آن فقط کافی است MyJsonContext را به عنوان پارامتر متدهای جدید Serialize و یا Deserialize، به صورت زیر ارسال کنیم تا از آن استفاده شود:
متدهای جدید این API مبتنی بر source generators را در ادامه ملاحظه می‌کنید:
روش معرفی تنظیمات Serializer به Source generator
برای معرفی تنظیمات serialization و deserialization، برای مثال تهیه‌ی خروجی‌های CamelCase، می‌توان از ویژگی JsonSourceGenerationOptions به صورت زیر استفاده کرد:
در این حالت مابقی کدها مانند قبل باقی خواهند ماند:
روش استفاده از JSON Source generators در برنامه‌های ASP.NET Core
در این نوع برنامه‌ها، JsonSerializerContextها را می‌توان توسط متد AddContext به صورت زیر به تنظیمات JSON برنامه معرفی کرد:
روش استفاده از JSON Source generators در برنامه‌های Blazor
البته در اینجا بیشتر منظور امکان استفاده‌ی از آنها توسط HttpClient است که به صورت زیر توسط متد GetFromJsonAsync واقع در فضای نام System.Net.Http.Json، میسر شده‌است:
لیست کامل‌تر این API جدید به صورت زیر است:
System.Text.Json source generator چیست؟
پایهی تمام اعمال serialization و deserialization در دات نت، استفاده از Reflection است که در زمینه‌ی ارائه‌ی برنامه‌هایی با کارآیی بالا و با مصرف حافظه‌ی پایین، بهینه عمل نمی‌کند. راه‌حل جایگزین استفاده از Reflection که در زمان اجرای برنامه رخ می‌دهد، به همراه دات نت 5 ارائه شد و source generators نام دارد. Source generators امکان تولید فایل‌های #C را در زمان کامپایل برنامه میسر می‌کنند که نسبت به راه‌حل Reflection که در زمان اجرای برنامه فعال می‌شود، کارآیی بسیار بیشتری را ارائه می‌کنند. برای مثال به همراه دات نت 6، علاوه بر روش پیش‌فرض مبتنی بر Reflection ارائه شده‌ی توسط System.Text.Json، راه حل جدید امکان استفاده‌ی از source generators توکار آن نیز پیش بینی شده‌است. کار اصلی آن، انجام تمام مراحلی است که پیشتر توسط Reflection در زمان اجرای برنامه صورت می‌گرفت، اینبار در زمان کامپایل برنامه و ارائه‌ی آن به صورت از پیش آماده شده و مهیا.
مزایای این روش شامل موارد زیر است:
- بالا رفتن سرعت برنامه
- کاهش زمان آغاز اولیه‌ی برنامه
- کاهش میزان حافظه‌ی مورد نیاز برنامه
- عدم نیاز به استفاده‌ی از System.Reflection و System.Reflection.Emit
- ارائه‌ی Trim-compatible serialization که سبب کاهش اندازه‌ی نهایی برنامه می‌شود. برای مثال در برنامه‌های Blazor می‌توان با فعالسازی Trimming، کدهای استفاده نشده را از فایل‌های بایناری نهایی حذف کرد. استفاده از source generators، با این روش سازگاری کاملی دارد.
مثالی از نحوه‌ی کار با JSON در دات نت 6، توسط source generators آن
فرض کنید قصد داریم اعمال serialization و deserialization از نوع JSON را بر روی نمونه‌های کلاس زیر انجام دهیم:
namespace Test
{
internal class Person
{
public string FirstName { get; set; }
public string LastName { get; set; }
}
} using System.Text.Json.Serialization;
namespace Test
{
[JsonSerializable(typeof(Person))]
internal partial class MyJsonContext : JsonSerializerContext
{
}
} پس از آن فقط کافی است MyJsonContext را به عنوان پارامتر متدهای جدید Serialize و یا Deserialize، به صورت زیر ارسال کنیم تا از آن استفاده شود:
Person person = new() { FirstName = "Jane", LastName = "Doe" };
byte[] utf8Json = JsonSerializer.SerializeToUtf8Bytes(person, MyJsonContext.Default.Person);
person = JsonSerializer.Deserialize(utf8Json, MyJsonContext.Default.Person); متدهای جدید این API مبتنی بر source generators را در ادامه ملاحظه می‌کنید:
namespace System.Text.Json
{
public static class JsonSerializer
{
public static object? Deserialize(ReadOnlySpan<byte> utf8Json, Type returnType, JsonSerializerContext context) => ...;
public static object? Deserialize(ReadOnlySpan<char> json, Type returnType, JsonSerializerContext context) => ...;
public static object? Deserialize(string json, Type returnType, JsonSerializerContext context) => ...;
public static object? Deserialize(ref Utf8JsonReader reader, Type returnType, JsonSerializerContext context) => ...;
public static ValueTask<object?> DeserializeAsync(Stream utf8Json, Type returnType, JsonSerializerContext context, CancellationToken cancellationToken = default(CancellationToken)) => ...;
public static ValueTask<TValue?> DeserializeAsync<TValue>(Stream utf8Json, JsonTypeInfo<TValue> jsonTypeInfo, CancellationToken cancellationToken = default(CancellationToken)) => ...;
public static TValue? Deserialize<TValue>(ReadOnlySpan<byte> utf8Json, JsonTypeInfo<TValue> jsonTypeInfo) => ...;
public static TValue? Deserialize<TValue>(string json, JsonTypeInfo<TValue> jsonTypeInfo) => ...;
public static TValue? Deserialize<TValue>(ReadOnlySpan<char> json, JsonTypeInfo<TValue> jsonTypeInfo) => ...;
public static TValue? Deserialize<TValue>(ref Utf8JsonReader reader, JsonTypeInfo<TValue> jsonTypeInfo) => ...;
public static string Serialize(object? value, Type inputType, JsonSerializerContext context) => ...;
public static void Serialize(Utf8JsonWriter writer, object? value, Type inputType, JsonSerializerContext context) { }
public static Task SerializeAsync(Stream utf8Json, object? value, Type inputType, JsonSerializerContext context, CancellationToken cancellationToken = default(CancellationToken)) => ...;
public static Task SerializeAsync<TValue>(Stream utf8Json, TValue value, JsonTypeInfo<TValue> jsonTypeInfo, CancellationToken cancellationToken = default(CancellationToken)) => ...;
public static byte[] SerializeToUtf8Bytes(object? value, Type inputType, JsonSerializerContext context) => ...;
public static byte[] SerializeToUtf8Bytes<TValue>(TValue value, JsonTypeInfo<TValue> jsonTypeInfo) => ...;
public static void Serialize<TValue>(Utf8JsonWriter writer, TValue value, JsonTypeInfo<TValue> jsonTypeInfo) { }
public static string Serialize<TValue>(TValue value, JsonTypeInfo<TValue> jsonTypeInfo) => ...;
}
} برای معرفی تنظیمات serialization و deserialization، برای مثال تهیه‌ی خروجی‌های CamelCase، می‌توان از ویژگی JsonSourceGenerationOptions به صورت زیر استفاده کرد:
using System.Text.Json.Serialization;
namespace Test
{
[JsonSourceGenerationOptions(PropertyNamingPolicy = JsonKnownNamingPolicy.CamelCase)]
[JsonSerializable(typeof(Person))]
internal partial class MyJsonContext : JsonSerializerContext
{
}
} string json = JsonSerializer.Serialize(person, MyJsonContext.Default.Person); Person person = JsonSerializer.Deserialize(json, MyJsonContext.Default.Person);
روش استفاده از JSON Source generators در برنامه‌های ASP.NET Core
در این نوع برنامه‌ها، JsonSerializerContextها را می‌توان توسط متد AddContext به صورت زیر به تنظیمات JSON برنامه معرفی کرد:
services.AddControllers().AddJsonOptions(options => options.AddContext<MyJsonContext>());
روش استفاده از JSON Source generators در برنامه‌های Blazor
البته در اینجا بیشتر منظور امکان استفاده‌ی از آنها توسط HttpClient است که به صورت زیر توسط متد GetFromJsonAsync واقع در فضای نام System.Net.Http.Json، میسر شده‌است:
[JsonSerializable(typeof(WeatherForecast[]))]
internal partial class MyJsonContext : JsonSerializerContext { }
@code {
private WeatherForecast[] forecasts;
private static JsonSerializerOptions Options = new(JsonSerializerDefaults.Web);
private static MyJsonContext Context = new MyJsonContext(Options);
protected override async Task OnInitializedAsync()
{
forecasts = await Http.GetFromJsonAsync("sample-data/weather.json", Context.WeatherForecastArray);
}
} namespace System.Net.Http.Json
{
public static partial class HttpClientJsonExtensions
{
public static Task<object?> GetFromJsonAsync(this HttpClient client, string? requestUri, Type type, JsonSerializerContext context, CancellationToken cancellationToken = default(CancellationToken)) => ...;
public static Task<object?> GetFromJsonAsync(this HttpClient client, System.Uri? requestUri, Type type, JsonSerializerContext context, CancellationToken cancellationToken = default(CancellationToken)) => ...;
public static Task<TValue?> GetFromJsonAsync<TValue>(this HttpClient client, string? requestUri, JsonTypeInfo<TValue> jsonTypeInfo, CancellationToken cancellationToken = default(CancellationToken)) => ...;
public static Task<TValue?> GetFromJsonAsync<TValue>(this HttpClient client, System.Uri? requestUri, JsonTypeInfo<TValue> jsonTypeInfo, CancellationToken cancellationToken = default(CancellationToken)) => ...;
public static Task<HttpResponseMessage> PostAsJsonAsync<TValue>(this HttpClient client, string? requestUri, TValue value, JsonTypeInfo<TValue> jsonTypeInfo, CancellationToken cancellationToken = default(CancellationToken)) => ...;
public static Task<HttpResponseMessage> PostAsJsonAsync<TValue>(this HttpClient client, System.Uri? requestUri, TValue value, JsonTypeInfo<TValue> jsonTypeInfo, CancellationToken cancellationToken = default(CancellationToken)) => ...;
public static Task<HttpResponseMessage> PutAsJsonAsync<TValue>(this HttpClient client, string? requestUri, TValue value, JsonTypeInfo<TValue> jsonTypeInfo, CancellationToken cancellationToken = default(CancellationToken)) => ...;
public static Task<HttpResponseMessage> PutAsJsonAsync<TValue>(this HttpClient client, System.Uri? requestUri, TValue value, JsonTypeInfo<TValue> jsonTypeInfo, CancellationToken cancellationToken = default(CancellationToken)) => ...;
}
public static partial class HttpContentJsonExtensions
{
public static Task<object?> ReadFromJsonAsync(this HttpContent content, Type type, JsonSerializerContext context, CancellationToken cancellationToken = default(CancellationToken)) => ...;
public static Task<T?> ReadFromJsonAsync<T>(this HttpContent content, JsonTypeInfo<TValue> jsonTypeInfo, CancellationToken cancellationToken = default(CancellationToken)) => ...;
}
} 
در این سلسله مقالات قصد دارم چندین مطلب راجع به افزایش سرعت نرم افزارهای تحت وب مطرح نمایم. این مطالب هرچند بسیار مختصر می‌باشند ولی در کارایی و سرعت برنامه‌های شما در آینده تاثیر خواهند داشت.
این دو خط یعنی خداحافظ Web Forms Engine...
البته همانطور که حتما دوستان مطلع هستند امکان گسترش Engineهای فوق توسط ارث بری از کلاس BuildManagerViewEngine جهت ایجاد Engineهای دیگر همیشه محیا است. در این صورت می‌توانید تنها انجین سفارشی مورد نظر خود را لود کرده و از لود دیگر انجین‌ها پرهیز کنید.
1.کش کردن همیشه آخرین حربه می‌باشد
این مهم است که بخش‌های مختلف سایت شما در سطوح مختلف کش شوند (ASP.NET, Kernel, Server, Proxy Server, Browser ,...) ولی این موضوع باید همیشه آخرین حربه و نکته ای باشد که آن را در مورد سایت خود اعمال می‌کنید.
یعنی همیشه مطمئن شوید ابتدا تمامی نکات مربوط به افزایش کارایی در برنامه خود را رعایت کرده اید، سپس اقدام به کش داده‌ها در سطوح مختلف نمایید. توجه کنید کش کردن داده‌ها و صفحات می‌تواند مشکلات را برای شما به عنوان یک برنامه نویس یا تست کننده برنامه پنهان کند و به شما اطمینان دهد که همه چیز خوب کار می‌کند در حالی که این چنین نیست!
البته ذکر این نکته هم بی فایده نیست که کش کردن همه چیز بعضی مواقع دشمن برنامه شما محسوب می‌شود! هیچ وقت یادم نمی‌رود، در پورتال داخلی یک شرکت که در وقت استراحت به کارکنان اجازه مطالعه روزنامه‌های روز را می‌داد (به صورت آفلاین)، این نکته در بالای صفحه آورده شده بود: «لطفا برای به روز رساندن صفحات روزنامه‌ها از کلید Ctrl+F5 استفاده نمایید». این موضوع یعنی بحث کشینگ در برنامه آن پرتال در سطح فاجعه می‌باشد! حالا فرض کنید این مشکل در فرم ورود و یا مرور اطلاعات یک برنامه به وجود آید...
2.حذف View Engineهای غیر ضروری
به عنوان یک برنامه نویس ASP.NET MVC، یابد اطلاع داشته باشید که CLR به صورت خودکار View Engineهای Razor و Web Forms را لود می‌کند. این موضوع به این دلیل است که اطلاعی از نحوه برنامه نویسی شما ندارد. اگر شما فقط از یکی از این دو View Engine استفاده می‌کنید،لطفا دیگری را غیر فعال کنید! فعال بودن هر دوی آنها یعنی اتلاف وقت گرانبهای CPU سرور شما برای رندر کردن تمامی صفحات شما توسط دو انجین! ایتدا viewهای شما با Web Forms Engine رندر شده سپس نتیجه به Razor Engine منتقل شده و مجدد توسط این انجین رندر می‌شود. این موضوع در سایت‌های با تعداد کاربر بالا یعنی فاجعه!
برای حل این مشکل کافی است خطوط زیر را در فایل Global.asax و در رویداد بخش Application_Start وارد نمایید:
ViewEngines.Engines.Clear(); ViewEngines.Engines.Add(new RazorViewEngine());
قبل از استفاده از این کد، اطمینان حاصل کنید کل برنامه شما توسط Razor تهیه شده است وگرنه بنده هیچ مسئولیتی در رابطه با فریادهای کارفرمای شما متقبل نمی‌شوم!
صد البته برای حذف Razor Engine و استفاده از Web Form Engine می‌توان از کد زیر در همان موقعیت فوق استفاده کرد:
ViewEngines.Engines.Clear(); ViewEngines.Engines.Add(new WebFormViewEngine());
3. استفاده از فایل‌های PDB مایکروسافت برای دیباگ و یا پروفایل کردن DLLهای دیگران
دیباگ یا پروفایل کردن برنامه ها، DLL ها، اسمبلی‌ها و منابعی از برنامه که شما آن را خود ننوشته اید (سورس آنها در دسترس شما نمی‌باشد) همیشه یکی از سخت‌ترین مراحل کار می‌باشد. جهت کمک به دیباگر‌ها یا پروفایلرها، نیاز است فایل‌های PDB مرتبط با DLLها را در اختیار آنها قرار دهید تا به بهترین نتیجه دسترسی پیدا کنید. این فایل‌ها محتوی نام توابع، شماره خطوط برنامه و metadataهای دیگر برنامه اصلی قبل از optimize شدن توسط کامپایلر یا JIT می‌باشد. خوب حالا اگر نیاز شد این کار را در رابطه با DLLها و کلاس‌های پایه Microsoft.NET انجام دهیم چه کار کنیم؟
خیلی ساده! خود Microsoft سروری جهت این موضوع تدارک دیده که فایل‌های PDB را جهت دیباگ کردن در اختیار تیم‌های برنامه نویسی قرار می‌دهد.کافی است از منوی Tools گزینه Options را انتخاب، سپس به بخش Debugging و به بخش Symbols بروید و گزینه Microsoft Symbol Servers as your source for Symbols را انتخاب کنید. برای اطمینان از اینکه هر مرتبه که برنامه را دیباگ می‌کنید مجبور به دانلود این فایل‌ها نشوید، فراموش نکنید پوشه ای را جهت کش این فایل‌ها ایجاد و آدرس آن را در بخش Cache symbols in this directory همین صفحه وارد نمایید.
این امکان در Visual Studio 2010, 2012 در دسترس می‌باشد.
اگر یک پروژه‌ی خالی ASP.NET Core Web Application را شروع کنید (با طی مراحل زیر جهت ایجاد یک پروژه‌ی جدید):
تغییرات ساختاری ASP.NET Core 1.0، با نگارش‌های قبلی ASP.NET، بسیار قابل ملاحظه هستند:
در اینجا نقش Solution همانند نگارش‌های قبلی ویژوال استودیو است: ظرفی است برای ساماندهی موارد مورد نیاز جهت تشکیل یک برنامه‌ی وب و شامل مواردی است مانند پروژه‌ها، تنظیمات آنها و غیره. بنابراین هنوز در اینجا فایل sln. تشکیل می‌شود.
نقش فایل global.json
زمانیکه یک پروژه‌ی جدید ASP.NET Core 1.0 را آغاز می‌کنیم، ساختار پوشه‌های آن به صورت زیر هستند:
در اینجا هنوز فایل sln. قابل مشاهده است. همچنین در اینجا فایل جدیدی به نام global.json نیز وجود دارد، با این محتوا:
شماره نگارش ذکر شده‌ی در اینجا را در قسمت قبل بررسی کردیم.
خاصیت projects در اینجا به صورت یک آرایه تعریف شده‌است و بیانگر محل واقع شدن پوشه‌های اصلی پروژه‌ی جاری هستند. پوشه‌ی src یا source را در تصویر فوق مشاهده می‌کنید و محلی است که سورس‌های برنامه در آن قرار می‌گیرند. یک پوشه‌ی test نیز در اینجا ذکر شده‌است و اگر در حین ایجاد پروژه، گزینه‌ی ایجاد unit tests را هم انتخاب کرده باشید، این پوشه‌ی مخصوص نیز ایجاد خواهد شد.
نکته‌ی مهم اینجا است، هرکدی که درون پوشه‌های ذکر شده‌ی در اینجا قرار نگیرد، قابلیت build را نخواهد داشت. به عبارتی این نسخه‌ی از ASP.NET پوشه‌ها را قسمتی از پروژه به حساب می‌آورد. در نگارش‌های قبلی ASP.NET، مداخل تعریف فایل‌های منتسب به هر پروژه، درون فایلی با پسوند csproj. قرار می‌گرفتند. معادل این فایل در اینجا اینبار پسوند xproj را دارد و اگر آن‌را با یک ادیتور متنی باز کنید، فاقد تعاریف مداخل فایل‌های پروژه است.
در این نگارش جدید اگر فایلی را به پوشه‌ی src اضافه کنید یا حذف کنید، بلافاصله در solution explorer ظاهر و یا حذف خواهد شد.
یک آزمایش: به صورت معمول از طریق windows explorer به پوشه‌ی src برنامه وارد شده و فایل پیش فرض Project_Readme.html را حذف کنید. سپس به solution explorer ویژوال استودیو دقت کنید. مشاهده خواهید کرد که این فایل، بلافاصله از آن حذف می‌شود. در ادامه به recycle bin ویندوز مراجعه کرده و این فایل حذف شده را restore کنید تا مجددا به پوشه‌ی src برنامه اضافه شود. اینبار نیز افزوده شدن خودکار و بلافاصله‌ی این فایل را می‌توان در solution explorer مشاهده کرد.
بنابراین ساختار مدیریت فایل‌های این نگارش از ASP.NET در ویژوال استودیو، بسیار شبیه به ساختار مدیریت فایل‌های VSCode شده‌است که آن نیز بر اساس پوشه‌ها کار می‌کند و یک پوشه و تمام محتوای آن‌را به صورت پیش فرض به عنوان یک پروژه می‌شناسد. به همین جهت دیگر فایل csproj ایی در اینجا وجود ندارد و file system همان project system است.
یک نکته: در اینجا مسیرهای مطلق را نیز می‌توان ذکر کرد:
اما در مورد هر مسیری که ذکر می‌شود، NET Core. باید بتواند یک سطح پایین‌تر از پوشه‌ی ذکر شده، فایل مهم project.json را پیدا کند؛ در غیراینصورت از آن صرفنظر خواهد شد. برای مثال برای مسیر نسبی src، مسیر src\MyProjectName\project.json را جستجو می‌کند و برای مسیر مطلق ذکر شده، این مسیر را c:\\sources\\Configuration\\src\\SomeName\\project.json
کامپایل خودکار پروژه در ASP.NET Core 1.0
علاوه بر تشخیص خودکار کم و زیاد شدن فایل‌های سیستمی پروژه، بدون نیاز به Add new item کردن آنها در ویژوال استودیو، اگر سورس‌های برنامه را نیز تغییر دهید، فایل سورس جدیدی را اضافه کنید و یا فایل سورس موجودی را حذف کنید، کل پروژه به صورت خودکار کامپایل می‌شود و نیازی نیست اینکار را به صورت دستی انجام دهید.
یک آزمایش: برنامه را از طریق منوی debug و گزینه‌ی start without debugging اجرا کنید. اگر برنامه را در حالت معمول debug->start debugging اجرا کنید، حالت کامپایل خودکار را مشاهده نخواهید کرد. در اینجا (پس از start without debugging) یک چنین خروجی را مشاهده خواهید کرد:
این خروجی حاصل اجرای کدهای درون فایل Startup.cs برنامه است:
اکنون در همین حال که برنامه در حال اجرا است و هنوز IIS Express خاتمه نیافته است، از طریق windows explorer، به پوشه‌ی src برنامه وارد شده و فایل Startup.cs را با notepad باز کنید. هدف این است که این فایل را در خارج از ویژوال استودیو ویرایش کنیم. اینبار سطر await دار را در notepad به نحو ذیل ویرایش کنید:
پس از آن اگر مرورگر را refresh کنید، بلافاصله خروجی جدید فوق را مشاهده خواهید کرد که بیانگر کامپایل خودکار پروژه در صورت تغییر فایل‌های آن است.
این مساله قابلیت استفاده‌ی از ASP.NET Core را در سایر ادیتورهای موجود، مانند VSCode سهولت می‌بخشد.
نقش فایل project.json
فایل جدید project.json مهم‌ترین فایل تنظیمات یک پروژه‌ی ASP.NET Core است و مهم‌ترین قسمت آن، قسمت وابستگی‌های آن است:
همانطور که در قسمت قبل نیز عنوان شد، در این نگارش از دات نت، تمام وابستگی‌های پروژه از طریق نیوگت تامین می‌شوند و دیگر خبری از یک دات نت «بزرگ» که شامل تمام اجزای این مجموعه‌است نیست. این مساله توزیع برنامه را ساده‌تر کرده و همچنین امکان به روز رسانی سریعتر این اجزا را توسط تیم‌های مرتبط فراهم می‌کند؛ بدون اینکه نیازی باشد تا منتظر یک توزیع «بزرگ» دیگر ماند.
در نگارش‌های قبلی ASP.NET، فایلی XML ایی به نام packages.config حاوی تعاریف مداخل بسته‌های نیوگت برنامه بود. این فایل در اینجا جزئی از محتوای فایل project.json در قسمت dependencies آن است.
با قسمت وابستگی‌های این فایل، به دو طریق می‌توان کار کرد:
الف) ویرایش مستقیم این فایل که به همراه intellisense نیز هست. با افزودن مداخل جدید به این فایل و ذخیره کردن آن، بلافاصله کار restore و دریافت و نصب آنها آغاز می‌شود:
ب) از طریق NuGet package manager
روش دیگر کار با وابستگی‌ها، کلیک راست بر روی گره references و انتخاب گزینه‌ی manage nuget packages است:
برای نمونه جهت نصب ASP.NET MVC 6 این مراحل باید طی شوند:
ابتدا برگه‌ی browse را انتخاب کنید و سپس تیک مربوط به include prerelease را نیز انتخاب نمائید.
البته بسته‌ی اصلی MVC در اینجا Microsoft.AspNetCore.Mvc نام دارد و نه MVC6.
اینبار بسته‌هایی که restore می‌شوند، در مسیر اشتراکی C:\Users\user_name\.nuget\packages ذخیره خواهند شد.
یک نکته‌ی مهم:
قرار هست در نگارش‌های پس از RTM، فایل‌های project.json و xproj را جهت سازگاری با MSBuild، اندکی تغییر دهند (که این تغییرات به صورت خودکار توسط VS.NET انجام می‌شود). اطلاعات بیشتر
انتخاب فریم ورک‌های مختلف در فایل project.json
در قسمت قبل عنوان شد که ASP.NET Core را می‌توان هم برفراز NET Core. چندسکویی اجرا کرد و هم NET 4.6. مختص به ویندوز. این انتخاب‌ها در قسمت frameworks فایل project.json انجام می‌شوند:
در اینجا، netcoreapp1.0 به معنای برنامه‌‌ای است که برفراز NET Core. اجرا می‌شود. نام پیشین آن dnxcore50 بود (اگر مقالات قدیمی‌تر پیش از RTM را مطالعه کنید).
در اینجا اگر علاقمند بودید که از دات نت کامل مخصوص ویندوز نیز استفاده کنید، می‌توانید آن‌را در لیست فریم ورک‌ها اضافه نمائید (در این مثال، دات نت کامل 4.5.2 نیز ذکر شده‌است):
لیست کامل این اسامی را در مستندات NET Starndard می‌توانید مطالعه کنید و خلاصه‌ی آن به این صورت است:
- “netcoreapp1.0” برای معرفی و استفاده‌ی از NET Core 1.0. بکار می‌رود.
- جهت معرفی فریم ورک‌های کامل و ویندوزی دات نت، اسامی “net45”, “net451”, “net452”, “net46”, “net461” مجاز هستند.
- “portable-net45+win8” برای معرفی پروفایل‌های PCL یا portable class libraries بکار می‌رود.
- “dotnet5.6”, “dnxcore50” برای معرفی نگارش‌های پیش نمایش NET Core.، پیش از ارائه‌ی نگارش RTM استفاده می‌شوند.
- “netstandard1.2”, “netstandard1.5” کار معرفی برنامه‌های NET Standard Platform. را انجام می‌دهند.
بر این مبنا، dotnet5.6 ذکر شده‌ی در قسمت تنظیمات نگارش RTM، به این معنا است که قادر به استفاده‌ی از بسته‌های نیوگت و کتابخانه‌های تولید شده‌ی با نگارش‌های RC نیز خواهید بود (هرچند برنامه از netcoreapp1.0 استفاده می‌کند).
یک مثال: قسمت فریم ورک‌های فایل project.json را به نحو ذیل جهت معرفی دات نت 4.6.1 تغییر دهید:
لیست وابستگی‌های خاص این فریم ورک در خاصیت dependencies آن قابل ذکر است.
در این حالت پس از ذخیره‌ی فایل و شروع خودکار بازیابی وابستگی‌ها، با پیام خطای Package Microsoft.NETCore.App 1.0.0 is not compatible with net461 متوقف خواهید شد.
برای رفع این مشکل باید وابستگی Microsoft.NETCore.App را حذف کنید، چون با net461 سازگاری ندارد
فایل project.lock.json چیست؟
ذیل فایل project.json، فایل دیگری به نام project.lock.json نیز وجود دارد. اگر به محتوای آن دقت کنید، این فایل حاوی لیست دقیق بسته‌های نیوگت مورد استفاده‌ی توسط برنامه است و الزاما با آن‌چیزی که در فایل project.json قید شده، یکی نیست. از این جهت که در فایل project.json، قید می‌شود netcoreapp1.0؛ ولی این netcoreapp1.0 دقیقا شامل چه بسته‌هایی است؟ لیست کامل آنها را در این فایل می‌توانید مشاهده کنید.
در ابتدای این فایل یک خاصیت locked نیز وجود دارد که مقدار پیش فرض آن false است. اگر به true تنظیم شود، در حین restore وابستگی‌های برنامه، تنها از نگارش‌های ذکر شده‌ی در این فایل استفاده می‌شود. از این جهت که در فایل project.json می‌توان شماره نگارش‌ها را با * نیز مشخص کرد؛ مثلا *.1.0.0
پوشه‌ی جدید wwwroot و گره dependencies
یکی از پوشه‌های جدیدی که در ساختار پروژه‌ی ASP.NET Core معرفی شده‌است، wwwroot نام دارد:
از دیدگاه هاستینگ برنامه، این پوشه، پوشه‌ای است که در معرض دید عموم قرار می‌گیرد (وب روت). برای مثال فایل‌های ایستای اسکریپت، CSS، تصاویر و غیره باید در این پوشه قرار گیرند تا توسط دنیای خارج قابل دسترسی و استفاده شوند. بنابراین سورس کدهای برنامه خارج از این پوشه قرار می‌گیرند.
گره dependencies که ذیل پوشه‌ی wwwroot قرار گرفته‌است، جهت مدیریت این وابستگی‌های سمت کلاینت برنامه است. در اینجا می‌توان از NPM و یا Bower برای دریافت و به روز رسانی وابستگی‌های اسکریپتی و شیوه‌نامه‌های برنامه کمک گرفت (علاوه بر نیوگت که بهتر است صرفا جهت دریافت وابستگی‌های دات نتی استفاده شود).
یک مثال: فایل جدیدی را به نام bower.json به پروژه‌ی جاری با این محتوا اضافه کنید:
این نام‌ها استاندارد هستند. برای مثال اگر قصد استفاده‌ی از npm مربوط به node.js را داشته باشید، نام این فایل packag.json است (با ساختار خاص خودش) و هر دوی این‌ها را نیز می‌توانید با هم اضافه کنید و از این لحاظ محدودیتی وجود ندارد.
پس از اضافه شدن فایل bower.json، بلافاصله کار restore بسته‌ها از اینترنت شروع می‌شود:
و یا با کلیک راست بر روی گره dependencies، گزینه‌ی restore packages نیز وجود دارد.
فایل‌های نهایی دریافت شده را در پوشه‌ی bower_components خارج از wwwroot می‌توانید مشاهده کنید.
در مورد نحوه‌ی توزیع و دسترسی به فایل‌های استاتیک یک برنامه‌ی ASP.NET Core 1.0، نکات خاصی وجود دارند که در قسمت‌های بعد، بررسی خواهند شد.
یک نکته: اگر خواستید نام پوشه‌ی wwwroot را تغییر دهید، فایل جدیدی را به نام hosting.json با این محتوا به پروژه اضافه کنید:
در اینجا AppWebRoot نام دلخواه پوشه‌ی جدیدی است که نیاز است به ریشه‌ی پروژه اضافه نمائید تا بجای wwwroot پیش فرض استفاده شود.
نقطه‌ی آغازین برنامه کجاست؟
اگر به فایل project.json دقت کنید، چنین تنظیمی در آن موجود است:
true بودن مقدار تولید entry point به استفاده‌ی از فایلی به نام Program.cs بر می‌گردد؛ با این محتوا:
به این ترتیب، یک برنامه‌ی ASP.NET Core، دقیقا همانند سایر برنامه‌های NET Core. رفتار می‌کند و در اساس یک برنامه‌ی کنسول است.
این چند سطر، قسمتی از سورس کد ASP.NET Core 1.0 هستند. به این معنا که اگر مقدار خاصیت emitEntryPoint مساوی true بود، با این برنامه به شکل یک برنامه‌ی کنسول رفتار کن و در غیر اینصورت یک Dynamically Linked Library خواهد بود.
در فایل Program.cs تنظیماتی را مشاهده می‌کنید، در مورد راه اندازی Kestler که وب سرور بسیار سریع و چندسکویی کار با برنامه‌های ASP.NET Core 1.0 است و قسمت مهم دیگر آن به استفاده‌ی از کلاس Startup بر می‌گردد (()<UseStartup<Startup). این کلاس را در فایل جدید Startup.cs می‌توانید ملاحظه کنید که کار تنظیمات آغازین برنامه را انجام می‌دهد. اگر پیشتر با OWIN، در نگارش‌های قبلی ASP.NET کار کرده باشید، قسمتی از این فایل برای شما آشنا است:
در اینجا امکان دسترسی به تنظیمات برنامه، معرفی سرویس‌ها، middlewareها و غیره وجود دارند که هرکدام، در قسمت‌های آتی به تفصیل بررسی خواهند شد.
نقش فایل launchsetting.json
محتویات پیش فرض این فایل برای قالب empty پروژه‌های ASP.NET Core 1.0 به صورت ذیل است:
همانطور که مشاهده می‌کنید، در اینجا تنظیمات IIS Express قابل تغییر هستند. برای مثال port پیش فرض برنامه 7742 تنظیم شده‌است.
پروفایل‌هایی که در اینجا ذکر شده‌اند، در تنظیمات پروژه نیز قابل مشاهده هستند: (کلیک راست بر روی پروژه و مشاهده‌ی properties آن و یا دوبار کلیک بر روی گره properties)
به علاوه امکان انتخاب این پروفایل‌ها در زمان آغاز برنامه نیز وجود دارند:
نکته‌ی مهم تمام این موارد به قسمت environment variable قابل مشاهده‌ی در تصاویر فوق بر می‌گردد. این متغیر محیطی می‌تواند سه مقدار Development ، Staging و Production را داشته باشد و بر اساس این متغیر و مقدار آن، می‌توان پروفایل جدیدی را تشکیل داد. زمانیکه برنامه بر اساس پروفایل خاصی بارگذاری می‌شود، اینکه چه متغیر محیطی انتخاب شده‌است، در کلاس Startup قابل استخراج و بررسی بوده و بر این اساس می‌توان اقدامات خاصی را انجام داد. برای مثال تنظیمات خاصی را بارگذاری کرد و یا صفحات ویژه‌ای را فعال و غیرفعال کرد (این موارد را در قسمت‌های بعدی مرور می‌کنیم).
همچنین در اینجا به ازای هر پروفایل مختلف می‌توان Url آغازین یا launch url و پورت آن‌را مجزا درنظر گرفت و یا از وب سرور دیگری استفاده کرد.
.NET Core -> ASP.NET Core Web Application (.NET Core) -> Select `Empty` Template
در اینجا نقش Solution همانند نگارش‌های قبلی ویژوال استودیو است: ظرفی است برای ساماندهی موارد مورد نیاز جهت تشکیل یک برنامه‌ی وب و شامل مواردی است مانند پروژه‌ها، تنظیمات آنها و غیره. بنابراین هنوز در اینجا فایل sln. تشکیل می‌شود.
نقش فایل global.json
زمانیکه یک پروژه‌ی جدید ASP.NET Core 1.0 را آغاز می‌کنیم، ساختار پوشه‌های آن به صورت زیر هستند:
در اینجا هنوز فایل sln. قابل مشاهده است. همچنین در اینجا فایل جدیدی به نام global.json نیز وجود دارد، با این محتوا:
{
"projects": [ "src", "test" ],
"sdk": {
"version": "1.0.0-preview2-003121"
}
} خاصیت projects در اینجا به صورت یک آرایه تعریف شده‌است و بیانگر محل واقع شدن پوشه‌های اصلی پروژه‌ی جاری هستند. پوشه‌ی src یا source را در تصویر فوق مشاهده می‌کنید و محلی است که سورس‌های برنامه در آن قرار می‌گیرند. یک پوشه‌ی test نیز در اینجا ذکر شده‌است و اگر در حین ایجاد پروژه، گزینه‌ی ایجاد unit tests را هم انتخاب کرده باشید، این پوشه‌ی مخصوص نیز ایجاد خواهد شد.
نکته‌ی مهم اینجا است، هرکدی که درون پوشه‌های ذکر شده‌ی در اینجا قرار نگیرد، قابلیت build را نخواهد داشت. به عبارتی این نسخه‌ی از ASP.NET پوشه‌ها را قسمتی از پروژه به حساب می‌آورد. در نگارش‌های قبلی ASP.NET، مداخل تعریف فایل‌های منتسب به هر پروژه، درون فایلی با پسوند csproj. قرار می‌گرفتند. معادل این فایل در اینجا اینبار پسوند xproj را دارد و اگر آن‌را با یک ادیتور متنی باز کنید، فاقد تعاریف مداخل فایل‌های پروژه است.
در این نگارش جدید اگر فایلی را به پوشه‌ی src اضافه کنید یا حذف کنید، بلافاصله در solution explorer ظاهر و یا حذف خواهد شد.
یک آزمایش: به صورت معمول از طریق windows explorer به پوشه‌ی src برنامه وارد شده و فایل پیش فرض Project_Readme.html را حذف کنید. سپس به solution explorer ویژوال استودیو دقت کنید. مشاهده خواهید کرد که این فایل، بلافاصله از آن حذف می‌شود. در ادامه به recycle bin ویندوز مراجعه کرده و این فایل حذف شده را restore کنید تا مجددا به پوشه‌ی src برنامه اضافه شود. اینبار نیز افزوده شدن خودکار و بلافاصله‌ی این فایل را می‌توان در solution explorer مشاهده کرد.
بنابراین ساختار مدیریت فایل‌های این نگارش از ASP.NET در ویژوال استودیو، بسیار شبیه به ساختار مدیریت فایل‌های VSCode شده‌است که آن نیز بر اساس پوشه‌ها کار می‌کند و یک پوشه و تمام محتوای آن‌را به صورت پیش فرض به عنوان یک پروژه می‌شناسد. به همین جهت دیگر فایل csproj ایی در اینجا وجود ندارد و file system همان project system است.
یک نکته: در اینجا مسیرهای مطلق را نیز می‌توان ذکر کرد:
"projects": [ "src", "test", "c:\\sources\\Configuration\\src" ],
کامپایل خودکار پروژه در ASP.NET Core 1.0
علاوه بر تشخیص خودکار کم و زیاد شدن فایل‌های سیستمی پروژه، بدون نیاز به Add new item کردن آنها در ویژوال استودیو، اگر سورس‌های برنامه را نیز تغییر دهید، فایل سورس جدیدی را اضافه کنید و یا فایل سورس موجودی را حذف کنید، کل پروژه به صورت خودکار کامپایل می‌شود و نیازی نیست اینکار را به صورت دستی انجام دهید.
یک آزمایش: برنامه را از طریق منوی debug و گزینه‌ی start without debugging اجرا کنید. اگر برنامه را در حالت معمول debug->start debugging اجرا کنید، حالت کامپایل خودکار را مشاهده نخواهید کرد. در اینجا (پس از start without debugging) یک چنین خروجی را مشاهده خواهید کرد:
این خروجی حاصل اجرای کدهای درون فایل Startup.cs برنامه است:
app.Run(async (context) =>
{
await context.Response.WriteAsync("Hello World!");
}); await context.Response.WriteAsync("Hello DNT!"); این مساله قابلیت استفاده‌ی از ASP.NET Core را در سایر ادیتورهای موجود، مانند VSCode سهولت می‌بخشد.
نقش فایل project.json
فایل جدید project.json مهم‌ترین فایل تنظیمات یک پروژه‌ی ASP.NET Core است و مهم‌ترین قسمت آن، قسمت وابستگی‌های آن است:
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.0",
"type": "platform"
},
"Microsoft.AspNetCore.Diagnostics": "1.0.0",
"Microsoft.AspNetCore.Server.IISIntegration": "1.0.0",
"Microsoft.AspNetCore.Server.Kestrel": "1.0.0",
"Microsoft.Extensions.Logging.Console": "1.0.0"
}, در نگارش‌های قبلی ASP.NET، فایلی XML ایی به نام packages.config حاوی تعاریف مداخل بسته‌های نیوگت برنامه بود. این فایل در اینجا جزئی از محتوای فایل project.json در قسمت dependencies آن است.
با قسمت وابستگی‌های این فایل، به دو طریق می‌توان کار کرد:
الف) ویرایش مستقیم این فایل که به همراه intellisense نیز هست. با افزودن مداخل جدید به این فایل و ذخیره کردن آن، بلافاصله کار restore و دریافت و نصب آنها آغاز می‌شود:
ب) از طریق NuGet package manager
روش دیگر کار با وابستگی‌ها، کلیک راست بر روی گره references و انتخاب گزینه‌ی manage nuget packages است:
برای نمونه جهت نصب ASP.NET MVC 6 این مراحل باید طی شوند:
ابتدا برگه‌ی browse را انتخاب کنید و سپس تیک مربوط به include prerelease را نیز انتخاب نمائید.
البته بسته‌ی اصلی MVC در اینجا Microsoft.AspNetCore.Mvc نام دارد و نه MVC6.
اینبار بسته‌هایی که restore می‌شوند، در مسیر اشتراکی C:\Users\user_name\.nuget\packages ذخیره خواهند شد.
یک نکته‌ی مهم:
قرار هست در نگارش‌های پس از RTM، فایل‌های project.json و xproj را جهت سازگاری با MSBuild، اندکی تغییر دهند (که این تغییرات به صورت خودکار توسط VS.NET انجام می‌شود). اطلاعات بیشتر
انتخاب فریم ورک‌های مختلف در فایل project.json
در قسمت قبل عنوان شد که ASP.NET Core را می‌توان هم برفراز NET Core. چندسکویی اجرا کرد و هم NET 4.6. مختص به ویندوز. این انتخاب‌ها در قسمت frameworks فایل project.json انجام می‌شوند:
"frameworks": {
"netcoreapp1.0": {
"imports": [
"dotnet5.6",
"portable-net45+win8"
]
}
}, در اینجا اگر علاقمند بودید که از دات نت کامل مخصوص ویندوز نیز استفاده کنید، می‌توانید آن‌را در لیست فریم ورک‌ها اضافه نمائید (در این مثال، دات نت کامل 4.5.2 نیز ذکر شده‌است):
"frameworks": {
"netcoreapp1.0": {
},
"net452": {
}
} - “netcoreapp1.0” برای معرفی و استفاده‌ی از NET Core 1.0. بکار می‌رود.
- جهت معرفی فریم ورک‌های کامل و ویندوزی دات نت، اسامی “net45”, “net451”, “net452”, “net46”, “net461” مجاز هستند.
- “portable-net45+win8” برای معرفی پروفایل‌های PCL یا portable class libraries بکار می‌رود.
- “dotnet5.6”, “dnxcore50” برای معرفی نگارش‌های پیش نمایش NET Core.، پیش از ارائه‌ی نگارش RTM استفاده می‌شوند.
- “netstandard1.2”, “netstandard1.5” کار معرفی برنامه‌های NET Standard Platform. را انجام می‌دهند.
بر این مبنا، dotnet5.6 ذکر شده‌ی در قسمت تنظیمات نگارش RTM، به این معنا است که قادر به استفاده‌ی از بسته‌های نیوگت و کتابخانه‌های تولید شده‌ی با نگارش‌های RC نیز خواهید بود (هرچند برنامه از netcoreapp1.0 استفاده می‌کند).
یک مثال: قسمت فریم ورک‌های فایل project.json را به نحو ذیل جهت معرفی دات نت 4.6.1 تغییر دهید:
"frameworks": {
"netcoreapp1.0": {
"imports": [
"dotnet5.6",
"portable-net45+win8"
]
},
"net461": {
"imports": [
"portable-net45+win8"
],
"dependencies": {
}
}
}, در این حالت پس از ذخیره‌ی فایل و شروع خودکار بازیابی وابستگی‌ها، با پیام خطای Package Microsoft.NETCore.App 1.0.0 is not compatible with net461 متوقف خواهید شد.
برای رفع این مشکل باید وابستگی Microsoft.NETCore.App را حذف کنید، چون با net461 سازگاری ندارد
"dependencies": {
//"Microsoft.NETCore.App": {
// "version": "1.0.0",
// "type": "platform"
//}, 
فایل project.lock.json چیست؟
ذیل فایل project.json، فایل دیگری به نام project.lock.json نیز وجود دارد. اگر به محتوای آن دقت کنید، این فایل حاوی لیست دقیق بسته‌های نیوگت مورد استفاده‌ی توسط برنامه است و الزاما با آن‌چیزی که در فایل project.json قید شده، یکی نیست. از این جهت که در فایل project.json، قید می‌شود netcoreapp1.0؛ ولی این netcoreapp1.0 دقیقا شامل چه بسته‌هایی است؟ لیست کامل آنها را در این فایل می‌توانید مشاهده کنید.
در ابتدای این فایل یک خاصیت locked نیز وجود دارد که مقدار پیش فرض آن false است. اگر به true تنظیم شود، در حین restore وابستگی‌های برنامه، تنها از نگارش‌های ذکر شده‌ی در این فایل استفاده می‌شود. از این جهت که در فایل project.json می‌توان شماره نگارش‌ها را با * نیز مشخص کرد؛ مثلا *.1.0.0
پوشه‌ی جدید wwwroot و گره dependencies
یکی از پوشه‌های جدیدی که در ساختار پروژه‌ی ASP.NET Core معرفی شده‌است، wwwroot نام دارد:
از دیدگاه هاستینگ برنامه، این پوشه، پوشه‌ای است که در معرض دید عموم قرار می‌گیرد (وب روت). برای مثال فایل‌های ایستای اسکریپت، CSS، تصاویر و غیره باید در این پوشه قرار گیرند تا توسط دنیای خارج قابل دسترسی و استفاده شوند. بنابراین سورس کدهای برنامه خارج از این پوشه قرار می‌گیرند.
گره dependencies که ذیل پوشه‌ی wwwroot قرار گرفته‌است، جهت مدیریت این وابستگی‌های سمت کلاینت برنامه است. در اینجا می‌توان از NPM و یا Bower برای دریافت و به روز رسانی وابستگی‌های اسکریپتی و شیوه‌نامه‌های برنامه کمک گرفت (علاوه بر نیوگت که بهتر است صرفا جهت دریافت وابستگی‌های دات نتی استفاده شود).
یک مثال: فایل جدیدی را به نام bower.json به پروژه‌ی جاری با این محتوا اضافه کنید:
{
"name": "asp.net",
"private": true,
"dependencies": {
"bootstrap": "3.3.6",
"jquery": "2.2.0",
"jquery-validation": "1.14.0",
"jquery-validation-unobtrusive": "3.2.6"
}
} پس از اضافه شدن فایل bower.json، بلافاصله کار restore بسته‌ها از اینترنت شروع می‌شود:
و یا با کلیک راست بر روی گره dependencies، گزینه‌ی restore packages نیز وجود دارد.
فایل‌های نهایی دریافت شده را در پوشه‌ی bower_components خارج از wwwroot می‌توانید مشاهده کنید.
در مورد نحوه‌ی توزیع و دسترسی به فایل‌های استاتیک یک برنامه‌ی ASP.NET Core 1.0، نکات خاصی وجود دارند که در قسمت‌های بعد، بررسی خواهند شد.
یک نکته: اگر خواستید نام پوشه‌ی wwwroot را تغییر دهید، فایل جدیدی را به نام hosting.json با این محتوا به پروژه اضافه کنید:
{
"webroot":"AppWebRoot"
} 
نقطه‌ی آغازین برنامه کجاست؟
اگر به فایل project.json دقت کنید، چنین تنظیمی در آن موجود است:
"buildOptions": {
"emitEntryPoint": true,
"preserveCompilationContext": true
}, public static void Main(string[] args)
{
var host = new WebHostBuilder()
.UseKestrel()
.UseContentRoot(Directory.GetCurrentDirectory())
.UseIISIntegration()
.UseStartup<Startup>()
.Build();
host.Run();
} var outputKind = compilerOptions.EmitEntryPoint.GetValueOrDefault() ? OutputKind.ConsoleApplication : OutputKind.DynamicallyLinkedLibrary;
در فایل Program.cs تنظیماتی را مشاهده می‌کنید، در مورد راه اندازی Kestler که وب سرور بسیار سریع و چندسکویی کار با برنامه‌های ASP.NET Core 1.0 است و قسمت مهم دیگر آن به استفاده‌ی از کلاس Startup بر می‌گردد (()<UseStartup<Startup). این کلاس را در فایل جدید Startup.cs می‌توانید ملاحظه کنید که کار تنظیمات آغازین برنامه را انجام می‌دهد. اگر پیشتر با OWIN، در نگارش‌های قبلی ASP.NET کار کرده باشید، قسمتی از این فایل برای شما آشنا است:
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
}
public void Configure(IApplicationBuilder app)
{
app.Run(async (context) =>
{
await context.Response.WriteAsync("Hello World!");
});
}
} نقش فایل launchsetting.json
محتویات پیش فرض این فایل برای قالب empty پروژه‌های ASP.NET Core 1.0 به صورت ذیل است:
{
"iisSettings": {
"windowsAuthentication": false,
"anonymousAuthentication": true,
"iisExpress": {
"applicationUrl": "http://localhost:7742/",
"sslPort": 0
}
},
"profiles": {
"IIS Express": {
"commandName": "IISExpress",
"launchBrowser": true,
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
},
"Core1RtmEmptyTest": {
"commandName": "Project",
"launchBrowser": true,
"launchUrl": "http://localhost:5000",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
}
}
} پروفایل‌هایی که در اینجا ذکر شده‌اند، در تنظیمات پروژه نیز قابل مشاهده هستند: (کلیک راست بر روی پروژه و مشاهده‌ی properties آن و یا دوبار کلیک بر روی گره properties)
به علاوه امکان انتخاب این پروفایل‌ها در زمان آغاز برنامه نیز وجود دارند:
نکته‌ی مهم تمام این موارد به قسمت environment variable قابل مشاهده‌ی در تصاویر فوق بر می‌گردد. این متغیر محیطی می‌تواند سه مقدار Development ، Staging و Production را داشته باشد و بر اساس این متغیر و مقدار آن، می‌توان پروفایل جدیدی را تشکیل داد. زمانیکه برنامه بر اساس پروفایل خاصی بارگذاری می‌شود، اینکه چه متغیر محیطی انتخاب شده‌است، در کلاس Startup قابل استخراج و بررسی بوده و بر این اساس می‌توان اقدامات خاصی را انجام داد. برای مثال تنظیمات خاصی را بارگذاری کرد و یا صفحات ویژه‌ای را فعال و غیرفعال کرد (این موارد را در قسمت‌های بعدی مرور می‌کنیم).
همچنین در اینجا به ازای هر پروفایل مختلف می‌توان Url آغازین یا launch url و پورت آن‌را مجزا درنظر گرفت و یا از وب سرور دیگری استفاده کرد.
هدف از توابع خطی(Inline)
استفاده از توابع، مقداری بر زمان اجرای برنامه می‌افزاید؛ هرچند که این زمان بسیار کم و در حد میلی ثانیه است، اما باری را بر روی برنامه قرار می‌دهد و علت این تاخیر زمانی این است که در فراخوانی و اعلان توابع، کامپایلر یک کپی از تابع مورد نظر را در حافظه قرار می‌دهد و در فراخوانی تابع، به آدرس مذکور مراجعه می‌کند و در عین حال آدرس موقعیت توقف دستورات در تابع main را نیز ذخیره می‌کند تا پس از پایان تابع، به آدرس قبل برگردد و ادامه‌ی دستورات را اجرا کند. در نتیجه این آدرس دهی‌ها و نقل و انتقالات بین آنها بار زمانی را در برنامه ایجاد می‌کند که در صورت زیاد بودن توابع در برنامه و تعداد فراخوانی‌های لازم، زمان قابل توجهی خواهد شد.
یکی از تکنیک‌های بهینه که برای کاهش زمان اجرای برنامه توسط کامپایلر‌ها استفاده می‌شود استفاده از توابع خطی (inline) است. این امکان در زبان C با عنوان توابع ماکرو(Macro function) و در ++C با عنوان توابع خطی (inline function) وجود دارد.
در واقع توابع خطی به کامپایلر پیشنهاد می‌دهند، زمانی که سربار فراخوانی تابع بیشتر از سربار بدنه خود متد باشد، برای کاهش هزینه و زمان اجرای برنامه از تابع به صورت خطی استفاده کند و یک کپی از بنده‌ی تابع را در قسمتی که تابع ما فراخوانی شده است، قرار دهد که مورد آدرس دهی از میان خواهد رفت!
نمونه ای از پیاده سازی این تکنیک در زبان ++C :
inline type name(parameters)
{
...
} بررسی متدهای خطی در سی شارپ
به مثال زیر توجه کنید:
قسمت‌های getter و setter مربوط به پراپرتی‌ها سربار اضافی بر کلاس Vector می‌افزایند. این موضوع شاید آنچنان مسئله‌ی مهمی نباشد. ولی فرض کنید این پراپرتی‌ها به شکل زیر داخل حلقه‌ای طولانی قرار گیرند. اگر با استفاده از یک پروفایلر زمان اجرای برنامه را زیر نظر بگیرید، خواهید دید که بیش از 90 درصد آن صرف فراخوانی‌های متدهای بخش‌های get , set پراپرتی‌ها است. برای این منظور باید مطمئن شویم که فراخوانی این متدها، به صورت خطی صورت می‌گیرد!
public class Vector
{
public double X { get; set; }
public double Y { get; set; }
public double Z { get; set; }
// ...
} برای این منظور آزمایشی را انجام می‌دهیم. فرض کنید کلاسی را به شکل زیر داشته باشیم:
public class MyClass
{
public int A { get; set; }
public int C;
} static void Main()
{
MyClass target = new MyClass();
int a = target.A;
Console.WriteLine("A = {0}", a);
int c = target.C;
Console.WriteLine("C = {0}", c);
} int a = target.A;
0000003e mov ecx,edi
00000040 cmp dword ptr [ecx],ecx
00000042 call dword ptr ds:[05FA29A8h]
00000048 mov esi,eax
0000004a mov dword ptr [esp+4],esi
int c = target.C;
00000098 mov edi,dword ptr [edi+4]
MyClass.get_A() looks like this:
00000000 push esi
00000001 mov esi,ecx
00000003 cmp dword ptr ds:[03B701DCh],0
0000000a je 00000011
0000000c call 76BA6BA7
00000011 mov eax,dword ptr [esi+0Ch]
00000014 pop esi
00000015 ret چه اتفاقی افتاده است؟
کامپایلر سی شارپ در زمان کامپایل، کدهای برنامه را به کدهای IL تبدیل می‌کند و JITکامپایلر، این کدهای IL را گرفته و کد ساده‌ی ماشین را تولید می‌کند. لذا به دلیل اینکه JIT با معماری پردازنده آشنایی کافی دارد، مسئولیت تصمیم گیری اینکه کدام متد به صورت خطی فراخوانی شود برعهده‌ی آن است. در واقع این JIT است که تشخیص می‌دهد که آیا فراخونی متد به صورت خطی مناسب است یا نه و به صورت یک معاوضه کار بین خط لوله دستورالعمل‌ها و کش است.
اگر شما برنامه‌ی خود را با (F5) و همگام با دیباگ اجرا کنید، تمام بهینه سازی‌های JIT که Inline Method هم یکی از آنهاست، از کار خواهند افتاد. برای مشاهده‌ی کد بهینه شده باید با بدون دیباگ (CTRL+F5) برنامه خود را اجرا کنید که در آن صورت مشاهده خواهید کرد، متد getter مربوط به پراپرتی A به صورت خطی استفاده شده است.
int a = target.A; 00000024 mov ebx,dword ptr [edi+0Ch]
JIT محدودیت هایی برای فراخونی به صورت خطی متدها دارد :
- متد هایی که حجم کد IL آنها بیشتر از 32 بایت است.
- متدهای بازگشتی.
- متدهایی که با اتریبیوت MethodImpl علامتگذاری شدند و MethodImplOptions.NoInlining اعمال شده بر آن
- متدهای virtual
- متدهایی که دارای کد مدیریت خطا هستند
- Methods that take a large value type as a parameter
- Methods with complicated flowgraphs
برای اینکه در سی شارپ به کامپایلر اعلام کنیم تا متد مورد نظر به صورت خطی مورد استفاده قرار گیرد، در دات نت 4.5 توسط اتریبیوت MethodImpl و اعمال MethodImplOptions.AggressiveInlining که یک نوع شمارشی است می‌توان این کار را انجام داد. مثال:
using System;
using System.Diagnostics;
using System.Runtime.CompilerServices;
class Program
{
const int _max = 10000000;
static void Main()
{
// ... Compile the methods.
Method1();
Method2();
int sum = 0;
var s1 = Stopwatch.StartNew();
for (int i = 0; i < _max; i++)
{
sum += Method1();
}
s1.Stop();
var s2 = Stopwatch.StartNew();
for (int i = 0; i < _max; i++)
{
sum += Method2();
}
s2.Stop();
Console.WriteLine(((double)(s1.Elapsed.TotalMilliseconds * 1000000) /
_max).ToString("0.00 ns"));
Console.WriteLine(((double)(s2.Elapsed.TotalMilliseconds * 1000000) /
_max).ToString("0.00 ns"));
Console.Read();
}
static int Method1()
{
// ... No inlining suggestion.
return "one".Length + "two".Length + "three".Length +
"four".Length + "five".Length + "six".Length +
"seven".Length + "eight".Length + "nine".Length +
"ten".Length;
}
[MethodImpl(MethodImplOptions.AggressiveInlining)]
static int Method2()
{
// ... Aggressive inlining.
return "one".Length + "two".Length + "three".Length +
"four".Length + "five".Length + "six".Length +
"seven".Length + "eight".Length + "nine".Length +
"ten".Length;
}
}
Output
7.34 ns No options
0.32 ns MethodImplOptions.AggressiveInlining مطالعه بیشتر:
دات نت 7 به همراه یک Regex Source Generator توکار است که به کمک آن می‌توان عبارات باقاعده را تبدیل به کدهای سی‌شارپ معادل آنها کرد و پیش از اجرای برنامه، آنها را کامپایل و جزئی از خروجی نهایی نمود. این روش نسبت به روش پیشین تولید کدهای معادل عبارات باقاعده در زمان اجرای برنامه، از مزایای زیر برخوردار است:
- اجرای یک عبارت باقاعده سریعتر خواهد شد. در این حالت دیگر نیازی نیست تا در حین اجرای برنامه، منتظر پردازش و تولید کدهای سی‌شارپ معادل آن شد.
- کدهای تولیدی پیش از کامپایل برنامه، از مزایای بهینه سازی ویژه‌ای برخوردار می‌شوند که پیشتر تنها با ذکر پرچم RegexOptions.Compiled در زمان اجرا میسر می‌شدند.
- بعضی از سکوهای کاری مانند iOS، از تولید کد در زمان اجرای برنامه پشتیبانی نمی‌کنند. در این حالت یک تولید کننده‌ی کد سی‌شارپ معادل در زمان کامپایل برنامه، حداکثر کارآیی را برای اینگونه سکوهای کاری به ارمغان می‌آورد.
- امکان مطالعه‌ی کدهای سی‌شارپ تولیدی معادل یک عبارت باقاعده، برای اولین بار پیش از اجرای برنامه میسر شده‌است.
- کدهای تولیدی معادل، قابلیت دیباگ دارند.
- می‌توان با مطالعه‌ی این کدها، نکات جدیدی را فرا گرفت!
چه عبارت باقاعده‌ای را می‌توان به Regex source generators تبدیل کرد؟
برای استفاده از این تولید کننده‌ی کدهای معادل عبارات باقاعده، باید از NET 7. و C# 11 استفاده کرد. همچنین تمام پارامترهای Regex تعریف شده نیز باید ثابت باشند. برای نمونه در دو مثال زیر، در اولی، pattern ثابت است و در دومی هم pattern و هم سایر تنظیمات ذکر شده؛ بنابراین قابلیت تبدیل به روش استفاده از تولید کننده‌های کد را دارند:
اما مثال زیر خیر؛ در این مثال چون pattern یک متغیر است، امکان تبدیل آن به روش تولید کننده‌ی خودکار کدهای معادل وجود ندارد:
روش استفاده از Regex source generators
برای تبدیل مثال‌هایی که عنوان شدند به نمونه‌ی source generator، باید ابتدا یک partial method مزین شده‌ی به ویژگی [GeneratedRegex] را ایجاد کرد؛ برای نمونه:
سپس می‌توان از این partial method، که کدهای آن به صورت خودکار تولید می‌شوند، در قسمت‌های مختلف برنامه استفاده کرد؛ برای مثال:
اگر علاقمند بودید تا کد معادل این partial method را مشاهده کنید، بر روی آن کلیک راست کرده و گزینه‌ی «Go to Definition» را انتخاب کنید (و یا نگه داشتن دکمه‌ی ctrl و سپس کلیک بر روی تعریف partial متد):
همچنین ابزارهای refactoring خودکاری نیز در IDEهای جدید برای این منظور تعبیه شده‌اند تا بتوان به سرعت کدهای قدیمی را به روش source generators تبدیل کرد:
و partial method تولیدی، اینبار به همراه توضیح کامل نحوه‌ی عملکرد عبارت باقاعده‌ی مورد استفاده نیز هست:
- اجرای یک عبارت باقاعده سریعتر خواهد شد. در این حالت دیگر نیازی نیست تا در حین اجرای برنامه، منتظر پردازش و تولید کدهای سی‌شارپ معادل آن شد.
- کدهای تولیدی پیش از کامپایل برنامه، از مزایای بهینه سازی ویژه‌ای برخوردار می‌شوند که پیشتر تنها با ذکر پرچم RegexOptions.Compiled در زمان اجرا میسر می‌شدند.
- بعضی از سکوهای کاری مانند iOS، از تولید کد در زمان اجرای برنامه پشتیبانی نمی‌کنند. در این حالت یک تولید کننده‌ی کد سی‌شارپ معادل در زمان کامپایل برنامه، حداکثر کارآیی را برای اینگونه سکوهای کاری به ارمغان می‌آورد.
- امکان مطالعه‌ی کدهای سی‌شارپ تولیدی معادل یک عبارت باقاعده، برای اولین بار پیش از اجرای برنامه میسر شده‌است.
- کدهای تولیدی معادل، قابلیت دیباگ دارند.
- می‌توان با مطالعه‌ی این کدها، نکات جدیدی را فرا گرفت!
چه عبارت باقاعده‌ای را می‌توان به Regex source generators تبدیل کرد؟
برای استفاده از این تولید کننده‌ی کدهای معادل عبارات باقاعده، باید از NET 7. و C# 11 استفاده کرد. همچنین تمام پارامترهای Regex تعریف شده نیز باید ثابت باشند. برای نمونه در دو مثال زیر، در اولی، pattern ثابت است و در دومی هم pattern و هم سایر تنظیمات ذکر شده؛ بنابراین قابلیت تبدیل به روش استفاده از تولید کننده‌های کد را دارند:
if(new Regex("[a-z]+").IsMatch("abc")){}
if(Regex.IsMatch(value, "[a-z]+", RegexOptions.CultureInvariant, TimeSpan.FromSeconds(1))){} public static bool Match(string value, string pattern)
{
return Regex.IsMatch(value, pattern);
} روش استفاده از Regex source generators
برای تبدیل مثال‌هایی که عنوان شدند به نمونه‌ی source generator، باید ابتدا یک partial method مزین شده‌ی به ویژگی [GeneratedRegex] را ایجاد کرد؛ برای نمونه:
public partial class MyRegexes
{
[GeneratedRegex("^[a-z]+$", RegexOptions.CultureInvariant, 1000)]
public static partial Regex LowercaseLettersRegex();
} public class RegexTests
{
public static bool IsLowercase(string value) => MyRegexes.LowercaseLettersRegex().IsMatch(value);
} 
همچنین ابزارهای refactoring خودکاری نیز در IDEهای جدید برای این منظور تعبیه شده‌اند تا بتوان به سرعت کدهای قدیمی را به روش source generators تبدیل کرد:
و partial method تولیدی، اینبار به همراه توضیح کامل نحوه‌ی عملکرد عبارت باقاعده‌ی مورد استفاده نیز هست:
کامپایلر سی‌شارپ با ++C نوشته شده. الان این کامپایلر و مابقی کامپایلرهای دات نتی رو با خود دات نت و سی‌شارپ بازنویسی کرده‌اند؛ تحت پروژه‌ای به نام Roslyn. مزیت آن امکان استفاده وسیع از این کامپایلر به صورت سرویس به برنامه نویس‌های دات نت است و همچنین داخل خود VS.NET برای بهبود عملکرد IDE، کارهای Refactoring و آنالیزهای پیشرفته کدها.
غیر فعال کردن حالت debug در محصول نهایی
myApp.config(['$compileProvider', function ($compileProvider) {
$compileProvider.debugInfoEnabled(false);
}]); 