مطالب
دریافت خروجی Curl از HttpClient در دات‌نت (NET.)
در این مقاله قصد دارم راجع‌به یک Extension در دات نت صحبت کنم که خیلی وقت‌ها می‌تواند بسیار مفید و نجات بخش و همینطور در زمان کارتان تاثیر زیادی بگذارد. خیلی وقت‌ها پیش آمده که داریم با یک سرویس بیرونی ارتباط برقرار میکنیم، اما هنگام فراخوانی کردن، با خطا مواجه می‌شویم و ما متوجه دلیل خطای رخ داده در آن لحظه نمی‌شویم. برای خود من بار‌ها پیش آمده که Property‌های اطلاعات ورودی برای وب سرویس را بصورت Pascal Case داده باشم، ولی سرویس بیرونی فقط بصورت Camel Case برای آن قابل قبول بوده‌است و من بعد از ساعت‌ها بررسی متوجه این موضوع می‌شدم و یا ممکن بود یک Property با مقدار نادرست ارسال می‌کردم و یا ممکن بود یک Property را اصلا ارسال نمی‌کردم و یا حتی اینکه یک Header را درست نمی‌فرستادم و کلی از این موضوعات که با آن‌ها برخورد کردیم و با صرف زمان، مشکل را حل کردیم. این Extension کار ما را برای حل این مسائل خیلی راحت می‌کند.

حالا چطور و چگونه ازش استفاده کنیم؟!

این Extension کارش این است، وقتی HttpClient ما مقدار دهی شده و آماده‌ی برای ارسال درخواست به سرویس بیرونی است، می‌توانیم قبل ارسال، آن را فراخوانی کنیم و یک خروجی Curl از درخواستی را که داریم می‌فرستیم، ببینیم. سپس خروجی Curl را در ترمینال صدا بزنیم و نتیجه را ببینیم. همینطور می‌توانیم به Postman خود Import کنیم و با داکیومنتی که داده شده، بررسی کنیم و مشکل را دقیق‌تر بررسی کنیم.

نحوه Import کردن Curl در Postman
 open the Postman -> click on the Import button -> 
select the Raw text tab -> paste the curl script here -> 
then press the Continue button -> at the end press the button import.
جای دیگری که نقش این Extension می‌تواند تاثیر گذار باشد، زمانی است که ما از نحوه‌ی فراخوانی سرویس‌های بیرونی خود که در سیستم نوشته شده، هیچ داکیومنت یا Postman Collection ای نداریم. ما با این Extension با خروجی Curl که در اختیارمان می‌گذارد، می‌توانیم Collection خود را ایجاد کنیم و در اختیار هم تیمی‌های خود قرار دهیم. می‌بینید که چقدر کارها را ساده و راحت می‌کند!

استفاده از این Extension بسیار ساده و سریع است و شما با نوشتن یک خط می‌توانید آن را فراخوانی کنید: 
آدرس Nuget Package


این Extension سه(۳) راه برای نمایش Curl دارد:

۱- چاپ در Console
httpClient.GenerateCurlInConsole(httpRequestMessage, null);
پارامتر دوم، کانفیگ هست که شما می‌توانید بنا به نیاز، آنها را تغییر دهید (پیش فرض آن null است). مثال و توضیحات کانفیگ به شرح زیر است:
httpClient.GenerateCurlInConsole(
   httpRequestMessage,
   configs =>
   {
     configs.TurnOn = true;
     configs.NeedAddDefaultHeaders = true;
     configs.EnableCodeBeautification = false;
   });
- مقدارTurnOn پیش فرض فعال است؛ درصورت غیرفعال کردن جنریتور، غیر فعال می‌شود و عمل ایجاد اسکریپت را انجام نمی‌دهد.
- با مقدارNeedAddDefaultHeaders می‌توانید مشخص کنید در صورت داشتن هدر‌های پیش فرض، در خروجی Curl اضافه شود یا خیر. پیش فرض آن فعال هست.
- مقدارEnableCodeBeautification اگر فعال باشد اسکریپت‌های چاپ شده در Console را به ازای هر HttpMethod، با رنگ متفاوتی نشان می‌دهد؛ برای خوانایی بهتر اسکریپت. بصورت پیش فرض غیر فعال است.

۲- ذخیره در فایل

httpClient.GenerateCurlInFile(httpRequestMessage, null);
پارامتر دوم کانفیگ هست که شما می‌توانید بنا به نیاز، آنها را تغییر دهید (پیش فرض آن null است).
مثال و توضیحات کانفیگ به شرح زیر است:
httpClient.GenerateCurlInFile(
   httpRequestMessage,
   configs =>
   {
    configs.Filename = "your filename";
    configs.Path = "your path";
    configs.TurnOn = true;
    configs.NeedAddDefaultHeaders = true;
   });
- مقدارFilename را اگر وارد کنید، می‌توانید نام فایلی را که ایجاد می‌شود، مشخص کنید. در صورت مقدار ندادن، پیش فرض تاریخ روز جاری را اعمال میکند. مثال: 20220910.curl
- مقدارPath را می‌توانید در صورت داشتن مسیری خاص، مشخص کنید. در غیر این صورت بصورت پیش فرض اطلاعات را در مسیر ProjectDirectory\bin\Debug\netX ذخیره می‌کند.
- مقدارTurnOn پیش فرض آن فعال است. درصورت غیرفعال کردن جنریتور غیر فعال می‌شود و عمل ایجاد اسکریپت را انجام نمی‌دهد.
- با مقدار NeedAddDefaultHeaders می‌توانید مشخص کنید در صورت داشتن هدر‌های پیش فرض، در خروجی Curl اضافه شود یا خیر. پیش فرض آن فعال هست.

۳- ذخیره در متغیر

httpClient.GenerateCurlInString(httpRequestMessage);

لینک آدرس GitHub پروژه جهت دیدن سورس پروژه و دیدن مثال‌های بیشتر و همینطور برای دیدن قابلیت‌های بیشتر این extension.

خوشحال می‌شوم اگه نظری دارید راجع به پروژه و یا مشکلی دیدید در سورس کد به من اطلاع بدهید و خیلی خوشحال می‌شوم اگر در تکمیل و پیاده سازی این پروژه مشارکت کنید و اگر این پروژه براتون جذاب و یا مفید بود استار بدهید.

اشتراک‌ها
سری مقدماتی دات‌نت بر روی Azure

.NET on Azure for Beginners
8 videos

.NET on Azure for Beginners will teach you the basics of Azure and how to leverage its services and features to build amazing cloud applications. You will learn how to deploy web apps, work with storage and data, authenticate and use Managed Identity, harness the power of containers, and even deploy with GitHub Actions. By the end of this series, you will have the skills and confidence to start developing your own .NET applications on Azure! 

سری مقدماتی دات‌نت بر روی Azure
اشتراک‌ها
دات‌نت ۷ ریلیز شد!

.NET 7 brings your apps increased performance and new features for C# 11/F# 7, .NET MAUI, ASP.NET Core/Blazor, Web APIs, WinForms, WPF and more. With .NET 7, you can also easily containerize your .NET 7 projects, set up CI/CD workflows in GitHub actions, and achieve cloud-native observability.


Thanks to the open-source .NET community for your numerous contributions that helped shape this .NET 7 release. 28k contributions made by over 8900 contributors throughout the .NET 7 release!


.NET remains one of the fastest, most loved, and trusted platforms with an expansive .NET package ecosystem that includes over 330,000 packages. 

دات‌نت ۷ ریلیز شد!
بازخوردهای دوره
آشنایی با AOP Interceptors
- یکی از اهداف مهم AOP این است که به صورت لایه‌ای نامریی عمل کند و هر زمان که نیاز باشد، بتوان بدون کوچکترین تغییری در کدهای اصلی برنامه، کل منطق آن‌را حذف، یا با نمونه‌‌ای دیگر جایگزین کرد. بنابراین دریافت یک مقدار از Interceptor داخل متدی در برنامه، نقض کننده‌ی فلسفه‌ی وجودی این عملیات است.
- اما توسط پارامتر IInvocation و مقداری Reflection، دسترسی کاملی به اطلاعات متد فراخوان هست و در اینجا می‌توان در صورت نیاز، پارامتر و مقداری را نیز به آن ارسال کرد.
- در ASP.NET MVC، مفهوم فیلترها دقیقا پیاده سازی کننده‌ی Interceptor‌های AOP هستند. در اینجا نیز مستقیما اطلاعاتی به فراخوان، در صورت نیاز بازگشت داده نمی‌شود. اما Context جاری در اختیار Interceptor و فیلتر هست. به این ترتیب Interceptor فرصت خواهد داشت به این Context مشترک، اطلاعاتی را اضافه کند یا تغییر دهد. مثلا به لیست خطاهای آن یک خطای اعتبارسنجی جدید را اضافه کند.
اشتراک‌ها
انتشار نسخه اول پیش‌نمایش دات‌نت ۸

Welcome to .NET 8! The first preview is ready for you to download: claim your copy of the first .NET 8 preview and start building applications today. Scroll down to see the list of features included in this preview. .NET 8 is a long-term support (LTS) release. This blog post covers the major themes and goals that drive the prioritization and selection of enhancements to develop. .NET 8 preview and release candidate builds will be delivered monthly. As usual, the final release will be delivered sometime in November at .NET Conf. 

انتشار نسخه اول پیش‌نمایش دات‌نت ۸
مطالب
تغییرات Logging در ASP.NET Core 6x
فرض کنید با استفاده از روش متداول زیر، کار ثبت یک واقعه را انجام داده‌اید:
public class TestController
{
    private readonly ILogger<TestController> _logger;
    public TestController(ILogger<TestController> logger)
    {
        _logger = logger;
    }

   [HttpGet("/")]
    public string Get()
    {
        _logger.LogInformation("hello world");
          return "Hello world!";
    }
}
در یک برنامه‌ی متداول ASP.NET Core، زیرساخت کار با ILogger از پیش تنظیم شده‌است. برای کار با آن فقط کافی است به نمونه‌های ILogger و یا <ILogger<T از طریق سیستم تزریق وابستگی‌ها دسترسی یافت و سپس متدهای الحاقی آن‌را مانند LogInformation فراخوانی کرد.

اگر یک چنین برنامه‌ای را به دات نت 6 ارتقاء دهید، با پیام اخطار زیر مواجه خواهید شد:
CA1848: For improved performance, use the LoggerMessage delegates instead of calling LogInformation
به صورت خلاصه، تمام متدهای پیشین LogInformation، LogDebug و امثال آن در دات نت 6 منسوخ شده درنظر گرفته می‌شوند! دلیل آن‌را در ادامه بررسی خواهیم کرد.


استفاده‌ی گسترده از source generators در دات نت 6

source generators، امکان مداخله در عملیات کامپایل برنامه را میسر کرده و امکان تولید کدهای پویایی را در زمان کامپایل، فراهم می‌کنند. هرچند این قابلیت به همراه دات نت 5 ارائه شدند، اما تا زمان دات نت 6 استفاده‌ی گسترده‌ای از آن در خود دات نت صورت نگرفت. موارد زیر، تغییراتی است که بر اساس source generators در دات نت 6 رخ داده‌اند:
- source generators مخصوص ILogger (موضوع این بحث؛ یعنی LoggerMessage source generator)
- source generators مخصوص System.Text.Json تا سربار تبدیل به JSON و یا برعکس کمتر شود.
- بازنویسی مجدد پروسه‌ی کامپایل Blazor/Razor بر اساس source generators، بجای روش دو مرحله‌ای قبلی که امکان Hot Reload را فراهم کرده‌است.

نوشتن یک source generator هرچند ساده نیست، اما چون نیاز به reflection را به حداقل می‌رساند، می‌تواند تغییرات کارآیی بسیار مثبتی را به همراه داشته باشد.


توصیه به استفاده از LoggerMessage.Define در دات نت 6

ILogger به همراه قابلیت‌هایی مانند structural logging نیز هست که امکان فرمت بهتر پیام‌های ثبت شده را میسر می‌کند تا توسط برنامه‌های جانبی که قرار است این لاگ‌ها را پردازش کنند، به سادگی قابل خواندن باشند. برای مثال رکورد زیر را در نظر بگیرید:
public record Person (int Id, string Name);
به همراه نمونه‌ای از آن:
var person = new Person(123, "Test");
خروجی لاگ زیر در این حالت:
_logger.LogInformation("hello to {Person}", person);
به صورت زیر خواهد بود:
info: TestController[0]
hello world to Person { Id = 123, Name = Test }
دقت کنید که رشته‌ی ارسالی به LogInformation به همراه $ نیست. یعنی از string interpolation استفاده نشده‌است و نام پارامتر تعریف شده (placeholder name) با حروف بزرگ شروع شده‌است.

اگر در اینجا مانند مثال زیر از string interpolation استفاده شود:
_logger.LogInformation($"hello world to {person}"); // Using interpolation instead of structured logging
هرچند کار با آن ساده‌تر است از string.Format، اما برای عملیات ثبت وقایع با کارآیی بالا توصیه نمی‌شود؛ به این دلایل:
- ویژگی «لاگ‌های ساختار یافته» را از دست می‌دهیم و دیگر توسط نرم افزارهای ثالث لاگ خوان، به سادگی پردازش نخواهند شد.
- ویژگی «قالب ثابت» پیام را نیز از دست خواهیم داد که باز هم یافتن پیام‌های مشابه را در بین انبوهی از لاگ‌های رسیده مشکل می‌کند.
-  کار serialization شیء ارسالی به آن، پیش از عملیات ثبت وقایع رخ می‌دهد. اما ممکن است سطح لاگ سیستم در این حد نباشد و اصلا این پیام لاگ نشود. در این حالت یک کار اضافی صورت گرفته و بر روی کارآیی برنامه تاثیر منفی خواهد گذاشت.

برای جلوگیری از serialization و همچنین تخصیص حافظه‌ی اضافی و مشکلات عدم ساختار یافته بودن لاگ‌ها، توصیه شده‌است که ابتدا سطح لاگ مدنظر بررسی شود و همچنین از string interpolation استفاده نشود:
if (_logger.IsEnabled(LogLevel.Information))
{
   _logger.LogInformation("hello world to {Person}", person);
}
البته مشکل این روش، تکرار این if/else‌ها در تمام برنامه‌است و همچنین باید دقت داشت که LogLevel انتخابی، با متد لاگ، هماهنگی دارد.
مشکل دیگر لاگ‌های ساختار یافته، امکان فراموش کردن یکی از پارامترها است که با یک خطای زمان اجرا گوشزد خواهد شد؛ مانند مثال زیر:
_logger.LogInformation("hello world to {Person} because {Reason}", person);
اکنون در دات نت 6 با پیام اخطار CA1848 که در ابتدای بحث مشاهده کردید، توصیه می‌کنند که اگر قالب نهایی خاصی را مدنظر دارید، آن‌را توسط متد LoggerMessage.Define دقیقا مشخص کنید:
private static readonly Action<ILogger, Person, Exception?> _logHelloWorld =
    LoggerMessage.Define<Person>(
        logLevel: LogLevel.Information,
        eventId: 0,
        formatString: "hello world to {Person}");
در این روش جدید باید یک Action را برای لاگ کردن پیام‌ها تهیه کرد که از همان ابتدا LogLevel آن مشخص است (و نیازی به بررسی مجزا ندارد؛ یعنی خودش logger.IsEnabled را فراخوانی می‌کند) و همچنین از روش لاگ ساختار یافته استفاده می‌کند. مزیت این روش کش شدن قالب لاگ، در بار اول فراخوانی آن است ( برخلاف متدهای الحاقی مانند LogInformation که هربار باید این قالب‌ها را پردازش کنند) و همچنین در اینجا دیگر خبری از boxing و تبدیل نوع پارامترها نیست.

اکنون روش فراخوانی این Action با کارآیی بالا به صورت زیر است:
[HttpGet("/")]
public string Get()
{
    var person = new Person(123, "Test");
    _logHelloWorld(_logger, person, null);
      return "Hello world!";
}
همانطور که مشاهده می‌کنید اینبار دیگر حتی امکان فراموش کردن پارامتری وجود ندارد (مشکلی که می‌تواند با LogInformation متداول رخ دهد).


معرفی [LoggerMessage] source generator در دات نت 6

هرچند LoggerMessage.Define، مزایای قابل توجهی مانند کش شدن قالب لاگ، عدم نیاز به بررسی ضرورت لاگ شدن پیام و ارسال تعداد پارامترهای صحیح را به همراه دارد، اما ... کار کردن با آن مشکل است و برای کار با آن باید کدهای زیادی را نوشت. به همین جهت با استفاده از قابلیت source generators، امکان تولید خودکار این نوع کدها در زمان کامپایل برنامه پیش‌بینی شده‌است:
public partial class TestController
{
   [LoggerMessage(0, LogLevel.Information, "hello world to {Person}")]
   partial void LogHelloWorld(Person person);
}
این قطعه کد، LoggerMessage.Define را به صورت خودکار برای ما تولید می‌کند. برای اینکار باید یک متد partial را تهیه کرد و سپس آن‌را به ویژگی جدید LoggerMessage مزین کرد. پس از آن source generator، مابقی کارها را در زمان کامپایل برنامه انجام می‌دهد.
ویژگی partial method، امکان تعریف یک متد را در یک فایل و سپس ارائه‌ی پیاده سازی آن‌را در فایلی دیگر میسر می‌کند که البته در اینجا آن فایل دیگر، توسط source generator تولید می‌شود.
باید دقت داشت که در اینجا TestController را نیز باید به صورت partial تعریف کرد تا آن نیز قابلیت بسط در چند فایل را پیدا کند. همچنین متد فوق را به صورت static partial void نیز می‌توان نوشت.

یکی از مزایای کار با source generator که خودش در اصل یک آنالایزر هم هست، بررسی تعداد پارامترهای ارسالی و تعریف شده‌است:
[LoggerMessage(0, LogLevel.Information, "hello world to {Person} with a {Reason}")]
partial void LogHelloWorld(Person person);
برای مثال در اینجا متد LogHelloWorld یک پارامتر دارد اما LoggerMessage آن به همراه دو پارامتر تعریف شده‌است که این مشکل در زمان کامپایل تشخیص داده شده و گوشزد می‌شود (برخلاف روش‌های پیشین که در زمان اجرا این نوع مشکلات نمایان می‌شدند).

در این روش، امکان ذکر پارامتر اختیاری LogLevel هم وجود دارد؛ اگر نیاز است مقدار آن به صورت پویا تغییر کند:
[LoggerMessage(Message = "hello world to {Person}")]
partial void LogHelloWorld(LogLevel logLevel, Person person);