ร่วมสร้างที่เก็บเอกสาร .NET

ขอขอบคุณที่สนใจการร่วมสร้างเอกสาร .NET

เอกสารนี้ครอบคลุมถึงกระบวนการร่วมสร้างบทความและตัวอย่างโค้ดที่โฮสต์อยู่ใน ไซต์เอกสาร .NET การร่วมสร้างอาจทำได้แบบง่าย เช่น การแก้ไขข้อผิดพลาดจากการพิมพ์ผิด หรือแบบซับซ้อน เช่น การเขียนบทความใหม่

ไซต์เอกสาร .NET ถูกสร้างขึ้นจากที่เก็บข้อมูลหลายรายการ ต่อไปนี้เป็นเพียงบางส่วน:

• บทความเชิงแนวคิดและส่วนย่อยของโค้ด .NET
• ตัวอย่างและส่วนย่อยของโค้ด
• การอ้างอิง .NET API
• การอ้างอิง .NET Compiler Platform SDK
• การอ้างอิง ML.NET API

คู่มือแนะนำสำหรับการร่วมสร้าง

เราขอขอบคุณการร่วมสร้างของชุมชนในการจัดทําเอกสาร รายการต่อไปนี้แสดงกฎแนะนําที่ควรทราบเมื่อคุณกําลังร่วมสร้างเอกสาร .NET:

• อย่าแปลกใจกับคำขอดึงข้อมูลที่มีขนาดใหญ่ แต่ให้ส่งประเด็นและเริ่มต้นการสนทนาเพื่อให้เราสามารถเห็นด้วยกับทิศทางก่อนที่คุณจะลงทุนเป็นจำนวนมาก
• อย่า รวมโค้ดตัวอย่างแบบอินไลน์ในบทความ
• ใช้ โครงการส่วนย่อยที่มีโค้ดเพื่อฝังในบทความ
• ปฏิบัติตามคำแนะนำและหลักเกณฑ์เสียงและโทน
• ใช้ไฟล์แม่แบบเป็นจุดเริ่มต้นในการทำงานของคุณ
• สร้างสาขาแยกต่างหากบนสำเนาของคุณก่อนที่จะทำงานกับบทความ
• ปฏิบัติตาม โฟลว์ของ GitHub
• โพสต์บล็อกและทวีต (หรืออะไรก็ตาม) เกี่ยวกับการร่วมสร้างของคุณหากคุณต้องการ!

ปฏิบัติตามหลักเกณฑ์เหล่านี้จะช่วยให้คุณและเรามีประสบการณ์ที่ดียิ่งขึ้น

กระบวนการร่วมสร้าง

ขั้นตอนที่ 1: หากคุณสนใจที่จะเขียนเนื้อหาใหม่หรือแก้ไขเนื้อหาที่มีอยู่อย่างละเอียด ให้เปิดประเด็นที่อธิบายสิ่งที่คุณต้องการทํา เนื้อหาภายใน โฟลเดอร์เอกสาร ถูกจัดอยู่ในส่วนที่แสดงในสารบัญ (TOC) กำหนดจุดที่จะใส่หัวข้อใน TOC รับข้อเสนอแนะเกี่ยวกับข้อเสนอของคุณ

หรือ

เลือกประเด็นที่มีอยู่และตำแหน่งที่เกิดประเด็น คุณสามารถดูรายการ เปิดประเด็น ของเราและอาสาทำงานในสิ่งที่คุณสนใจ ได้แก่:

• กรองตาม ป้ายชื่อปัญหา แรกที่ดีสําหรับประเด็นแรกที่ดี
• กรองตาม ความช่วยเหลือที่ต้องการ ป้ายชื่อสําหรับปัญหาที่เหมาะสมสําหรับการสนับสนุนชุมชน โดยทั่วไป ประเด็นเหล่านี้ต้องการบริบทน้อยที่สุด
• ผู้สนับสนุนที่มีประสบการณ์สามารถแก้ไขประเด็นใดก็ตามที่น่าสนใจ

เมื่อคุณพบประเด็นในการทำงาน ให้เพิ่มความคิดเห็นเพื่อถามว่าเปิดอยู่หรือไม่

เมื่อคุณเลือกภารกิจที่ต้องการแล้ว ให้ สร้างบัญชี GitHub และไปที่ขั้นตอนที่ 2

ขั้นตอนที่ 2: สําเนา /dotnet/docs repo (หรือ repo ใดก็ตามที่คุณมีส่วนร่วม) ตามความจําเป็นและสร้างสาขาสําหรับการเปลี่ยนแปลงของคุณ

สําหรับการเปลี่ยนแปลงเล็กน้อย ดูแก้ไขในเบราว์เซอร์

ขั้นที่ 3: ทำการเปลี่ยนแปลงในสาขาใหม่นี้

ถ้าเป็นหัวข้อใหม่ คุณสามารถใช้้ไฟล์แม่แบบนี้เป็นจุดเริ่มต้น ซึ่งประกอบด้วยหลักเกณฑ์ในการเขียนและอธิบายถึงเมตาดาต้าที่จำเป็นสำหรับแต่ละบทความ เช่น ข้อมูลผู้เขียน สําหรับข้อมูลเพิ่มเติมเกี่ยวกับไวยากรณ์ Markdown ที่ใช้ในเนื้อหา Microsoft Learn โปรดดู การอ้างอิง Markdown

นําทางไปยังโฟลเดอร์ที่สอดคล้องกับตําแหน่งที่ตั้ง TOC ที่กําหนดไว้สําหรับบทความของคุณในขั้นตอนที่ 1 โฟลเดอร์ดังกล่าวประกอบด้วยไฟล์ Markdown สำหรับบทความทั้งหมดในส่วนนั้น หากจำเป็น ให้สร้างโฟลเดอร์ใหม่เพื่อวางไฟล์สำหรับเนื้อหาของคุณ บทความหลักสำหรับส่วนนั้นเรียกว่า index.md

สำหรับภาพและแหล่งข้อมูลคงที่อื่น ๆ ให้สร้างโฟลเดอร์ย่อยที่เรียกว่า สื่อ ภายในโฟลเดอร์ที่มีบทความของคุณหากยังไม่มีอยู่ ภายในโฟลเดอร์ สื่อ สร้างโฟลเดอร์ย่อยด้วยชื่อบทความ (ยกเว้นไฟล์ดัชนี) สําหรับข้อมูลเพิ่มเติมเกี่ยวกับตําแหน่งที่จะวางไฟล์ของคุณ ให้ดู โครงสร้างโฟลเดอร์ ตัวอย่างส่วน

อย่ารวมโค้ดแบบอินไลน์ในบทความ เว้นแต่ว่าคุณกําลังแสดงโครงสร้างที่ไม่มีการคอมไพล์ แต่ให้ใช้ โครงการส่วนย่อย ของโค้ดและรวมโค้ดโดยใช้ส่วนขยายโค้ด เพื่อให้แน่ใจว่ารหัสตัวอย่างของคุณได้รับการตรวจสอบโดยระบบ CI ของเรา

สำหรับ ส่วนย่อยของโค้ด ให้สร้างโฟลเดอร์ย่อยที่เรียกว่า ส่วนย่อย ภายในโฟลเดอร์ที่มีบทความของคุณหากยังไม่มีอยู่ ภายในโฟลเดอร์ส่วนย่อย ให้สร้างโฟลเดอร์ย่อยที่มีชื่อบทความ ในกรณีส่วนใหญ่ คุณจะมีส่วนย่อยของโค้ดสำหรับทั้งสามภาษาหลักได้แก่ .NET, C#, F#, และ Visual Basic ในกรณีนี้ ให้สร้างโฟลเดอร์ย่อยที่ชื่อว่า csharp, fsharp และ vb สำหรับแต่ละโครงการจากสามโครงการ ถ้าคุณกำลังสร้างส่วนย่อยสำหรับบทความภายใต้โฟลเดอร์ docs/csharp, docs/fsharp หรือ docs/visual-basic ส่วนย่อยจะอยู่ในภาษาเดียวเท่านั้นเพื่อให้คุณสามารถละเว้นโฟลเดอร์ย่อยของภาษาได้ สําหรับข้อมูลเพิ่มเติมเกี่ยวกับตําแหน่งที่จะวางไฟล์ของคุณ ให้ดู โครงสร้างโฟลเดอร์ ตัวอย่างส่วน

ส่วนย่อยของโค้ดคือตัวอย่างที่มีขนาดเล็กและโฟกัสของโค้ดที่แสดงให้เห็นแนวคิดที่ครอบคลุมในบทความ โปรแกรมที่มีขนาดใหญ่กว่า ที่มีไว้สำหรับการดาวน์โหลดและการสำรวจควรอยู่ในที่เก็บ dotnet/samples ตัวอย่างแบบเต็มมีครอบคลุมอยู่ในส่วน ที่สนับสนุนตัวอย่าง

ขั้นตอนที่ 4: ส่งคําขอดึงข้อมูล (PR) จากสาขาของคุณไปยังสาขาเริ่มต้น

สำคัญ

ฟังก์ชันการทำงานอัตโนมัติของความคิดเห็นไม่พร้อมใช้งานในที่เก็บข้อมูลเอกสาร.NET ในขณะนี้ สมาชิกของทีมเอกสาร .NET จะทบทวนและรวม PR ของคุณ

PR แต่ละรายการควรแก้ไขปัญหาหนึ่งปัญหาในแต่ละครั้ง เว้นแต่ว่าปัญหาหลายปัญหาจะเกี่ยวข้องกับการแก้ไข PR เดียวกัน PR สามารถแก้ไขไฟล์เดียวหรือหลายไฟล์ได้ หากคุณกำลังแก้ไขปัญหาหลายปัญหาบนไฟล์ที่แตกต่างกัน PR จะต้องแยกจากกัน

หาก PR ของคุณแก้ไขประเด็นที่มีอยู่ ให้เพิ่ม Fixes #Issue_Number คําสําคัญลงในคําอธิบาย PR ด้วยวิธีนี้ประเด็นจะถูกปิดโดยอัตโนมัติเมื่อ PR ถูกรวมเข้าด้วยกัน สําหรับข้อมูลเพิ่มเติม โปรดดูการเชื่อมโยงคําขอดึงข้อมูลกับปัญหาโดยใช้คําสําคัญ

ทีม .NET จะตรวจสอบ PR ของคุณและแจ้งให้คุณทราบหากมีการอัปเดต/เปลี่ยนแปลงอื่น ๆ ที่จำเป็นเพื่อที่ขอการอนุมัติ

ขั้นที่ 5: ทำการปรับปรุงที่จำเป็นต่อสาขาของคุณตามที่ได้หารือกับทีมงาน

ผู้ดูแลจะผสานรวม PR ของคุณเข้ากับสาขาเริ่มต้นเมื่อมีการใช้คําติชมและการเปลี่ยนแปลงของคุณได้รับการอนุมัติ

เราผลักความมุ่งมั่นทั้งหมดจากสาขาเริ่มต้นไปยังสาขาปัจจุบัน แล้วคุณจะสามารถดูการสนับสนุนของคุณที่ ปรากฏในเอกสาร .NET โดยปกติเราเผยแพร่ทุกวันในช่วงสัปดาห์ทำงาน

โครงสร้างโฟลเดอร์ตัวอย่าง

docs
  /about
  /core
    /porting
      porting-overview.md
      /media
        /porting-overview
          portability_report.png
        /shared ...
      /snippets
        /porting-overview
          /csharp
            porting.csproj
            porting-overview.cs
            Program.cs
          /fsharp
            porting.fsproj
            porting-overview.fs
            Program.fs
          /vb
            porting.vbproj
            porting-overview.vb
            Program.vb
        /shared
          /csharp ...
          /fsharp ...
          /vb ...

หมายเหตุ

ไม่จำเป็นต้องใช้โฟลเดอร์ภาษาภายใต้ส่วนย่อยข้อมูลในพื้นที่คู่มือภาษา ซึ่งจะถือว่ามีเพียงภาษาเดียวที่ใช้ ตัวอย่างเช่น ในคู่มือแนะนํา C# จะสันนิษฐานว่าส่วนย่อยทั้งหมดเป็น C#

โครงสร้างที่แสดงข้างต้นประกอบด้วยรูปภาพหนึ่ง portability_report png และโครงสร้างโค้ดสามชนิดที่ประกอบด้วย ส่วนย่อยของโค้ด ที่รวมอยู่ในบทความ porting-overview.md

โฟลเดอร์ ส่วนย่อย/ที่ใช้ร่วมกัน ใช้สําหรับส่วนย่อยที่อาจครอบคลุมหลายบทความภายในโฟลเดอร์หลักเดียวกัน เช่น โฟลเดอร์พอร์ต ในตัวอย่างก่อนหน้า ใช้โฟลเดอร์ที่ แชร์ เมื่อคุณมีเหตุผลที่เฉพาะเจาะจงเท่านั้นเช่นรหัส XAML ที่อ้างอิงโดยหลายบทความ แต่ไม่สามารถคอมไพล์ใน โฟลเดอร์เฉพาะ บทความได้

นอกจากนี้คุณยังสามารถแชร์สื่อในบทความต่างๆ เมื่อบทความเหล่านั้นอยู่ในโฟลเดอร์หลักเดียวกัน เช่น โฟลเดอร์พอร์ต ในตัวอย่างก่อนหน้า โฟลเดอร์ที่แชร์นี้ควรหลีกเลี่ยงถ้าเป็นไปได้ และใช้เฉพาะเมื่อเหมาะสม ตัวอย่างเช่น อาจเหมาะสมที่จะแชร์หน้าจอการโหลดทั่วไปสําหรับแอปที่กําลังสาธิต หรือแชร์กล่องโต้ตอบ Visual Studio ที่ใช้ซ้ําในหลายบทความ

สำคัญ

สำหรับเหตุผลทางประวัติศาสตร์ จำนวนมากของส่วนย่อยที่รวมอยู่จะถูกจัดเก็บไว้ภายใต้โฟลเดอร์ /samples ในที่เก็บ dotnet/docs ถ้าคุณกำลังทำการเปลี่ยนแปลงที่สำคัญกับบทความ ส่วนย่อยเหล่านั้นควรถูกย้ายไปยังโครงสร้างใหม่ อย่างไรก็ตาม ไม่ต้องกังวลเกี่ยวกับการย้ายส่วนย่อยสําหรับการเปลี่ยนแปลงเล็กน้อย

ส่งไปยังตัวอย่าง

เราสร้างความแตกต่างต่อไปนี้สำหรับโค้ดที่รองรับเนื้อหาของเรา:

• ตัวอย่าง: ผู้อ่านสามารถดาวน์โหลดและเรียกใช้ตัวอย่างได้ ตัวอย่างทั้งหมดควรเป็นแอปพลิเคชันหรือไลบรารีที่สมบูรณ์ ในกรณีที่ตัวอย่างสร้างไลบรารี ซึ่งควรประกอบรวมด้วยการทดสอบหน่วยหรือแอปพลิเคชันที่ทำให้ผู้อ่านสามารถเรียกใช้โค้ดได้ พวกเขามักใช้เทคโนโลยี คุณลักษณะ หรือชุดเครื่องมือมากกว่าหนึ่งชิ้น ไฟล์ readme.md สำหรับแต่ละตัวอย่างจะอ้างถึงบทความเพื่อให้คุณสามารถอ่านเพิ่มเติมเกี่ยวกับแนวคิดที่ครอบคลุมในแต่ละตัวอย่าง
• ส่วนย่อย: แสดงตัวอย่างแนวคิดหรืองานที่ขนาดเล็กกว่า พวกเขาคอมไพล์แต่ไม่ได้ตั้งใจให้เป็นแอปพลิเคชันที่สมบูรณ์ แอปดังกล่าวควรทำงานได้อย่างถูกต้อง แต่ไม่ใช่แอปพลิเคชันตัวอย่างสำหรับสถานการณ์ทั่วไป แต่แอปดังกล่าวถูกออกแบบให้มีขนาดเล็กที่สุดเพื่อแสดงตัวอย่างแนวคิดหรือคุณลักษณะเดียว ซึ่งแอปเหล่านี้ควรมีโค้ดไม่เกินหน้าจอเดียว

ตัวอย่างถูกเก็บไว้ในที่เก็บ dotnet/samples เรากำลังดำเนินการไปสู่รูปแบบที่โครงสร้างโฟลเดอร์ตัวอย่างของเราตรงกับโครงสร้างโฟลเดอร์ docs ของเรา มาตรฐานที่เราปฏิบัติตาม ได้แก่:

• โฟลเดอร์ระดับบนสุดจะตรงกับโฟลเดอร์ระดับบนสุดในที่เก็บเอกสาร ตัวอย่างเช่น ที่เก็บเอกสารมีโฟลเดอร์ machine-learning/tutorials และตัวอย่างสำหรับบทช่วยสอนของคอมพิวเตอร์อยู่ในโฟลเดอร์ samples/machine-learning/tutorials

นอกจากนี้ ตัวอย่างทั้งหมดภายในโฟลเดอร์ หลัก และ มาตรฐาน ควรบิลด์และทำงานบนแพลตฟอร์มทั้งหมดที่ได้รับการสนับสนุนโดย .NET Core ระบบบิลด์ CI ของเราจะบังคับใช้ดังกล่าว โฟลเดอร์ เฟรมเวิร์ก ระดับบนสุดประกอบด้วยตัวอย่างที่ถูกสร้างและตรวจสอบบน Windows เท่านั้น

โครงการตัวอย่างควรสร้างและเรียกใช้ชุดแพลตฟอร์มที่กว้างที่สุดสำหรับตัวอย่างที่กำหนด ในทางปฏิบัติ นั่นหมายถึงการสร้างแอปพลิเคชันคอนโซลแอ็ตทริบิวต์ .NET Core ถ้าเป็นไปได้ ตัวอย่างที่เจาะจงเว็บหรือเฟรมเวิร์ก UI ควรเพิ่มเครื่องมือเหล่านี้ตามต้องการ ตัวอย่างประกอบรวมด้วยแอปพลิเคชันเว็บ แอปพลิเคชันบนมือถือ แอป WPF หรือ WinForms และอื่น ๆ

เรากำลังดำเนินการเพื่อให้มีระบบ CI สำหรับโค้ดทั้งหมด เมื่อคุณทำการปรับปรุงตัวอย่าง ให้ตรวจสอบว่าการอัปเดตแต่ละครั้งเป็นส่วนหนึ่งของโครงการที่สามารถสร้างได้หรือไม่ ในทางอุดมคติ ควรเพิ่มการทดสอบความถูกต้องของตัวอย่างด้วย

ตัวอย่างที่สมบูรณ์ที่คุณสร้างควรประกอบด้วยไฟล์ readme.md ไฟล์นี้ควรประกอบด้วยคำอธิบายของตัวอย่างสั้น ๆ (หนึ่งหรือสองย่อหน้า) ไฟล์ readme.md ของคุณควรบอกผู้อ่านว่าพวกเขาจะเรียนรู้อะไรบ้างโดยการสำรวจตัวอย่างนี้ ไฟล์ readme.md ยังควรมีลิงก์ไปยังเอกสารปัจจุบันในไซต์เอกสาร .NET อีกด้วย เมื่อต้องการกำหนดว่าไฟล์ใดที่อยู่ในที่เก็บข้อมูลจะแมปไซต์นั้น ให้แทนที่ /docs ในเส้นทางที่เก็บด้วย https://learn.microsoft.com/dotnet

หัวข้อของคุณจะมีลิงก์ไปยังตัวอย่างด้วย เชื่อมโยงโดยตรงไปยังโฟลเดอร์ตัวอย่างของ GitHub

เขียนตัวอย่างใหม่

ตัวอย่างคือโปรแกรมและไลบรารีเต็มรูปแบบสำหรับการดาวน์โหลด พวกเขาอาจมีขนาดเล็กในขอบเขต แต่พวกเขาสาธิตแนวคิดในลักษณะที่ช่วยให้คนสามารถสำรวจและทดลองใช้งานของตนเองได้ คำแนะนำสำหรับตัวอย่างเพื่อให้แน่ใจว่าผู้อ่านสามารถดาวน์โหลดและสำรวจได้ ตรวจสอบตัวอย่าง Parallel LINQ (PLINQ) เป็นตัวอย่างของแต่ละคำแนะนำ

1. ตัวอย่างของคุณต้องเป็นส่วนหนึ่งของโครงการที่สามารถสร้างได้ ถ้าเป็นไปได้ โครงการควรสร้างบนแพลตฟอร์มทั้งหมดที่ได้รับการสนับสนุนโดย .NET Core ข้อยกเว้นคือตัวอย่างที่แสดงคุณลักษณะเฉพาะของแพลตฟอร์มหรือเครื่องมือเฉพาะของแพลตฟอร์ม

2. ตัวอย่างของ คุณควรสอดคล้องกับสไตล์ การเข้ารหัสรันไทม์เพื่อรักษาความสอดคล้อง

   นอกจากนี้ เรายังต้องการใช้เมธอด static มากกว่าเมธอดอินสแตนซ์เมื่อแสดงสิ่งที่ไม่ต้องการทำให้ออบเจ็กต์ใหม่เป็นอินสแตนซ์

3. ตัวอย่างของคุณควรประกอบด้วย การจัดการข้อยกเว้นอย่างเหมาะสม ซึ่งควรจัดการกับข้อยกเว้นทั้งหมดที่อาจถูกมองข้ามไปในบริบทของกลุ่มตัวอย่าง ตัวอย่างเช่น ตัวอย่างที่เรียกเมธอด Console.ReadLine เพื่อดึงข้อมูลอินพุตของผู้ใช้ควรใช้การจัดการข้อยกเว้นที่เหมาะสมเมื่อมีการส่งผ่านสตริงอินพุตเป็นอาร์กิวเมนต์ไปยังเมธอด ในทำนองเดียวกัน ถ้าตัวอย่างของคุณคาดว่าจะติดต่อเมธอดไม่สำเร็จ ข้อยกเว้นที่เกิดขึ้นจะต้องได้รับการจัดการ จัดการกับข้อยกเว้นเฉพาะที่ถูกมองข้ามโดยเมธอดเสมอ แทนที่ข้อยกเว้นระดับฐาน เช่น Exception หรือ SystemException

วิธีการสร้างตัวอย่าง:

1. ใส่ ประเด็น หรือเพิ่มความคิดเห็นลงในไฟล์ที่มีอยู่ซึ่งคุณกำลังใช้งานอยู่

2. เขียนหัวข้อที่อธิบายแนวคิดที่แสดงในตัวอย่างของคุณ (ตัวอย่าง: docs/standard/linq/where-clause.md)

3. เขียนตัวอย่างของคุณ (ตัวอย่าง: WhereClause-Sample1.cs)

4. สร้าง Program.cs โดยมีจุดเข้าใช้งานหลักที่เรียกใช้งานตัวอย่างของคุณ หากมีอยู่แล้วหนึ่ง ให้เพิ่มการเรียกไปยังตัวอย่างของคุณ:

   public class Program
   {
       public void Main(string[] args)
       {
           WhereClause1.QuerySyntaxExample();
   
           // Add the method syntax as an example.
           WhereClause1.MethodSyntaxExample();
       }
   }
   

คุณสร้างส่วนย่อยหรือตัวอย่าง .NET โดยใช้ .NET CLI ซึ่งสามารถติดตั้งได้ด้วย .NET SDK วิธีการบิลด์และเรียกใช้ตัวอย่างของคุณ:

1. ไปที่โฟลเดอร์ตัวอย่างและบิลด์เพื่อตรวจสอบข้อผิดพลาด:

   dotnet build
   

2. เรียกใช้ตัวอย่างของคุณ:

   dotnet run
   

3. เพิ่ม readme.md ลงในไดเรกทอรีรากของตัวอย่างของคุณ

   ซึ่งควรมีคำอธิบายสั้น ๆ เกี่ยวกับโค้ด และแนะนำบุคคลในบทความที่อ้างอิงตัวอย่าง ด้านบนสุดของ readme.md ต้องมีเมตาดาต้าที่จำเป็นสำหรับเบราว์เซอร์ตัวอย่าง บล็อกส่วนหัวควรประกอบด้วยเขตข้อมูลต่อไปนี้:

   ---
   name: "really cool sample"
   description: "Learn everything about this really cool sample."
   page_type: sample
   languages:
     - csharp
     - fsharp
     - vbnet
   products:
     - dotnet-core
     - dotnet
     - dotnet-standard
     - aspnet
     - aspnet-core
     - ef-core
   ---
   

   • คอลเลกชัน languages ควรมีเฉพาะภาษาเหล่านั้นที่พร้อมใช้งานสำหรับตัวอย่างของคุณ
   • คอลเลกชัน products ควรมีเฉพาะผลิตภัณฑ์เหล่านั้นที่เกี่ยวข้องกับตัวอย่างของคุณเท่านั้น

ยกเว้นที่ระบุไว้ ตัวอย่างทั้งหมดที่บิลด์ขึ้นจากบรรทัดคําสั่งบนแพลตฟอร์มที่ได้รับการสนับสนุนโดย .NET มีตัวอย่างบางส่วนที่เฉพาะเจาะจงสำหรับ Visual Studio และต้องใช้ Visual Studio 2017 หรือใหม่กว่า นอกจากนี้ ตัวอย่างบางส่วนยังแสดงถึงคุณลักษณะเฉพาะของแพลตฟอร์มและจะต้องมีแพลตฟอร์มที่เฉพาะเจาะจง ส่วนย่อยและตัวอย่างอื่นต้องมี .NET Framework และจะทำงานบนแพลตฟอร์ม Windows และจะต้องมชุดนักพัฒนาซอฟต์แวร์สำหรับเฟรมเวิร์กรุ่นเป้าหมาย

ประสบการณ์เชิงโต้ตอบของ C#

ส่วนย่อยทั้งหมดที่รวมอยู่ในบทความใช้ แท็ก ภาษาเพื่อระบุภาษาต้นฉบับ ส่วนย่อยของ csharp-interactive โค้ดแบบสั้นใน C# สามารถใช้แท็กภาษาเพื่อระบุส่วนย่อย C# ที่ทํางานในเบราว์เซอร์ได้ (ส่วนย่อยของ csharp-interactive โค้ดแบบอินไลน์ใช้แท็ก สําหรับส่วนย่อยที่มาจากต้นทาง ให้ใช้ code-csharp-interactive แท็ก) ส่วนย่อยของโค้ดเหล่านี้จะแสดง หน้าต่าง โค้ดและ หน้าต่าง เอาต์พุตในบทความ หน้าต่างเอาต์พุตจะแสดงผลลัพธ์จากการดําเนินการโค้ดเชิงโต้ตอบเมื่อผู้ใช้เรียกใช้ส่วนย่อย

ประสบการณ์เชิงโต้ตอบของ C# จะเปลี่ยนวิธีที่เราทํางานกับส่วนย่อย ผู้เข้าชมสามารถเรียกใช้ส่วนย่อยเพื่อดูผลลัพธ์ได้ มีหลายปัจจัยที่ช่วยในการตรวจสอบว่าส่วนย่อยหรือข้อความที่เกี่ยวข้องควรรวมข้อมูลเกี่ยวกับเอาต์พุตหรือไม่

เมื่อต้องการแสดงเอาต์พุตที่คาดหวังโดยไม่มีการเรียกใช้ส่วนย่อย

• บทความสำหรับผู้เริ่มต้นควรมีเอาต์พุตเพื่อให้ผู้อ่านสามารถเปรียบเทียบเอาต์พุตของตนกับคำตอบที่คาดหวังได้
• ส่วนย่อยที่เอาต์พุตเป็นส่วนสําคัญของหัวข้อควรแสดงเอาต์พุตนั้น ตัวอย่างเช่น บทความในข้อความที่จัดรูปแบบควรแสดงรูปแบบข้อความโดยไม่เรียกใช้ส่วนย่อย
• เมื่อทั้งส่วนย่อยและเอาต์พุตที่คาดหวังสั้น ให้พิจารณาการแสดงเอาต์พุต ซึ่งจะช่วยประหยัดเวลาสักหน่อย
• บทความที่อธิบายถึงวิธีการที่วัฒนธรรมปัจจุบันหรือวัฒนธรรมคงที่ส่งผลต่อเอาต์พุตควรอธิบายถึงเอาต์พุตที่คาดหวังด้วย REPL (Read Evaluate Print Loop) เชิงโต้ตอบจะรันบนโฮสต์ที่ใช้ Linux วัฒนธรรมที่เป็นค่าเริ่มต้นและวัฒนธรรมคงที่ทำให้เกิดเอาต์พุตที่แตกต่างกันในระบบปฏิบัติการและเครื่องที่แตกต่างกัน บทความนี้ควรอธิบายถึงเอาต์พุตในระบบ Windows, Linux และ Mac

เมื่อไม่รวมเอาต์พุตที่คาดหวังจากส่วนย่อย

• บทความที่ส่วนย่อยสร้างเอาต์พุตขนาดใหญ่กว่าไม่ควรรวมอยู่ในความคิดเห็น ซึ่งจะบดบังโค้ดเมื่อมีการเรียกใช้ส่วนย่อย
• บทความที่ส่วนย่อยแสดงหัวข้อ แต่เอาต์พุตไม่ได้เป็นส่วนสําคัญในการทําความเข้าใจ ตัวอย่างเช่น โค้ดที่เรียกใช้คิวรี่ LINQ เพื่ออธิบายไวยากรณ์คิวรี่และแสดงทุกรายการในคอลเล็กชันเอาต์พุต

หมายเหตุ

คุณอาจสังเกตเห็นว่าหัวข้อบางหัวข้อยังไม่ได้ทำตามหลักเกณฑ์ทั้งหมดที่ระบุไว้ในที่นี้ เรากำลังดำเนินการเพื่อให้เกิดความสอดคล้องกันทั่วทั้งไซต์ ตรวจสอบรายการ เปิดประเด็น ซึ่งขณะนี้เรากำลังติดตามเป้าหมายเฉพาะนั้น

การร่วมสร้างเนื้อหาที่ไม่ใช่ภาษาอังกฤษ

ขณะนี้ การร่วมให้เนื้อหาที่แปลโดยใช้เครื่อง (MT) ยังไม่ได้รับการยอมรับ เพื่อปรับปรุงคุณภาพเนื้อหา MT เราจึงได้เปลี่ยนไปใช้กลไก Neural MT เรายอมรับและสนับสนุนการร่วมให้เนื้อหาที่แปลโดยมนุษย์ (HT) ซึ่งใช้สำหรับฝึกกลไก Neural MT ดังนั้น เมื่อเวลาผ่านไป การร่วมให้เนื้อหา HT จะช่วยปรับปรุงคุณภาพของทั้ง HT และ MT หัวข้อเกี่ยวกับ MT จะมีข้อความปฏิเสธการรับผิดที่ระบุว่าส่วนดังกล่าวของหัวข้ออาจเป็นเนื้อหาแบบ MT และปุ่ม แก้ไข จะไม่แสดงขึ้น เนื่องจากระบบปิดใช้งานการแก้ไข

หมายเหตุ

เอกสารที่แปลเป็นภาษาท้องถิ่นส่วนใหญ่ไม่มีความสามารถในการแก้ไขหรือให้คําติชมผ่าน GitHub ใช้แบบฟอร์มเพื่อให้คําติชมเกี่ยวกับเนื้อหา https://aka.ms/provide-feedback ที่แปลเป็นภาษาท้องถิ่น

ข้อตกลงการอนุญาตใช้สิทธิผู้ร่วมสร้าง

คุณต้องลงนามใน ข้อตกลงการอนุญาตใช้สิทธิการร่วมสร้าง (CLA) สำหรับ .NET Foundation ก่อนการผสานรวม PR ของคุณ นี่เป็นข้อกำหนดแบบครั้งเดียวสำหรับโครงการใน .NET Foundation คุณสามารถอ่านข้อมูลเพิ่มเติมเกี่ยวกับ ข้อตกลงการอนุญาตใช้สิทธิการร่วมสร้าง (CLA) บน Wikipedia

ข้อตกลง: .NET Foundation Contributor License Agreement (CLA)

คุณไม่ต้องลงนามข้อตกลงล่วงหน้า คุณสามารถโคลน ทำสำเนา และส่ง PR ได้ตามปกติ เมื่อ PR ของคุณถูกสร้างขึ้นจะมีการจัดประเภทโดยบอท CLA หากการเปลี่ยนแปลงมีขนาดเล็ก (เช่น คุณแก้ไขการสะกดผิด) หลังจากนั้น PR จะมีข้อความกำกับว่า cla-not-required มิฉะนั้นจะถูกจัดเป็น cla-required เมื่อคุณลงนามใน CLA คำขอดึงข้อมูลปัจจุบันและคำขอดึงข้อมูลในอนาคตทั้งหมดจะมีข้อความกำกับว่า cla-signed