یک نکتهی تکمیلی: امکان مشاهدهی کدهای تولیدی توسط Source Generators، به آخرین نگارش Rider هم ذیل قسمت مشاهدهی Dependencies، اضافه شدهاست:
اشتراکها
منابع مطالعاتی در مورد Roslyn
اشتراکها
سری آموزشی مقدمات Typescript
Source Generators که به همراه C# 9.0 ارائه شدند، یک فناوری نوین meta-programming است و به عنوان جزئی از پروسهی استاندارد کامپایل برنامه، ظاهر میشود. هدف اصلی از ارائهی Source Generators، تولید کدهای تکراری مورد استفادهی در برنامهها است. برای مثال بجای انجام کارهای تکراری مانند پیاده سازی متدهای GetHashCode، ToString و یا حتی یک AutoMapper و یا Serializer، برای تمام کلاسهای برنامه، Source Generators میتوانند آنها را به صورت خودکار پیاده سازی کنند و همچنین با هر تغییری در کدهای کلاسها، این پیاده سازیها به صورت خودکار به روز خواهند شد. مزیت این روش نه فقط تولید پویای کدها است، بلکه سبب بهبود کارآیی برنامه هم خواهند شد؛ از این جهت که برای مثال میتوان اعمالی مانند Serialization را بدون انجام Reflection در زمان اجرا، توسط آنها پیاده سازی کرد.
زمانیکه پروسهی کامپایل برنامه شروع میشود، در این بین، به مرحلهی جدیدی به نام «تولید کدها» میرسد. در این حالت، کامپایلر تمام اطلاعاتی را که در مورد پروژهی جاری در اختیار دارد، به تولید کنندهی کد معرفی شدهی به آن ارائه میدهد. بر اساس این اطلاعات غنی ارائه شدهی توسط کامپایلر، تولید کنندهی کد، شروع به تولید کدهای جدیدی کرده و آنها را در اختیار ادامهی پروسهی کامپایل، قرار میدهد. پس از آن، کامپایلر با این کدهای جدید، همانند سایر کدهای موجود در پروژه رفتار کرده و عملکرد عادی خودش را ادامه میدهد.
یک برنامه میتواند از چندین Source Generators نیز استفاده کند که روش قرار گرفتن آنها را در پروسهی کامپایل، در شکل زیر مشاهده میکنید:
Source Generators از یکدیگر کاملا مستقل هستند و اطلاعات آنها Immutable است. یعنی نمیتوان اطلاعات تولیدی توسط یک Source Generator را در دیگری تغییر داد و تمام فایلهای تولیدی توسط انواع Source Generators موجود، به پروسهی کامپایل نهایی اضافه میشوند. هرچند زمانیکه فایلی توسط یک تولید کنندهی کد، به کامپایلر اضافه میشود، بلافاصله اطلاعات آن در کل برنامه و IDE و تمام Source Generators موجود دیگر، قابل مشاهده و استفاده است.
مقایسهای بین تولید کنندههای کد و فناوری IL Weaving
Source Generators، تنها راه و روش تولید کد، نیستند و پیش از آن روشهایی مانند استفاده از T4 templates ، Fody ، PostSharp و امثال آن نیز ارائه شدهاست. در ادامه مقایسهای را بین تولید کنندههای کد و فناوری IL Weaving را که پیشتر در سری AOP در این سایت مطالعه کردهاید، مشاهده میکنید:
تولید کنندههای کد:
- تنها میتوانند فایلهای جدید را اضافه کنند. یعنی «در حین» پروسهی کامپایل ظاهر میشوند و به عنوان یک مکمل، تاثیر گذارند. برای مثال نمیتوانند محتوای یک خاصیت یا متد از پیش موجود را تغییر دهند. اما میتوانند هر نوع کد partial ای را «تکمیل» کنند.
- محتوای اضافه شدهی توسط یک تولید کنندهی کد، بلافاصله توسط Compiler شناسایی شده و بررسی میشود و همچنین در Intellisense ظاهر شده و به سادگی قابل دسترسی است. همچنین، قابلیت دیباگ نیز دارد.
IL Weaving:
- میتوانند bytecode برنامه را تغییر دهند. یعنی «پس از» پروسهی کامپایل ظاهر شده و کدهایی را به اسمبلی نهایی تولید شده اضافه میکنند. در این حالت محدودیتی از لحاظ محل تغییر کدها وجود ندارد. برای مثال میتوان بدنهی یک متد یا خاصیت را بطور کامل بازنویسی کرد و کارکردهایی مانند تزریق کدهای caching و logging را دارند.
- کدهایی که توسط این پروسه اضافه میشوند، در حین کدنویسی متداول، قابلیت دسترسی ندارند؛ چون پس از پروسهی کامپایل، به فایل باینری نهایی تولیدی، اضافه میشوند. بنابراین قابلیت دیباگ به همراه سایر کدهای برنامه را نیز ندارند. به علاوه چون توسط کامپایلر در حین پروسهی کامپایل، بررسی نمیشوند، ممکن است به همراه قطعه کدهای غیرقابل اجرایی نیز باشند و دیباگ آنها بسیار مشکل است.
آیندهی Reflection به چه صورتی خواهد شد؟
هرچند Reflection کار تولید کدی را انجام نمیدهد، اما یکی از کارهای متداول با آن، یافتن و محاسبهی اطلاعات خواص و فیلدهای اشیاء، در زمان اجرا است و مزیت کار کردن با آن نیز این است که اگر خاصیتی یا فیلدی تغییر کند، نیازی به بازنویسی قسمتهای پیاده سازی شدهی با Reflection نیست. به همین جهت برای مثال تقریبا تمام کتابخانههای Serialization، از Reflection برای پیاده سازی اعمال خود استفاده میکنند.
امروز، تمام اینگونه عملیات را توسط Source Generators نیز میتوان انجام داد و این فناوری جدید، قابلیت به روز رسانی خودکار کدهای تولیدی را با کم و زیاد شدن خواص و فیلدهای کلاسها دارد و نمونهای از آن، Source Generator توکار مرتبط با کار با JSON در دات نت 6 است که به شدت سبب بهبود کارآیی برنامه، در مقایسه با استفادهی از Reflection میشود؛ چون اینبار تمام محاسبات دقیق مرتبط با Serialization به صورت خودکار در زمان کامپایل برنامه انجام میشود و جزئی از خروجی برنامهی نهایی خواهد شد و دیگر نیازی به محاسبهی هربارهی اطلاعات مورد نیاز، در زمان اجرای برنامه نیست.
نمونهای از روش دسترسی به اطلاعات کلاسها و خواص و فیلدهای آنها را در زمان کامپایل برنامه توسط Source Generators، در مثال قسمت بعد، مشاهده خواهید کرد.
وضعیت T4 templates چگونه خواهد شد؟
در سالهای آغازین ارائهی دات نت، استفاده از T4 templates جهت تولید کدها بسیار مرسوم بود؛ اما با ارائهی Source Generators، این ابزار نیز منسوخ شده در نظر گرفته میشود.
T4 Templates همانند Source Generators تنها کدها و فایلهای جدیدی را تولید میکنند و توانایی تغییر کدهای موجود را ندارند. اما مشکل مهم آن، داشتن Syntax ای خاص است که توسط اکثر IDEها پشتیبانی نمیشود. همچنین عموما اجرای آنها نیز دستی است و برخلاف Source Generators، با تغییرات کدها، به صورت خودکار به روز نمیشوند.
تغییرات زبان #C در جهت پشتیبانی از تولید کنندههای کد
از سالهای اول ارائهی زبان #C، واژهی کلیدی partial، جهت فراهم آوردن امکان تقسیم کدهای یک کلاس، به چندین فایل، میسر شد که از این قابلیت در فناوری T4 Templates زیاد استفاده میشد. اکنون با ارائهی تولید کنندههای کد، واژهی کلیدی partial را میتوان به متدها نیز افزود تا پیاده سازی اصلی آنها، در فایلی دیگر، توسط تولید کنندههای کد انجام شود. تا C# 8.0 امکان افزودن واژهی کلیدی partial به متدهای خصوصی یک کلاس و آن هم از نوع void وجود داشت و در C# 9.0 به متدهای عمومی کلاسها نیز اضافه شدهاست و اکنون این متدها میتوانند void هم نباشند:
زمانیکه پروسهی کامپایل برنامه شروع میشود، در این بین، به مرحلهی جدیدی به نام «تولید کدها» میرسد. در این حالت، کامپایلر تمام اطلاعاتی را که در مورد پروژهی جاری در اختیار دارد، به تولید کنندهی کد معرفی شدهی به آن ارائه میدهد. بر اساس این اطلاعات غنی ارائه شدهی توسط کامپایلر، تولید کنندهی کد، شروع به تولید کدهای جدیدی کرده و آنها را در اختیار ادامهی پروسهی کامپایل، قرار میدهد. پس از آن، کامپایلر با این کدهای جدید، همانند سایر کدهای موجود در پروژه رفتار کرده و عملکرد عادی خودش را ادامه میدهد.
یک برنامه میتواند از چندین Source Generators نیز استفاده کند که روش قرار گرفتن آنها را در پروسهی کامپایل، در شکل زیر مشاهده میکنید:
Source Generators از یکدیگر کاملا مستقل هستند و اطلاعات آنها Immutable است. یعنی نمیتوان اطلاعات تولیدی توسط یک Source Generator را در دیگری تغییر داد و تمام فایلهای تولیدی توسط انواع Source Generators موجود، به پروسهی کامپایل نهایی اضافه میشوند. هرچند زمانیکه فایلی توسط یک تولید کنندهی کد، به کامپایلر اضافه میشود، بلافاصله اطلاعات آن در کل برنامه و IDE و تمام Source Generators موجود دیگر، قابل مشاهده و استفاده است.
مقایسهای بین تولید کنندههای کد و فناوری IL Weaving
Source Generators، تنها راه و روش تولید کد، نیستند و پیش از آن روشهایی مانند استفاده از T4 templates ، Fody ، PostSharp و امثال آن نیز ارائه شدهاست. در ادامه مقایسهای را بین تولید کنندههای کد و فناوری IL Weaving را که پیشتر در سری AOP در این سایت مطالعه کردهاید، مشاهده میکنید:
تولید کنندههای کد:
- تنها میتوانند فایلهای جدید را اضافه کنند. یعنی «در حین» پروسهی کامپایل ظاهر میشوند و به عنوان یک مکمل، تاثیر گذارند. برای مثال نمیتوانند محتوای یک خاصیت یا متد از پیش موجود را تغییر دهند. اما میتوانند هر نوع کد partial ای را «تکمیل» کنند.
- محتوای اضافه شدهی توسط یک تولید کنندهی کد، بلافاصله توسط Compiler شناسایی شده و بررسی میشود و همچنین در Intellisense ظاهر شده و به سادگی قابل دسترسی است. همچنین، قابلیت دیباگ نیز دارد.
IL Weaving:
- میتوانند bytecode برنامه را تغییر دهند. یعنی «پس از» پروسهی کامپایل ظاهر شده و کدهایی را به اسمبلی نهایی تولید شده اضافه میکنند. در این حالت محدودیتی از لحاظ محل تغییر کدها وجود ندارد. برای مثال میتوان بدنهی یک متد یا خاصیت را بطور کامل بازنویسی کرد و کارکردهایی مانند تزریق کدهای caching و logging را دارند.
- کدهایی که توسط این پروسه اضافه میشوند، در حین کدنویسی متداول، قابلیت دسترسی ندارند؛ چون پس از پروسهی کامپایل، به فایل باینری نهایی تولیدی، اضافه میشوند. بنابراین قابلیت دیباگ به همراه سایر کدهای برنامه را نیز ندارند. به علاوه چون توسط کامپایلر در حین پروسهی کامپایل، بررسی نمیشوند، ممکن است به همراه قطعه کدهای غیرقابل اجرایی نیز باشند و دیباگ آنها بسیار مشکل است.
آیندهی Reflection به چه صورتی خواهد شد؟
هرچند Reflection کار تولید کدی را انجام نمیدهد، اما یکی از کارهای متداول با آن، یافتن و محاسبهی اطلاعات خواص و فیلدهای اشیاء، در زمان اجرا است و مزیت کار کردن با آن نیز این است که اگر خاصیتی یا فیلدی تغییر کند، نیازی به بازنویسی قسمتهای پیاده سازی شدهی با Reflection نیست. به همین جهت برای مثال تقریبا تمام کتابخانههای Serialization، از Reflection برای پیاده سازی اعمال خود استفاده میکنند.
امروز، تمام اینگونه عملیات را توسط Source Generators نیز میتوان انجام داد و این فناوری جدید، قابلیت به روز رسانی خودکار کدهای تولیدی را با کم و زیاد شدن خواص و فیلدهای کلاسها دارد و نمونهای از آن، Source Generator توکار مرتبط با کار با JSON در دات نت 6 است که به شدت سبب بهبود کارآیی برنامه، در مقایسه با استفادهی از Reflection میشود؛ چون اینبار تمام محاسبات دقیق مرتبط با Serialization به صورت خودکار در زمان کامپایل برنامه انجام میشود و جزئی از خروجی برنامهی نهایی خواهد شد و دیگر نیازی به محاسبهی هربارهی اطلاعات مورد نیاز، در زمان اجرای برنامه نیست.
نمونهای از روش دسترسی به اطلاعات کلاسها و خواص و فیلدهای آنها را در زمان کامپایل برنامه توسط Source Generators، در مثال قسمت بعد، مشاهده خواهید کرد.
وضعیت T4 templates چگونه خواهد شد؟
در سالهای آغازین ارائهی دات نت، استفاده از T4 templates جهت تولید کدها بسیار مرسوم بود؛ اما با ارائهی Source Generators، این ابزار نیز منسوخ شده در نظر گرفته میشود.
T4 Templates همانند Source Generators تنها کدها و فایلهای جدیدی را تولید میکنند و توانایی تغییر کدهای موجود را ندارند. اما مشکل مهم آن، داشتن Syntax ای خاص است که توسط اکثر IDEها پشتیبانی نمیشود. همچنین عموما اجرای آنها نیز دستی است و برخلاف Source Generators، با تغییرات کدها، به صورت خودکار به روز نمیشوند.
تغییرات زبان #C در جهت پشتیبانی از تولید کنندههای کد
از سالهای اول ارائهی زبان #C، واژهی کلیدی partial، جهت فراهم آوردن امکان تقسیم کدهای یک کلاس، به چندین فایل، میسر شد که از این قابلیت در فناوری T4 Templates زیاد استفاده میشد. اکنون با ارائهی تولید کنندههای کد، واژهی کلیدی partial را میتوان به متدها نیز افزود تا پیاده سازی اصلی آنها، در فایلی دیگر، توسط تولید کنندههای کد انجام شود. تا C# 8.0 امکان افزودن واژهی کلیدی partial به متدهای خصوصی یک کلاس و آن هم از نوع void وجود داشت و در C# 9.0 به متدهای عمومی کلاسها نیز اضافه شدهاست و اکنون این متدها میتوانند void هم نباشند:
partial class MyType { partial void OnModelCreating(string input); // C# 8.0 public partial bool IsPet(string input); // C# 9.0 } partial class MyType { public partial bool IsPet(string input) => input is "dog" or "cat" or "fish"; }
Here’s what’s new in this preview release:
- Razor compiler updated to use source generators
- Support for custom event arguments in Blazor
- CSS isolation for MVC Views and Razor Pages
- Infer component generic types from ancestor components
- Preserve prerendered state in Blazor apps
- SignalR – Nullable annotations
همانطور که در قسمت اول این سری نیز عنوان شد، انجام عملیات Reflection عموما به همراه سربار محاسبهی هربارهی اطلاعات مورد نیاز آن است و اکنون میتوان یک چنین محاسباتی را توسط Source generators، در زمان کامپایل برنامه، تامین و جزئی از خروجی نهایی کامپل شدهی آن کرد تا کارآیی برنامه به شدت افزایش یابد. یک نمونه مثال آن، استفاده از ویژگی Display بر روی عناصر یک enum است تا بتوان توضیحات بیشتری را جهت نمایش در UI، ارائه داد:
روش متداول جهت دسترسی به اطلاعات ویژگی Display، استفاده از Reflection به صورت زیر است:
یعنی هرجائی که در برنامه نیاز باشد تا برای مثال نام نمایشی Gender.Female محاسبه شود، باید یکبار عملیات فوق در زمان اجرا، تکرار گردد با محاسبهی تمام ویژگیهای یک عنصر enum، بررسی وجود DisplayAttribute در این بین و در صورت وجود، محاسبهی مقدار خاصیت Name آن.
یعنی در اصل متد کمکی که برای اینکار نیاز داریم، چنین خروجی را دارد:
مزیت این روش نسبت به Reflection، از پیش محاسبه شده بودن و سرعت بالای کار با آن است؛ اما ... باید به ازای هر enum نوشته شده، یکبار به صورت اختصاصی، تکرار شود و همچنین اگر اطلاعات enum متناظر با آن تغییر کرد، نیاز است تا این کلاسها و متدهای کمکی نیز اصلاح شوند. به همین جهت است که عموما کار با Reflection ترجیح داده میشود؛ چون حجم کدنویسی کمتری را به همراه دارد و همچنین میتواند انواع و اقسام enum را پوشش دهد و عمومی است.
با ارائهی Source Generators، مشکلات یاد شده دیگر وجود ندارند. یعنی کار تولید متدهای اختصاصی برای هر enum، خودکار است و همچنین به روز رسانی آنی آنها با هر تغییری در enumها نیز پیشبینی شدهاست.
تهیهی تولید کنندهی خودکار کدی که نام نمایشی enumها را به صورت از پیش محاسبه شده ارائه میدهد
در قسمت قبل، با روش تهیه و استفاده از Source Generators آشنا شدیم. در اینجا نیز از همان قالب، در جهت تولید کد متد الحاقی GetDisplayName فوق، استفاده خواهیم کرد. یعنی هدف رسیدن به کلاس GenderExtensions فوق و متد GetDisplayName آن، در زمان کامپایل برنامه و به صورت خودکار است:
کار را با ایجاد یک کلاس عمومی جدید که پیاده سازی کنندهی اینترفیس ISourceGenerator و مزین به ویژگی Generator است، شروع میکنیم. در مورد وابستگیهای مورد نیاز یک چنین پروژهای، در قسمت قبل توضیحات کافی ارائه شد.
در اینجا در متد Execute، دسترسی کاملی را به اطلاعات تهیه شدهی توسط کامپایلر داریم. توسط آن تمام Enumهای برنامه را یا همان EnumDeclarationSyntax را در اینجا، یافته و سپس حلقهای را بر روی اطلاعات آنها تشکیل داده و برای تک تک آنها، توسط متد GenerateEnumExtensions، کد معادل کلاس GenderExtensions را که در این مطلب معرفی شد، تولید میکنیم. در پایان کار نیز این کد را توسط متد AddSource، به کامپایلر معرفی خواهیم کرد تا بلافاصله در IDE ظاهر شده و قابلیت استفاده را پیدا کند.
یک نکته: اگر میخواهید صرفا enumهای خاصی در این بین بررسی شوند، میتوانید کدهای یک Attribute سفارشی را مثلا با نام فرضی [GenerateExtensions] در همینجا توسط متد context.AddSource به مجموعه سورسها اضافه کنید و سپس بر اساس نام آن، در قسمت Where ایی که کامنت شدهاست، تنها اطلاعات مدنظر را فیلتر و پردازش کنید.
متدی هم که ابتدا کلاس Extensions را بر اساس نام هر Enum موجود تولید و سپس بدنهی متد GetDisplayName اختصاصی آنرا تکمیل میکند، به صورت زیر است:
در مورد روش استفادهی از این source generator نیز در قسمت قبل بحث شد و فقط کافی است ارجاعی را به اسمبلی آن به پروژهی مدنظر افزود و OutputItemType را به آنالایزر تنظیم کرد.
کدهای کامل این مثال را از اینجا میتوانید دریافت کنید: SourceGeneratorTests-part3.zip
سؤال: چگونه میتوان کدهای تولید شدهی توسط یک Source Generator را ذخیره کرد؟
Source Generators به صورت پیشفرض هیچ فایلی را بر روی دیسک سخت ذخیره نمیکنند و تمام عملیات آنها در حافظه انجام میشود. اگر علاقمند به مطالعهی این خروجیهای خودکار، به صورت فایلهای واقعی هستید، نیاز به انجام تغییرات زیر در فایل csproj پروژهی مصرف کنندهی Source Generator است:
توضیحات:
- EmitCompilerGeneratedFiles سبب ثبت فایلهای خودکار تولید شده، بر روی دیسک سخت میشود که قالب مسیر پیشفرض ذخیره سازی آن به صورت زیر است:
- اگر میخواهید نام پوشهی generated را تغییر دهید، میتوان از ویژگی CompilerGeneratedFilesOutputPath استفاده کرد.
- چون این فایلهای cs. جدید ثبت شدهی بر روی دیسک سخت، مجددا وارد پروسهی کامپایل میشوند و خود Source Generator هم یک نمونهی از آنهارا پیشتر به کامپایلر معرفی کردهاست، برنامه دیگر به علت وجود اطلاعات تکراری، کامپایل نخواهد شد. به همین جهت نیاز است تا قسمت Compile Remove فوق را نیز معرفی کرد تا کامپایلر از پوشهی Generated تنظیمی، صرفنظر کند.
- اطلاعات موجود در پوشهی Generated، فقط یکبار تولید میشوند؛ صرفنظر از اطلاعات موجود در حافظه که همیشه به روز است. به همین جهت اگر میخواهید نمونههای به روز شدهی آنها را نیز بر روی دیسک سخت داشته باشید، نیاز به قسمت RemoveDir تنظیمی وجود دارد.
using System.ComponentModel.DataAnnotations; namespace NotifyPropertyChangedGenerator.Demo; public enum Gender { NotSpecified, [Display(Name = "مرد")] Male, [Display(Name = "زن")] Female }
public static class Extensions { public static string GetDisplayName(this Enum value) { if (value is null) throw new ArgumentNullException(nameof(value)); var attribute = value.GetType().GetField(value.ToString())? .GetCustomAttributes<DisplayAttribute>(false).FirstOrDefault(); if (attribute is null) return value.ToString(); return attribute.GetType().GetProperty("Name")?.GetValue(attribute, null)?.ToString(); } }
یعنی در اصل متد کمکی که برای اینکار نیاز داریم، چنین خروجی را دارد:
namespace NotifyPropertyChangedGenerator.Demo { public static class GenderExtensions { public static string GetDisplayName(this Gender @enum) { return @enum switch { Gender.NotSpecified => "NotSpecified", Gender.Male => "مرد", Gender.Female => "زن", _ => throw new ArgumentOutOfRangeException(nameof(@enum)) }; } } }
با ارائهی Source Generators، مشکلات یاد شده دیگر وجود ندارند. یعنی کار تولید متدهای اختصاصی برای هر enum، خودکار است و همچنین به روز رسانی آنی آنها با هر تغییری در enumها نیز پیشبینی شدهاست.
تهیهی تولید کنندهی خودکار کدی که نام نمایشی enumها را به صورت از پیش محاسبه شده ارائه میدهد
در قسمت قبل، با روش تهیه و استفاده از Source Generators آشنا شدیم. در اینجا نیز از همان قالب، در جهت تولید کد متد الحاقی GetDisplayName فوق، استفاده خواهیم کرد. یعنی هدف رسیدن به کلاس GenderExtensions فوق و متد GetDisplayName آن، در زمان کامپایل برنامه و به صورت خودکار است:
[Generator] public class EnumExtensionsGenerator : ISourceGenerator { public void Initialize(GeneratorInitializationContext context) {} public void Execute(GeneratorExecutionContext context) { var compilation = context.Compilation; foreach (var syntaxTree in compilation.SyntaxTrees) { var semanticModel = compilation.GetSemanticModel(syntaxTree); var immutableHashSet = syntaxTree.GetRoot() .DescendantNodesAndSelf() .OfType<EnumDeclarationSyntax>() .Select(enumDeclarationSyntax => semanticModel.GetDeclaredSymbol(enumDeclarationSyntax)) .OfType<ITypeSymbol>() /*.Where(typeSymbol => typeSymbol.GetAttributes().Any( attributeData => string.Equals(attributeData.AttributeClass?.Name, "GenerateExtensions", StringComparison.Ordinal) ))*/ .ToImmutableHashSet(); foreach (var typeSymbol in immutableHashSet) { var source = GenerateEnumExtensions(typeSymbol); context.AddSource($"{typeSymbol.Name}Extensions.cs", source); } } }
در اینجا در متد Execute، دسترسی کاملی را به اطلاعات تهیه شدهی توسط کامپایلر داریم. توسط آن تمام Enumهای برنامه را یا همان EnumDeclarationSyntax را در اینجا، یافته و سپس حلقهای را بر روی اطلاعات آنها تشکیل داده و برای تک تک آنها، توسط متد GenerateEnumExtensions، کد معادل کلاس GenderExtensions را که در این مطلب معرفی شد، تولید میکنیم. در پایان کار نیز این کد را توسط متد AddSource، به کامپایلر معرفی خواهیم کرد تا بلافاصله در IDE ظاهر شده و قابلیت استفاده را پیدا کند.
یک نکته: اگر میخواهید صرفا enumهای خاصی در این بین بررسی شوند، میتوانید کدهای یک Attribute سفارشی را مثلا با نام فرضی [GenerateExtensions] در همینجا توسط متد context.AddSource به مجموعه سورسها اضافه کنید و سپس بر اساس نام آن، در قسمت Where ایی که کامنت شدهاست، تنها اطلاعات مدنظر را فیلتر و پردازش کنید.
متدی هم که ابتدا کلاس Extensions را بر اساس نام هر Enum موجود تولید و سپس بدنهی متد GetDisplayName اختصاصی آنرا تکمیل میکند، به صورت زیر است:
private string GenerateEnumExtensions(ITypeSymbol typeSymbol) { return $@"namespace {typeSymbol.ContainingNamespace} {{ public static class {typeSymbol.Name}Extensions {{ public static string GetDisplayName(this {typeSymbol.Name} @enum) {{ {GenerateExtensionMethodBody(typeSymbol)} }} }} }}"; } private static string GenerateExtensionMethodBody(ITypeSymbol typeSymbol) { var sb = new StringBuilder(); sb.Append(@"return @enum switch { "); foreach (var fieldSymbol in typeSymbol.GetMembers().OfType<IFieldSymbol>()) { var displayAttribute = fieldSymbol.GetAttributes() .FirstOrDefault(attributeData => string.Equals(attributeData.AttributeClass?.Name, "DisplayAttribute", StringComparison.Ordinal)); if (displayAttribute is null) { sb.AppendLine( $@" {typeSymbol.Name}.{fieldSymbol.Name} => ""{fieldSymbol.Name}"","); } else { var displayAttributeName = displayAttribute.NamedArguments .FirstOrDefault(x => string.Equals(x.Key, "Name", StringComparison.Ordinal)) .Value; sb.AppendLine( $@" {typeSymbol.Name}.{fieldSymbol.Name} => ""{displayAttributeName.Value}"","); } } sb.Append( @" _ => throw new ArgumentOutOfRangeException(nameof(@enum)) };"); return sb.ToString(); }
کدهای کامل این مثال را از اینجا میتوانید دریافت کنید: SourceGeneratorTests-part3.zip
سؤال: چگونه میتوان کدهای تولید شدهی توسط یک Source Generator را ذخیره کرد؟
Source Generators به صورت پیشفرض هیچ فایلی را بر روی دیسک سخت ذخیره نمیکنند و تمام عملیات آنها در حافظه انجام میشود. اگر علاقمند به مطالعهی این خروجیهای خودکار، به صورت فایلهای واقعی هستید، نیاز به انجام تغییرات زیر در فایل csproj پروژهی مصرف کنندهی Source Generator است:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>net6.0</TargetFramework> <ImplicitUsings>enable</ImplicitUsings> <Nullable>enable</Nullable> <EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles> <CompilerGeneratedFilesOutputPath>Generated</CompilerGeneratedFilesOutputPath> </PropertyGroup> <Target Name="CleanSourceGeneratedFiles" BeforeTargets="BeforeBuild" DependsOnTargets="$(BeforeBuildDependsOn)"> <RemoveDir Directories="$(CompilerGeneratedFilesOutputPath)" /> </Target> <ItemGroup> <!-- Exclude the output of source generators from the compilation --> <Compile Remove="$(CompilerGeneratedFilesOutputPath)/**/*.cs" /> <Content Include="$(CompilerGeneratedFilesOutputPath)/**" /> </ItemGroup> <ItemGroup> <ProjectReference Include="..\NotifyPropertyChangedGenerator\NotifyPropertyChangedGenerator.csproj" OutputItemType="Analyzer" ReferenceOutputAssembly="false" /> </ItemGroup> </Project>
- EmitCompilerGeneratedFiles سبب ثبت فایلهای خودکار تولید شده، بر روی دیسک سخت میشود که قالب مسیر پیشفرض ذخیره سازی آن به صورت زیر است:
{BaseIntermediateOutpath}/generated/{Assembly}/{SourceGeneratorName}/{GeneratedFile}
- چون این فایلهای cs. جدید ثبت شدهی بر روی دیسک سخت، مجددا وارد پروسهی کامپایل میشوند و خود Source Generator هم یک نمونهی از آنهارا پیشتر به کامپایلر معرفی کردهاست، برنامه دیگر به علت وجود اطلاعات تکراری، کامپایل نخواهد شد. به همین جهت نیاز است تا قسمت Compile Remove فوق را نیز معرفی کرد تا کامپایلر از پوشهی Generated تنظیمی، صرفنظر کند.
- اطلاعات موجود در پوشهی Generated، فقط یکبار تولید میشوند؛ صرفنظر از اطلاعات موجود در حافظه که همیشه به روز است. به همین جهت اگر میخواهید نمونههای به روز شدهی آنها را نیز بر روی دیسک سخت داشته باشید، نیاز به قسمت RemoveDir تنظیمی وجود دارد.
اشتراکها