خوب زمانیکه یک متد قراره فراخوانی بشه، کلاس مربوط به اون هم باید وهله سازی بشه دیگه. نه؟! این جزو اصول ابتدایی کار هست. بعد این مشکلش چیه؟ یا چه اهمیتی داره وقتی اصل متد کش شده اصلا اجرا نمیشه و یک ضرب نتیجهش بازگشت داده میشه.
دات نت 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 تولیدی، اینبار به همراه توضیح کامل نحوهی عملکرد عبارت باقاعدهی مورد استفاده نیز هست:
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"; }
بازخوردهای دوره
آشنایی با AOP Interceptors
سلام.
در StructureMap 3 متد EnrichWith نداریم! متد DecorateAllWith هم پارامتر هاش تفاوت داره!
میشه قطعه کد مناسب رو قرار بدید؟
ممنونم.
در StructureMap 3 متد EnrichWith نداریم! متد DecorateAllWith هم پارامتر هاش تفاوت داره!
میشه قطعه کد مناسب رو قرار بدید؟
ممنونم.
بازخوردهای دوره
آشنایی با AOP Interceptors
ممنون بابت این دوره زیبا؛
ایا روشی توکار برای بازگشت مقدار، از یک Interceptor به متد اجراشونده هست؟
ایا روشی توکار برای بازگشت مقدار، از یک Interceptor به متد اجراشونده هست؟
بعنوان مثال رشته ای که Log میشود رو بعنوان مقدار بازگشتی در متد اجرا شونده دریافت کنیم؟
باتشکر
بازخوردهای دوره
آشنایی با AOP Interceptors
- سؤال شما این بود که در کلاس اصلی من، در متدی داخل آن، با چند صدهزار رکورد کار انجام میشود. پاسخ این است که اصلا این پروکسی ایجاد شده ربطی به داخل متد شما ندارد. کاری به وهله سازیهای انجام شده داخل آن نیز ندارد. invocation.Proceed یعنی این متد رو اجرا کن؛ نه اینکه هر وهلهای که داخل آن متد قرار میگیرد را نیز با پروکسی مزین کن.
- تمام ORMها برای پیاده سازی مباحث Lazy loading یک شیء پروکسی را از شیء اصلی شما ایجاد میکنند. نمونهاش را شاید با EF Code first با نامهای خودکاری مانند ClassName_00394CF1F92740F13E3 دیده باشید؛ NHibernate هم یک زمانی از همین Castle.Core برای تدارک پروکسیهای اشیاء استفاده میکرد. سربار آن در حین ایجاد چندین هزار وهله از یک شیء، در حد همان کار با ORMهایی است که هر روزه از آنها استفاده میکنید (اگر میخواهید یک حسی از این قضیه داشته باشید).
- تمام ORMها برای پیاده سازی مباحث Lazy loading یک شیء پروکسی را از شیء اصلی شما ایجاد میکنند. نمونهاش را شاید با EF Code first با نامهای خودکاری مانند ClassName_00394CF1F92740F13E3 دیده باشید؛ NHibernate هم یک زمانی از همین Castle.Core برای تدارک پروکسیهای اشیاء استفاده میکرد. سربار آن در حین ایجاد چندین هزار وهله از یک شیء، در حد همان کار با ORMهایی است که هر روزه از آنها استفاده میکنید (اگر میخواهید یک حسی از این قضیه داشته باشید).
بازخوردهای دوره
آشنایی با AOP Interceptors
باید از قابلیت scan در StructureMap استفاده کنید:
- در این حالت AssemblyContainingType مشخص میکند که کدام اسمبلی باید اسکن شود.
- WithDefaultConventions یعنی هرجایی IName داشتیم را به صورت خودکار به Name متصل کن. (روال پیش فرض سیم کشی اینترفیسها و کلاسها برای وهله سازی)
- OnAddedPluginTypes یک Callback هست که زمان انجام اولیه تنظیمات به ازای هر type یافت شده فراخوانی میشود. در اینجا میشود با استفاده از EnrichWith و ProxyGenerator کار اتصال کلاس Interceptor را انجام داد.
ObjectFactory.Initialize(x => { var dynamicProxy = new ProxyGenerator(); x.Scan(scanner => { scanner.AssemblyContainingType<IMyType>(); // نحوه یافتن اسمبلی لایه سرویس // Connect `IName` interface to 'Name' class automatically scanner.WithDefaultConventions() .OnAddedPluginTypes(plugin => plugin.EnrichWith(target => dynamicProxy.CreateInterfaceProxyWithTargetInterface(target.GetType().GetInterfaces().First(), target.GetType().GetInterfaces(), target, new LoggingInterceptor()) )); }); });
- WithDefaultConventions یعنی هرجایی IName داشتیم را به صورت خودکار به Name متصل کن. (روال پیش فرض سیم کشی اینترفیسها و کلاسها برای وهله سازی)
- OnAddedPluginTypes یک Callback هست که زمان انجام اولیه تنظیمات به ازای هر type یافت شده فراخوانی میشود. در اینجا میشود با استفاده از EnrichWith و ProxyGenerator کار اتصال کلاس Interceptor را انجام داد.
همانطور که در قسمت اول این سری نیز عنوان شد، انجام عملیات 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 تنظیمی وجود دارد.
بازخوردهای دوره
آشنایی با AOP Interceptors
قسمت EnrichAllWith را حذف کنید. بعد برنامه را اجرا کنید. باز هم اجرا میشود و استثنایی صادر نمیشود. چرا؟ چون اجرای کد آن معادل است با:
مقدار infinity برای نوع double تعریف شده اما برای نوع int خیر؛ اینطوری طراحی شده.
double d = 0; Console.WriteLine(1 / d); // compiles, runs, results in: Infinity
تا اینجا روش آزمایش تولید کنندههای کد، صرفا بر اساس کامپایل برنامه و مشاهدهی خروجی نهایی آن بود و یا حتی با ترفندهایی امکان دیباگ آنها نیز وجود دارد که البته هنوز در تمام IDEها پشتیبانی نمیشود. در این قسمت میخواهیم این وضعیت را بهبود بخشیده و برای تولید کنندههای کد، آزمون واحد بنویسیم که یکی از مزایای آن، فراهم بودن امکان دیباگ یک چنین پروژههایی در تمام IDEهای موجود است و برای انجام اینکار، نیاز به هیچ ترفند خاصی وجود ندارد و پروسهی کاری آن یکدست و هماهنگ با سایر آزمونهای واحد است.
آماده سازی مقدمات پروژهی آزمون واحد
در ادامهی مثال این سری، پروژهی جدید NotifyPropertyChangedGenerator.Tests را از نوع class library با تنظیمات فایل csproj. زیر ایجاد میکنیم:
در اینجا وابستگیهای مورد نیاز برای دسترسی به امکانات Roslyn و همچنین برای نمونه MSTest را مشاهده میکنید. به علاوه مسیر پروژهی Source Generator مورد استفاده به نحو متداولی تعریف شدهاست.
ایجاد یک کلاس کمکی برای اجرای Source Generators در پروژههای آزمون واحد
در اینجا میخواهیم همان کاری را که کامپایلر سیشارپ در پشت صحنه انجام میدهد، شبیه سازی کنیم تا بتوانیم یک تولید کنندهی کد را به مراحل کامپایل کد، معرفی و سپس آنرا اجرا کنیم:
این متد، یک قطعه کد ابتدایی را دریافت کرده و سپس آنرا به همراه Source Generatorهای مدنظر، به کامپایلر سیشارپ معرفی میکند، تا کامپایلر تمام این موارد را در کنار هم پردازش کرده و اسمبلی درون حافظهای را به نام compilation تولید کند. خروجیهای این متد، اطلاعات غنی هستند از نحوهی کامپایل دادههای ارسالی به کامپایلر که در ادامه میتوان از آنها جهت نوشتن آزمونهای واحد متکی به خودی استفاده کرد.
نوشتن اولین آزمون واحد مخصوص یک تولید کنندهی کد
پس از تهیهی متدی که میتواند یک قطعه کد و تعدادی Source Generator را به کامپایلر سیشارپ، جهت پردازش معرفی کند، یک نمونه نحوهی استفادهی از آن جهت نوشتن آزمونهای واحد کاملا مستقل و متکی به خود، به صورت زیر است:
- در این مثال ابتدا یک قطعه کد سیشارپ را که قرار است کدهای آن توسط تولید کنندهی کد توسعه داده شده تکمیل شوند، تعریف کردهایم.
- سپس این قطعه کد و نمونهای از تولید کنندهی کد را به کامپایلر ارسال و اجرا کردهایم.
- اکنون بر اساس خروجی کامپایلر برای مثال میتوان به فایل تولید شده و SyntaxTrees آن دسترسی پیدا کرد و یا با کمک متد GetText، به کل محتوای این فایل تولید شده دسترسی یافت و برای مثال آنرا با مقداری که انتظار داریم مقایسه کرد تا به این ترتیب بتوان از صحت عملکرد تولید کنندهی کد، اطمینان حاصل نمود.
- همانطور که عنوان شد، اکنون قرار دادن break-point در قسمتهای مختلف آزمون واحد تهیه شده بسیار سادهاست و به این ترتیب میتوان یک چنین پروژههایی را در تمام IDEها دیباگ کرد.
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: SourceGeneratorTests-part5.zip
آماده سازی مقدمات پروژهی آزمون واحد
در ادامهی مثال این سری، پروژهی جدید NotifyPropertyChangedGenerator.Tests را از نوع class library با تنظیمات فایل csproj. زیر ایجاد میکنیم:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net6.0</TargetFramework> <ImplicitUsings>enable</ImplicitUsings> <Nullable>enable</Nullable> <IsPackable>false</IsPackable> </PropertyGroup> <ItemGroup> <PackageReference Include="Microsoft.CodeAnalysis.Analyzers" Version="3.3.3"> <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets> <PrivateAssets>all</PrivateAssets> </PackageReference> <PackageReference Include="Microsoft.CodeAnalysis.Common" Version="4.2.0" /> <PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="4.2.0" PrivateAssets="all" /> <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.2.0" /> <PackageReference Include="MSTest.TestFramework" Version="2.2.10" /> <PackageReference Include="MSTest.TestAdapter" Version="2.2.10" /> </ItemGroup> <ItemGroup> <ProjectReference Include="..\NotifyPropertyChangedGenerator\NotifyPropertyChangedGenerator.csproj" /> </ItemGroup> </Project>
ایجاد یک کلاس کمکی برای اجرای Source Generators در پروژههای آزمون واحد
در اینجا میخواهیم همان کاری را که کامپایلر سیشارپ در پشت صحنه انجام میدهد، شبیه سازی کنیم تا بتوانیم یک تولید کنندهی کد را به مراحل کامپایل کد، معرفی و سپس آنرا اجرا کنیم:
internal static class SourceGeneratorTestsExtensions { public static (GeneratorDriver Driver, Compilation OutputCompilation, ImmutableArray<Diagnostic> Diagnostics) RunGenerators(this string source, params ISourceGenerator[] generators) { var references = AppDomain.CurrentDomain.GetAssemblies() .Where(assembly => !assembly.IsDynamic) .Select(assembly => MetadataReference.CreateFromFile(assembly.Location)) .Cast<MetadataReference>(); var inputCompilation = CSharpCompilation.Create("compilation", new[] { CSharpSyntaxTree.ParseText(source, new CSharpParseOptions(LanguageVersion.Latest)) }, references, new CSharpCompilationOptions(OutputKind.ConsoleApplication)); GeneratorDriver driver = CSharpGeneratorDriver.Create(generators); driver = driver.RunGeneratorsAndUpdateCompilation( inputCompilation, out var outputCompilation, out var diagnostics); return (driver, outputCompilation, diagnostics); } }
نوشتن اولین آزمون واحد مخصوص یک تولید کنندهی کد
پس از تهیهی متدی که میتواند یک قطعه کد و تعدادی Source Generator را به کامپایلر سیشارپ، جهت پردازش معرفی کند، یک نمونه نحوهی استفادهی از آن جهت نوشتن آزمونهای واحد کاملا مستقل و متکی به خود، به صورت زیر است:
using Microsoft.VisualStudio.TestTools.UnitTesting; using PropertyChangedGenerator = NotifyPropertyChangedGenerator.NotifyPropertyChangedGenerator; namespace NotifyPropertyChangedGenerator.Tests; [TestClass] public class GeneratorTest { [TestMethod] public void SimpleGeneratorTest() { var userSource = @" using System; using System.ComponentModel; namespace NotifyPropertyChangedDemo { public class Test : INotifyPropertyChanged { private int regularField; private int IndexBackingField; } } "; var (driver, outputCompilation, diagnostics) = userSource.RunGenerators(new PropertyChangedGenerator()); var newFile = outputCompilation.SyntaxTrees .Single(x => Path.GetFileName(x.FilePath).EndsWith(".Test.cs")); Assert.IsNotNull(newFile); Assert.IsTrue(newFile.FilePath.EndsWith("Test.Notify.Test.cs")); var generatedSource = newFile.GetText().ToString(); Assert.IsTrue(generatedSource.Contains("namespace NotifyPropertyChangedDemo")); // We can now assert things about the resulting compilation: Assert.IsTrue(diagnostics.IsEmpty); // there were no diagnostics created by the generators // we have two syntax trees, the original 'user' provided one, and the one added by the generator Assert.IsTrue(outputCompilation.SyntaxTrees.Count() == 2); // verify the compilation with the added source has no diagnostics Assert.IsTrue(outputCompilation.GetDiagnostics().IsEmpty); } }
- سپس این قطعه کد و نمونهای از تولید کنندهی کد را به کامپایلر ارسال و اجرا کردهایم.
- اکنون بر اساس خروجی کامپایلر برای مثال میتوان به فایل تولید شده و SyntaxTrees آن دسترسی پیدا کرد و یا با کمک متد GetText، به کل محتوای این فایل تولید شده دسترسی یافت و برای مثال آنرا با مقداری که انتظار داریم مقایسه کرد تا به این ترتیب بتوان از صحت عملکرد تولید کنندهی کد، اطمینان حاصل نمود.
- همانطور که عنوان شد، اکنون قرار دادن break-point در قسمتهای مختلف آزمون واحد تهیه شده بسیار سادهاست و به این ترتیب میتوان یک چنین پروژههایی را در تمام IDEها دیباگ کرد.
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: SourceGeneratorTests-part5.zip