วิธีรันไฟล์ C# โดยตรงด้วย `dotnet run app.cs`

(devblogs.microsoft.com)

4 คะแนน โดย GN⁺ 2025-05-30 | 4 ความคิดเห็น | แชร์ทาง WhatsApp

ตั้งแต่ .NET 10 Preview 4 เป็นต้นไป ได้เพิ่มความสามารถในการรันไฟล์ C# เดี่ยวได้ทันทีด้วย dotnet run app.cs ทำให้สามารถรันโค้ด C# ได้แม้ ไม่มีไฟล์โปรเจ็กต์
ด้วย file-based apps การรันสคริปต์แบบง่าย การทดสอบ และการลองไอเดียจึงทำได้สะดวกขึ้นมาก คล้ายกับ Python หรือ JavaScript
ยังสามารถจัดการ การอ้างอิงแพ็กเกจ NuGet, การระบุ SDK, การตั้งค่า build properties ผ่าน directive ภายในไฟล์ได้ ช่วยเพิ่มความยืดหยุ่นในการพัฒนา
รองรับ shebang จึงนำไปใช้กับ CLI utility หรือสคริปต์อัตโนมัติบนระบบตระกูลยูนิกซ์ได้
หากต้องการ ยังสามารถแปลงเป็น แอปแบบอิงโปรเจ็กต์ ได้อย่างลื่นไหล ทำให้เชื่อมต่อจากการเรียนรู้และการทำต้นแบบไปสู่การพัฒนาแอปจริงได้อย่างเป็นธรรมชาติ

`dotnet run app.cs` คืออะไร

เดิมที หากต้องการรันโค้ด C# ด้วย dotnet CLI จะต้องมีโครงสร้าง โปรเจ็กต์ (.csproj) เสมอ
ตอนนี้สามารถรันได้ทันทีด้วยไฟล์ .cs เดี่ยว เพียงไฟล์เดียว ทำให้ลดอุปสรรคในการเริ่มต้นลงอย่างมาก
เหมาะกับการใช้งานหลากหลาย เช่น ภาษาสคริปต์ งานอัตโนมัติ การทดลอง และการเรียนรู้
ด้วยการ ผสานรวมกับ CLI จึงใช้งานได้ทันทีหากมี dotnet โดยไม่ต้องติดตั้งเครื่องมือเพิ่ม
เมื่อโค้ดใหญ่ขึ้น ก็สามารถขยายไปเป็นแอปแบบอิงโปรเจ็กต์ได้ด้วยภาษาและเครื่องมือชุดเดิม

รองรับ directive ระดับไฟล์

ใน file-based apps ก็สามารถประกาศการตั้งค่าหลักของโปรเจ็กต์เป็น directive ภายในไฟล์ .cs ได้โดยตรง

การอ้างอิงแพ็กเกจ NuGet

สามารถอ้างอิง แพ็กเกจ NuGet ได้ทันทีด้วย directive #:package

ตัวอย่าง:

#:package Humanizer@2.14.1  

using Humanizer;  

var dotNet9Released = DateTimeOffset.Parse("2024-12-03");  
var since = DateTimeOffset.Now - dotNet9Released;  

Console.WriteLine($"It has been {since.Humanize()} since .NET 9 was released.");

การระบุ SDK
- สามารถระบุ ประเภทของ SDK ได้ด้วย directive #:sdk
  - ตัวอย่าง:
```
#:sdk Microsoft.NET.Sdk.Web  
```
  - ยังสามารถเปิดใช้ความสามารถของ ASP.NET Core (minimal API, MVC เป็นต้น) ได้ด้วย
การตั้งค่า MSBuild properties
- สามารถระบุ build properties ได้โดยตรงด้วย #:property
  - ตัวอย่าง:
```
#:property LangVersion preview  
```
รองรับ shebang สำหรับเชลล์สคริปต์
- ใส่ #!/usr/bin/dotnet run ไว้บนสุดของไฟล์ เพื่อใช้งานเป็น ไฟล์รันได้โดยตรงบนระบบตระกูลยูนิกซ์
  - ตัวอย่าง:
```
#!/usr/bin/dotnet run  
Console.WriteLine("Hello from a C# script!");  
```
  - ให้สิทธิ์รันแล้วใช้งานได้ทันที:
```
chmod +x app.cs  
./app.cs  
```

การแปลงเป็นแอปแบบอิงโปรเจ็กต์

เมื่อแอปมีขนาดใหญ่ขึ้นหรือจำเป็นต้องใช้ความสามารถเพิ่มเติม สามารถแปลงเป็น โปรเจ็กต์ได้อย่างง่ายดาย ด้วยคำสั่ง dotnet project convert app.cs
directive จะถูกแปลงเป็น properties, references ฯลฯ ในไฟล์ .csproj โดยอัตโนมัติ

ตัวอย่างการแปลง

ไฟล์ตัวอย่างด้านล่าง:

#:sdk Microsoft.NET.Sdk.Web  
#:package Microsoft.AspNetCore.OpenApi@10.*-*  

var builder = WebApplication.CreateBuilder();  
builder.Services.AddOpenApi();  
var app = builder.Build();  
app.MapGet("/", () => "Hello, world!");  
app.Run();

ผลลัพธ์หลังแปลง:

<Project Sdk="Microsoft.NET.Sdk.Web">  
  <PropertyGroup>  
    <TargetFramework>net10.0</TargetFramework>  
    <ImplicitUsings>enable</ImplicitUsings>  
    <Nullable>enable</Nullable>  
  </PropertyGroup>  
  <ItemGroup>  
    <PackageReference Include="Microsoft.AspNetCore.OpenApi" Version="10.*-*" />  
  </ItemGroup>  
</Project>

ความแตกต่างจากแนวทาง C# script แบบเดิม

ก่อนหน้านี้แม้จะสามารถรัน C# script ได้ด้วยเครื่องมือจากชุมชน เช่น CS-Script, dotnet-script, Cake เป็นต้น แต่จำเป็นต้องติดตั้งและตั้งค่าเครื่องมือแยกต่างหาก
ตอนนี้สามารถใช้ คอมไพเลอร์และภาษา C# ชุดเดียวกันได้เลยโดยไม่ต้องติดตั้งเพิ่มหรือเข้าโหมดพิเศษ ทำให้รันโค้ดได้ทันทีโดยแทบไม่มีอุปสรรค

วิธีเริ่มต้น

ติดตั้ง .NET 10 Preview 4
หากใช้ Visual Studio Code ต้องติดตั้ง C# Dev Kit และ ส่วนขยาย C# เวอร์ชันพรีรีลีสล่าสุด (2.79.8 ขึ้นไป)
สร้างไฟล์ .cs แล้วเขียนโค้ดได้ทันที
รัน dotnet run hello.cs ในเทอร์มินัล
หากต้องการ สามารถแปลงเป็นโปรเจ็กต์ด้วย dotnet project convert hello.cs

อ่านเพิ่มเติม

เดโมในเซสชัน Microsoft Build: No projects, just C# with dotnet run app.cs

แผนในอนาคต

มีแผนเพิ่มการรองรับ file-based apps ใน VS Code และปรับปรุง IntelliSense สำหรับ directive รวมถึงประสิทธิภาพและการดีบัก
กำลังพัฒนาความสามารถเพิ่มเติม เช่น รองรับหลายไฟล์ และการปรับปรุงความเร็วในการรัน
dotnet run app.cs ช่วยให้เข้าถึง C# ได้ง่ายขึ้น โดยยังคงมอบพลังของ .NET ไว้อย่างครบถ้วน
เป็นพื้นฐานที่ช่วยให้เปลี่ยนผ่านจากการทำต้นแบบ การศึกษา ไปจนถึงการพัฒนาโปรดักชันได้รวดเร็วยิ่งขึ้น

4 ความคิดเห็น

rkttu 2025-08-18

ประสบการณ์ DX ที่ให้การเติมโค้ดอัตโนมัติบนพื้นฐาน File-based App มีให้ใช้งานอยู่แล้วใน C# extension เวอร์ชันล่าสุด แต่เดิม Microsoft ไม่ได้เผยแพร่ส่วนขยายนี้นอกเหนือจาก VS Code Marketplace

เพื่อแก้ความไม่สะดวกนี้ จึงได้แยกเฉพาะส่วน C# Extension ของ C# Dev Kit (ส่วนที่ใช้ไลเซนส์ MIT) มาทำ autobuild/auto-publish แยกต่างหากและลงทะเบียนไว้บน OpenVSX พร้อมแชร์วิดีโอเดโมสั้น ๆ ที่อิงกับ Kiro ตามนี้

https://www.youtube.com/watch?v=pIi7CWOPQSA

ndrgrd 2025-05-31

ตอนที่ก่อนหน้านี้ผมเคยใช้ฟีเจอร์ C# Interactive แพ็กเกจที่ไม่ได้ติดตั้งไว้ในเครื่องจะใช้งานไม่ได้ แต่ดูเหมือนว่าตอนนี้มันถูกปรับปรุงแล้วนะครับ

GN⁺ 2025-05-30

ความคิดเห็นจาก Hacker News

ฟีเจอร์นี้ดูเหมือนจะส่งผลต่อประสิทธิภาพการทำงานของนักพัฒนา .NET ได้มาก เลยอดสงสัยไม่ได้ว่าทำไมเพิ่งมีตอนนี้ และยังมีอีกอย่างที่อยากได้มากในโปรเจ็กต์ .NET คือความสามารถในการกำหนด custom command ต่อโปรเจ็กต์ได้ง่าย ๆ แบบ npm run <command>
- ผมใช้ https://github.com/dotnet-script/dotnet-script อยู่โดยแทบไม่มีปัญหาอะไร แต่ถ้าข้ามขั้นตอนที่ยุ่งยากไปได้ก็คงดีกว่า
- หมายถึงอะไรแบบ https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-run หรือเปล่า
- ถ้ามีฟีเจอร์แบบนั้นจริงก็คงดีมาก ตอนนี้ผมทำแบบนั้นด้วย make file อยู่ https://www.gnu.org/software/make/
- จริง ๆ ก็คิดว่าการใช้ task runner แยกต่างหากอย่าง make หรือ task อาจจะดีกว่า
- เมื่อก่อนตอนต้องการอะไรแบบนี้ก็เคยใช้ LINQPad เหมือนกัน
น่าสนใจที่มีการโปรโมตให้ใช้สิ่งนี้ร่วมกับ shebang แบบจริงจัง แนวทางนี้ดูน่าดึงดูดทีเดียว Go ก็เคยเหมาะกับการใช้งานแบบสคริปต์ในลักษณะนี้ก่อนจะมีโมดูล และจำได้ว่า Ubuntu ก็เคยใช้แนวนี้เหมือนกัน แต่ผู้สร้าง Go ดูจะไม่ค่อยเห็นด้วยกับการใช้ Go เป็นภาษาสคริปต์แบบนี้
- ไม่ใช่ว่าผู้สร้าง Go คัดค้าน เพียงแต่เขาแนะนำให้ใช้ Go เป็นภาษาสำหรับการเขียนโปรแกรมเป็นหลัก เครื่องมืออย่าง gorun (https://github.com/erning/gorun) ก็ทำให้ใช้ Go แบบสคริปต์ได้ง่ายมานานแล้ว และช่วงหลังยังรองรับการรันแบบครั้งเดียวได้ตรง ๆ เช่น go run github.com/kardianos/json/cmd/jsondiff@v1.0.1 ซึ่งเป็นฟีเจอร์ที่เจ๋งมาก
- สงสัยว่าคำว่า ‘shebang’ เริ่มใช้กันตั้งแต่เมื่อไรและที่ไหน ตอนเรียนมหาวิทยาลัยและในแถบภาคใต้ช่วงยุค 90 ถึงต้นยุค 2000 ปกติจะเรียกว่า hashbang เพิ่งมาได้ยินคำว่า shebang ตอน C# เริ่มดัง ทั้งที่จริง ๆ แล้วคำนี้มีมาก่อนหน้านั้นนาน แค่ไม่เคยได้ยินในแวดวงรอบตัว
- ตอนเคยทำงานที่บริษัท .NET แห่งหนึ่ง มีคนจู่ ๆ ก็เขียนสคริปต์ automation ด้วย bash ขึ้นมา ทั้งที่ไม่มีความเชี่ยวชาญพอจะดูแลมันระยะยาว และคุณภาพก็ตั้งต้นมาไม่ดีอยู่แล้ว เลยไม่เข้าใจว่าทำไมไม่เขียนเครื่องมือนั้นเป็น C# ไปเลย ฟีเจอร์นี้อาจทำให้แนวทางแบบ C# กลายเป็นตัวเลือกที่ใช้งานได้จริงมากขึ้น
- ทำแบบนี้ได้ด้วย cargo ของ Rust เหมือนกัน แต่ยังไม่ใช่การรองรับอย่างเป็นทางการ https://rust-lang.github.io/rfcs/3424-cargo-script.html
ตัวฟีเจอร์ยอดเยี่ยม แต่ถึงจะคอมไพล์แล้วก็ยังมี startup overhead ราว 0.5 วินาที ทำให้ไม่เหมาะกับแอปจำนวนมาก ถึงอย่างนั้นการพึ่ง bash สำหรับ shell scripting ก็มีข้อจำกัด ยุคของ perl ก็ผ่านไปแล้ว และ Ruby ก็ยังยอดเยี่ยมที่สุดสำหรับงานลักษณะนี้เลยใช้อยู่เรื่อยมา ช่วงหลังย้ายสคริปต์บางส่วนไปเป็น Swift ซึ่งเป็นแบบ interpreter โดยพื้นฐาน จึงเร็วกว่าเยอะ และไฟล์รันที่คอมไพล์แล้วก็เปิดได้ทันทีจนประทับใจมาก ถึงขั้นลองทำ caching compiler สำหรับ Swift CLI app เองด้วย (https://github.com/jrz/tools) ส่วน dotnet run นั้นแคชผลการคอมไพล์ให้อยู่แล้ว จึงไม่ต้องมี caching layer เพิ่มเติม (ถ้าจะปิดใช้ให้ใส่ --no-build และถ้าจะดู path ของไบนารีให้ใช้ --artifacts-path)
- อยากรู้ว่าตัวเลข 0.5 วินาทีมาจากไหน ผมลองทดสอบกับ hello world ได้ 63ms และถ้าดู benchmark ของ CLI library ของ neuecc (https://neuecc.medium.com/consoleappframework-v5-zero-overhead-native-aot-compatible-cli-framework-for-c-8f496df8d9d1) ก็ไม่มีตัวไหนแตะ 0.5 วินาทีเลย อีกอย่างที่พูดว่า Swift เป็นแบบ interpreter โดยพื้นฐานนั้น .NET JIT เป็น tiered JIT จึงไม่ได้สร้างโค้ดขึ้นมาทันที แต่ทำงานเป็นหลายขั้น
- ได้ยินมาว่า dotnet เวอร์ชัน 10 หรือ 11 จะมีโหมด interpreted เต็มรูปแบบเข้ามา เลยสงสัยว่าโหมดนั้นจะใช้กับกรณีแบบนี้ได้ไหม https://github.com/dotnet/runtime/issues/112748
- ถ้าต่อให้คอมไพล์แล้วก็ยังมีอาการหน่วงช่วงเริ่มต้นอยู่บ้าง ก็สงสัยว่าทำไม Python ถึงได้รับความนิยมมากในด้านนี้
- ฟีเจอร์นี้ยังอยู่ในช่วงพรีวิวตอนต้น ๆ และในหลายงานประกาศก็พูดชัดว่าทีมรับรู้ปัญหาเรื่องความเร็วตอนเริ่มต้นและกำลังปรับปรุงอยู่
- ถ้าต้องการ startup ที่เร็วมาก ก็สามารถแปลงเป็น native code ได้ง่ายตามคู่มือ https://learn.microsoft.com/en-us/dotnet/core/deploying/
น่าเสียดายที่แทบไม่พูดถึงโปรเจ็กต์ CSX/VBX เลย https://ttu.github.io/dotnet-script/ และก็น่าแปลกที่ดูเหมือนจะตัดสินใจในแนวทางที่ไม่เข้ากันกับการจัดการ dependency ของ F# script บน C# runtime https://learn.microsoft.com/en-us/dotnet/fsharp/tools/fsharp-interactive/
- เรื่องที่บอกว่าความพยายามอย่าง CSX/VBX ไม่ถูกสะท้อนออกมา จริง ๆ มีการอ้างถึงแนวทางและเครื่องมือหลายแบบอย่างเป็นทางการอยู่แล้ว https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/#existing-ways-to-run-c#-without-projects
- ถามกลับว่าที่ว่าไม่เข้ากับ F# หมายถึงอะไร ถ้าหมายถึงความต่างของไวยากรณ์ ก็มีเหตุผลที่ตั้งใจทำให้ต่างกัน และไม่ต้องการสร้าง dialect แบบ C# script ขึ้นมาใหม่ จึงจงใจไม่รองรับบางอย่างอย่าง file import ซึ่งเป็นผลจากลักษณะเฉพาะของ C#
ใน Kotlin ก็มีฟีเจอร์คล้ายกัน https://github.com/Kotlin/kotlin-script-examples/blob/master/jvm/main-kts/MainKts.md (ที่นี่ต้องใช้นามสกุลไฟล์ *.main.kts เท่านั้นถึงจะทำงาน) แนวทางแบบนี้เหมาะมากกับสคริปต์เล็ก ๆ หรือการทำต้นแบบ และก็ใช้งานความสามารถของ JVM ได้จริงจังด้วย แต่สำหรับสคริปต์เล็ก ๆ Ruby ก็ยังสะดวกที่สุด โดยเฉพาะเวลาเรียกโปรแกรมภายนอกที่ไวยากรณ์ backtick ใช้ง่ายมาก
- Kotlin scripting คงไม่หายไปหมด แต่อนาคตอาจไม่ได้สดใสนัก https://blog.jetbrains.com/kotlin/2024/11/state-of-kotlin-scripting-2024/
- เหมือนจะจำได้ว่า Java เองก็มีแนวทางสคริปต์คล้าย ๆ กันแล้ว
ใช้ shebang เพื่อรันสคริปต์ C# แบบเดียวกับ bash script ได้ https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/#using-shebang-lines-for-shell-scripts
- ลองทดสอบ shebang เพื่อรันไฟล์ตรง ๆ บนอิมเมจ .net10 preview 4 sdk ตอนแรกไม่สำเร็จ แต่ dotnet run <file> ใช้งานได้ พออัปเดตก็ใช้งานได้ตามปกติ สาเหตุคือไฟล์ใช้การขึ้นบรรทัดใหม่แบบ CRLF แทน LF
- ดีใจมากที่ตอนนี้เขียนสคริปต์ที่มี type safety ได้แล้ว และบน macOS ต้องใช้ #!/usr/local/share/dotnet/dotnet run หรือ #!/usr/bin/env -S dotnet run ใน shebang
ดูเหมือนจะเป็นเครื่องมือที่ใช้แทน PowerShell ได้ PowerShell มีแนวโน้มจะกลายเป็นภาษาที่แทบใช้กับ ChatGPT โดยเฉพาะ ในหลายบริษัทสคริปต์ PowerShell ทำหน้าที่เป็นแกนหลักของอินฟราสตรักเจอร์ แต่บ่อยครั้งก็ลงเอยในสภาพเหมือน ‘อ่านได้อย่างเดียว’
- รู้สึกว่ามันมีศักยภาพจะเข้าไปแทนได้กว้างกว่านั้นมาก ถ้าเป็นทีม .NET ก็แทบไม่จำเป็นต้องไปจับ Python หรือ shell script เลย แค่ใส่ shebang ด้านบนแล้ววาง C# snippet ก็อาจจัดการงานสคริปต์ได้แทบทั้งหมด แม้แต่บริการทดสอบก็ไม่ต้องเขียนด้วย express.js แค่ทำด้วย ASP.NET minimal API แบบเร็ว ๆ ก็พอ
- ผู้ดูแลระบบ Windows น่าจะเป็นกลุ่มที่ใช้สคริปต์จาก ChatGPT ในปริมาณมหาศาลที่สุดหรือเปล่า ถ้าผมยังเป็นแอดมินอยู่ ด้วยระดับเอกสารทางการของ Microsoft ตอนนี้ก็คงต้องลองใช้แน่
- เรียกใช้โค้ด C# จาก PowerShell ก็ทำได้เช่นกัน https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/add-type?view=powershell-7.5
- การเขียนอินฟราสตรักเจอร์ทั้งหมดเป็นสคริปต์ PowerShell ไม่ใช่เรื่องง่ายจริง และถ้าทำแบบนั้นก็มักจะกลายเป็นความโกลาหล ในทางปฏิบัติพอเกินระดับฟังก์ชันไม่กี่ตัว C# จะมีประสิทธิภาพกว่ามากและอุปสรรคในการเริ่มใช้ก็แทบไม่มี PowerShell เหมาะที่สุดกับสคริปต์ ad-hoc ขนาดเล็ก และตอนนี้ก็ครองตำแหน่ง ‘ภาษาสคริปต์มาตรฐานของ Windows’ แบบเดียวกับที่ VBScript เคยเป็น
- เพราะ PowerShell รันโค้ด .NET ได้โดยตรง จึงอาจมองได้ว่าเป็นการขยายประสบการณ์ของ PowerShell ไปอีกทางด้วย
ดูเหมือนจะมาแทนฟีเจอร์ของ NetPad ได้แทบทั้งหมด และถ้าเพิ่มการดีบักเข้ามาได้ก็มีลุ้นว่า LINQPad อาจถูกเบียดตกจากการใช้งานหลัก ผมเองก็เคยได้ประโยชน์จาก LINQPad มาก แต่ประสบการณ์แบบ text editor ของมันยังอึดอัดเกินไปสำหรับยุคนี้ จะใช้เขียนหรือแก้โค้ดจริงจังก็ยังมีข้อจำกัด
- สำหรับผม แก่นของ LINQPad คือการโต้ตอบกับฐานข้อมูลและการสำรวจค่าด้วย .dump() ส่วน dotnet run ตัวนี้น่าจะเป็นเครื่องมือที่เข้ามาเติมเต็มมากกว่า เมื่อก่อนเคยอยู่ในที่ที่เกลียด PowerShell มากและใช้ LINQPad ทำงานสคริปต์แทบทั้งหมด ซึ่งในบริบทแบบนั้นมันก็ใช้ได้ดี
- LINQPad เป็นผลิตภัณฑ์ที่ไม่เหมือนใครในโลก .NET แต่ตัว text editor ของมันบางทีก็แย่มากจนเกือบสุด ๆ อยากให้เปลี่ยนไปใช้ editor อย่าง neovim หรือ monaco ส่วนการแสดงผลตารางและความลื่นยังดีมาก แต่พอเทียบกับเทคโนโลยีแนว ‘notebook’ อย่าง Jupyter Notebook ทุกวันนี้ ขอบเขตการใช้งานก็ดูแคบกว่า อาจเพราะเป็นงานของนักพัฒนาเดี่ยวด้วย ถึงอย่างนั้นเวลาทำงานกับข้อมูล SQL ทุกวัน LINQPad ก็ยังดีที่สุดอยู่ดี
- LINQPad คงยังไม่ถูกแทนที่ทันที ผมคิดว่าครึ่งหนึ่งของจุดแข็งอยู่ที่ UI เลยสงสัยว่าประสบการณ์ใช้ dotnet run ใน VSCode หรือ Visual Studio จะใกล้เคียงกับ LINQPad แค่ไหน จุดเด่นของ LINQPad คือการแสดงผลลัพธ์แบบภาพ ถ้า dotnet run แสดงได้แค่ข้อความหรือจำเป็นต้องมีปลั๊กอินเพิ่มเยอะ ความต้องการ LINQPad ก็คงยังอยู่ แต่ถ้าต้องการแค่เช็กไวยากรณ์อะไรบางอย่าง dotnet run อาจเป็นตัวเลือกที่ดีกว่า ผมเองก็บางครั้งลองไวยากรณ์ที่ไม่แน่ใจใน LINQPad เหมือนกัน
- ถ้ายังไม่ได้ทำฟีเจอร์ GUI และจุดขยายต่าง ๆ ให้ครบ ก็คงแทน LINQPad ตรง ๆ ได้ยาก
ตื่นเต้นกับฟีเจอร์นี้มาก น่าจะใช้แทนสคริปต์ PowerShell บางส่วนที่ผมใช้ใน CI/CD pipeline ได้ ผมชอบทั้ง PowerShell และ Bash แต่มีงานบางแบบที่คิดแก้ปัญหาเป็นภาษาตระกูล C ในหัวแล้วมีประสิทธิภาพกว่ามาก และฟีเจอร์นี้น่าจะมาเติมช่องว่างนั้นได้
ในข้อเสนอจริง (https://github.com/dotnet/sdk/blob/main/documentation/general/dotnet-run-file.md) มีข้อมูลเพิ่มเติมอีกหลายอย่าง โดยเฉพาะเรื่องการจัดการหลายไฟล์และรายละเอียดการทำงานภายใน เช่น implicit project file

rkttu 2025-05-30

ผมได้ลองทำตัวอย่างใช้งานจริงที่เกี่ยวกับฟีเจอร์นี้ไว้ 2 ตัวอย่าง เลยมาแชร์ไว้ในคอมเมนต์ตอบกลับครับ เป็นโค้ดตัวอย่างแอป GUI สำหรับ Windows และ macOS ที่ใช้ MCP server และ Avalonia 😊

https://forum.dotnetdev.kr/t/…