‫ارتقاهای CLI در NET 10 Preview 3.: نصب محلی SDK، تکمیل خط‌فرمان، حالت تعاملی و بیشتر

نسخه .NET 10 Preview 3 که در آوریل 2025 منتشر شد، مجموعه‌ای از بهبودها و ویژگی‌های جدید را برای رابط خط فرمان (CLI) معرفی کرده است که تجربه کاربری توسعه‌دهندگان را به‌طور قابل‌توجهی بهبود می‌بخشد. این ارتقاها شامل پشتیبانی پیشرفته برای تکمیل خط‌فرمان (Shell Completion)، حالت تعاملی پیش‌فرض (Interactive Mode)، نصب محلی SDK و انتشار ساده‌تر کانتینرها هستند.

یکی از مهم‌ترین بازخوردهای کاربران .NET CLI در نظرسنجی‌های اخیر، نیاز به بهبود قابلیت تکمیل خط‌فرمان بود. تکمیل خط‌فرمان به توسعه‌دهندگان امکان می‌دهد با تایپ بخشی از یک دستور و فشردن کلید Tab، پیشنهادهایی برای تکمیل دستورات، گزینه‌ها یا حتی نام بسته‌های NuGet دریافت کنند. در نسخه‌های قبلی، راه‌اندازی این قابلیت پیچیده و عملکرد آن کند بود. در .NET 10 Preview 3، مایکروسافت با معرفی دستور جدید dotnet completions generate [SHELL] این مشکل را برطرف کرده است.

این دستور اسکریپت‌های تکمیل پوسته را برای پوسته‌های محبوب مانند Bash، Fish، Nushell، PowerShell و Zsh تولید می‌کند. بسته به پوسته مورد استفاده، سطح ادغام متفاوت است. به‌عنوان مثال، در PowerShell، اسکریپت تولیدشده کاملاً با قابلیت‌های بومی پوسته ادغام شده و عملکرد سریعی ارائه می‌دهد. در مقابل، برای Nushell، ادغام محدودتر است اما همچنان کاربردی است. برای فعال‌سازی این قابلیت، توسعه‌دهندگان باید اسکریپت تولیدشده را به فایل پیکربندی پوسته خود (مانند .bashrc برای Bash یا $PROFILE برای PowerShell) اضافه کنند. مثال زیر نحوه فعال‌سازی تکمیل پوسته در Bash را نشان می‌دهد:

# افزودن تکمیل پوسته برای .NET CLI به Bash
dotnet completions generate bash >> ~/.bashrc
source ~/.bashrc

پس از اعمال این تنظیمات، با تایپ dotnet و فشردن Tab، لیستی از دستورات ممکن نمایش داده می‌شود. این قابلیت حتی برای تکمیل نام بسته‌های NuGet در دستوراتی مانند dotnet add package نیز کار می‌کند، که تجربه کاربری را به‌ویژه در پروژه‌های بزرگ بهبود می‌بخشد. توسعه‌دهندگان می‌توانند با ثبت درخواست در مخزن GitHub دات‌نت، پشتیبانی از پوسته‌های دیگر را پیشنهاد دهند یا حتی خودشان این قابلیت را توسعه دهند، زیرا مدل تکمیل پوسته در .NET 10 به‌صورت افزونه‌پذیر طراحی شده است.

بسیاری از دستورات .NET CLI، مانند dotnet build، dotnet publish یا dotnet pack، ممکن است نیاز به احراز هویت با مخازن NuGet داشته باشند. در نسخه‌های قبلی، توسعه‌دهندگان مجبور بودند به‌صورت دستی پرچم --interactive را به دستورات اضافه کنند تا ارائه‌دهندگان اعتبار (Credential Providers) بتوانند به‌صورت پویا عمل کنند. عدم استفاده از این پرچم منجر به خطاهایی مانند عدم دسترسی به مخزن NuGet می‌شد.

در .NET 10 Preview 3، پرچم --interactive به‌صورت پیش‌فرض برای دستوراتی که در یک محیط تعاملی (مانند ترمینال در حضور کاربر) اجرا می‌شوند، فعال است. این قابلیت با استفاده از منطقی مشابه با لوگر ترمینال MSBuild که در .NET 8 معرفی شد، تشخیص می‌دهد که آیا دستور در یک محیط CI/CD (مانند سرورهای ساخت) اجرا می‌شود یا خیر. در محیط‌های غیرتعاملی، این پرچم به‌صورت خودکار غیرفعال می‌شود تا از توقف‌های ناخواسته جلوگیری شود. توسعه‌دهندگان همچنان می‌توانند با استفاده از --interactive false این رفتار را غیرفعال کنند.

این تغییر تجربه کاربری را به‌ویژه برای توسعه‌دهندگانی که با مخازن خصوصی NuGet کار می‌کنند، ساده‌تر می‌کند. در آینده، پرچم --interactive ممکن است برای قابلیت‌های دیگری مانند نمایش اعلان‌ها (Prompts) یا نوارهای پیشرفت (Progress Bars) نیز استفاده شود، که CLI را کاربرپسندتر خواهد کرد.

یکی از چالش‌های توسعه‌دهندگان .NET، مدیریت نسخه‌های مختلف SDK در پروژه‌های متعدد است. در نسخه‌های قبلی، نصب یک نسخه خاص از SDK معمولاً به‌صورت سراسری انجام می‌شد، که می‌توانست باعث تداخل در سایر پروژه‌ها شود. .NET 10 Preview 3 با معرفی ویژگی نصب محلی SDK از طریق فایل global.json این مشکل را حل کرده است.

توسعه‌دهندگان می‌توانند با افزودن یک عنصر paths به فایل global.json، مسیرهای سفارشی را برای جستجوی SDK مشخص کنند. این امکان را فراهم می‌کند که یک نسخه خاص از SDK فقط در یک مخزن (Repository) خاص استفاده شود، بدون تأثیر بر نصب سراسری. به‌عنوان مثال، فرض کنید در یک مخزن، فایل global.json به‌صورت زیر تنظیم شده است:

{
  "sdk": {
    "version": "10.0.100-preview.3",
    "paths": [
      "./.dotnet"
    ]
  }
}

در این حالت، CLI نسخه SDK موجود در مسیر ./.dotnet را برای آن مخزن استفاده می‌کند، اما خارج از این مخزن به نصب سراسری بازمی‌گردد. این ویژگی برای تیم‌هایی که روی پروژه‌های متعدد با نسخه‌های مختلف SDK کار می‌کنند، بسیار مفید است. همچنین، ابزارهای IDE مانند Visual Studio می‌توانند از این اطلاعات برای تنظیم خودکار مسیر SDK استفاده کنند، بدون نیاز به تنظیمات دستی پیچیده.

انتشار برنامه‌ها به‌صورت کانتینر (Container) در سال‌های اخیر به یکی از روش‌های استاندارد در توسعه برنامه‌های مدرن تبدیل شده است. در نسخه‌های قبلی .NET، برای انتشار یک پروژه به‌صورت کانتینر، توسعه‌دهندگان باید خاصیت <EnableSdkContainerSupport> را در فایل پروژه تنظیم می‌کردند. در .NET 10 Preview 3، این الزام حذف شده و هر پروژه‌ای که قابلیت انتشار داشته باشد، به‌صورت پیش‌فرض می‌تواند به‌عنوان کانتینر منتشر شود.

برای مثال، یک پروژه کنسول ساده را می‌توان با دستور زیر به‌عنوان کانتینر منتشر کرد، بدون نیاز به تغییرات اضافی در فایل پروژه:

dotnet publish /t:PublishContainer

این دستور یک تصویر کانتینر (Container Image) تولید می‌کند که می‌تواند مستقیماً در Docker اجرا شود. این ساده‌سازی به توسعه‌دهندگان امکان می‌دهد تا با حداقل پیکربندی، برنامه‌های خود را در محیط‌های ابری یا محلی مستقر کنند. این ویژگی به‌ویژه برای توسعه‌دهندگانی که در حال انتقال به معماری‌های مبتنی بر میکروسرویس هستند، ارزشمند است.

.NET 10 Preview 3 با تمرکز بر بهبود رابط خط فرمان (CLI)، گام‌های مهمی در جهت افزایش بهره‌وری و راحتی توسعه‌دهندگان برداشته است. ویژگی‌هایی مانند تکمیل پوسته، حالت تعاملی پیش‌فرض، نصب محلی SDK و انتشار ساده‌تر کانتینرها، نه‌تنها تجربه کاربری را بهبود می‌بخشند، بلکه انعطاف‌پذیری و کارایی بیشتری را در پروژه‌های پیچیده فراهم می‌کنند. توسعه‌دهندگان می‌توانند با به‌کارگیری این ابزارها، فرآیندهای توسعه و استقرار خود را ساده‌تر و سریع‌تر کنند.