วิธีการ Bootstrap และสร้าง. NET Projects

สร้าง .NET โปรเจ็กต์

การสร้างโปรเจ็กต์ .NET ตั้งแต่ต้นนั้นทำได้ง่ายๆ โดยใช้วิซาร์ด Visual Studio ไปที่ File => New Project หรือ Add New Project ไปยังโซลูชันที่มีอยู่ เมื่อสร้างโปรเจ็กต์ใหม่แล้ว คุณสามารถเริ่มเขียนโค้ดได้ทันที อย่างไรก็ตาม การตั้งค่าโปรเจ็กต์เริ่มต้นที่สร้างโดยวิซาร์ดนั้นแทบจะไม่เป็นที่ยอมรับสำหรับทีมงานมืออาชีพ เนื่องจากเป็นการตั้งค่าคุณภาพที่ต่ำเกินไป นอกจากนี้ ไม่มีวิซาร์ดใดที่สามารถทราบเกี่ยวกับขั้นตอนการตั้งค่าอื่นๆ ที่คุณต้องดำเนินการในสภาพแวดล้อมการพัฒนาเฉพาะของคุณ

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

โครงสร้าง

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

• การใช้โฟลเดอร์โซลูชันและโครงการ
• การตั้งชื่อที่สอดคล้องกัน

โฟลเดอร์

โฟลเดอร์โซลูชัน ซึ่งบางครั้งเรียกว่า โฟลเดอร์เสมือน เป็นเครื่องมือที่มีประโยชน์มากในการจัดกลุ่มโครงการของคุณ ในมุมมอง Solution Explorer ให้คลิกขวาและเลือก Add => New Solution Folder จากนั้นลากและวางโปรเจ็กต์ที่มีอยู่ไปยังโฟลเดอร์ใหม่นี้ โฟลเดอร์เหล่านี้จะไม่ถูกมิเรอร์ในระบบไฟล์ ช่วยให้คุณรักษาโครงสร้างทางกายภาพที่ไม่เปลี่ยนแปลง ดังนั้นการย้ายโปรเจ็กต์จากโฟลเดอร์โซลูชันหนึ่งไปยังอีกโฟลเดอร์หนึ่งจะไม่ย้ายตามจริง

ไม่จำเป็นต้องมีเลขนำหน้า แต่กำลังทำให้โฟลเดอร์ปรากฏขึ้นตามลำดับในหน้าต่าง Solution Explorer

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

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

การตั้งชื่อ

มีกฎที่แนะนำสองสามข้อที่เกี่ยวข้องกับการตั้งชื่อ:

• ใช้ CamelCase
• ชื่อโปรเจ็กต์ควรตรงกับชื่อแอสเซมบลีของเอาต์พุต
• โปรเจ็กต์ที่มีการทดสอบอัตโนมัติควรมีส่วนต่อท้าย . .Tests
• ชื่อโครงการทั้งหมดควรมีคำนำหน้าร่วมกัน เช่น Company.Product

มีกฎเกณฑ์ที่สมเหตุสมผลบางประการเช่นกัน คุณควรตัดสินใจด้วยตัวเองว่าจะนำไปใช้เมื่อใดตามสามัญสำนึก (และไวยากรณ์ภาษาอังกฤษแน่นอน):

• ใช้หัวเรื่องในรูปแบบพหูพจน์เมื่อคอนเทนเนอร์ (โครงการหรือโฟลเดอร์) มีอินสแตนซ์ประเภทเดียวกันหลายรายการ (เช่น Tests หรือ System.Collections )
• ใช้รูปแบบเอกพจน์เมื่อคอนเทนเนอร์ทั้งหมดมีโค้ดเกี่ยวกับเอนทิตีเดียว (เช่น System.Collections.ObjectModel`)
• สำหรับตัวย่อสั้นๆ ให้ใช้ตัวพิมพ์ใหญ่เหมือนกับที่ System.IO ทำ
• สำหรับตัวย่อแบบยาว ให้ใช้ CamelCase เช่น Modules.Forex. .

หลักการง่ายๆ: ตัวย่อสั้นไม่ควรยาวเกินสามตัวอักษร

การกำหนดค่าโซลูชัน

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

การตั้งค่า ReSharper

หากคุณเป็นนักพัฒนา .NET มืออาชีพ คุณมักจะใช้ ReSharper ReSharper มีความยืดหยุ่นมากในการจัดการการตั้งค่า ในฐานะหัวหน้าทีม คุณสามารถสร้างและแจกจ่ายการตั้งค่า Team Shared ซึ่งจะถูกใช้โดยนักพัฒนารายอื่น การตั้งค่าที่ แชร์ของทีม จะถูกเก็บไว้ในไฟล์ที่มีนามสกุล . .DotSettings ReSharper จะเลือกการตั้งค่าเหล่านี้โดยอัตโนมัติหากชื่อไฟล์ตรงกับชื่อโซลูชัน Visual Studio:

 MyCompany.MyProduct.sln MyCompany.MyProduct.sln.DotSettings

ดังนั้น คุณควรสร้างไฟล์นี้ตั้งแต่เริ่มต้น หากคุณต้องการใช้การตั้งค่าบางอย่างกับทั้งทีมในท้ายที่สุด ตัวอย่างที่ดีคือกฎการใช้ (หรือไม่ใช้) var คีย์เวิร์ด ไฟล์การตั้งค่า ที่แชร์โดยทีม ของคุณสามารถมีกฎได้เพียงข้อเดียว ในขณะที่กฎอื่นๆ เป็นค่ากำหนดของนักพัฒนา เป็นมูลค่าการกล่าวขวัญว่า วิธีเดียวกันกับการตั้งค่า ReSharper ที่สามารถตั้งค่าในระดับต่อโปรเจ็กต์ เนื่องจากคุณอาจมีโค้ดดั้งเดิมที่คุณไม่สามารถแก้ไขได้ (เช่น เปลี่ยนเป็นใช้ var คีย์เวิร์ด)

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

กฎ StyleCop

เช่นเดียวกับการตั้งค่า ReSharper คุณสามารถแชร์การตั้งค่า StyleCop ได้ หากคุณใช้ ReSharper คุณอาจมีการติดตั้งปลั๊กอินการรวมที่จะใช้ประโยชน์จาก StyleCop จาก ReSharper อย่างไรก็ตาม StyleCop จะเก็บการตั้งค่าไว้อย่างอิสระในไฟล์ชื่อ Settings.StyleCop ในทำนองเดียวกัน คุณสามารถมีไฟล์นี้พร้อมกับไฟล์โซลูชันและไฟล์โครงการ

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

ไฟล์ข้อความ

หากคุณกำลังสร้างผลิตภัณฑ์สาธารณะและกำลังจะเผยแพร่ซอร์สโค้ด อย่าลืมสร้างและคอมมิตไฟล์เหล่านี้ด้วย:

 README.md LICENSE

ฉันแนะนำให้ใช้รูปแบบ markdown สำหรับไฟล์ README.md เนื่องจากมันกลายเป็นมาตรฐานอุตสาหกรรมและรองรับโดยบริการควบคุมแหล่งข้อมูลสาธารณะ เช่น GitHub รวมถึงเซิร์ฟเวอร์ภายในองค์กร เช่น BitBucket (ชื่อเดิม Stash)

ข้อมูลจำเพาะของ NuGet

หากคุณกำลังสร้างไลบรารี่ที่จะเผยแพร่บน NuGet Gallery คุณอาจจำเป็นต้องสร้างไฟล์ข้อมูลจำเพาะของแพ็คเกจ เช่น MyProject.nuspec ฉันชอบสร้างไฟล์เหล่านี้ด้วยตนเองและส่งไปยังตัวควบคุมต้นทาง โดยปกติแล้ว แพ็คเกจจะถูกปล่อยออกมาจากงาน Continuous Integration (CI for short) ของคุณ แต่คุณยังสามารถสร้างและเผยแพร่แพ็คเกจด้วยตนเองได้ทุกเมื่อจากคอนโซลดังนี้:

 nuget.exe pack MyLibrary.nuspec

อย่าลืมเพิ่มเวอร์ชันของแพ็คเกจก่อนดำเนินการคำสั่งนี้

ไฟล์เฉพาะ CI

เราทุกคนใช้เซิร์ฟเวอร์ CI ต่างกัน และพวกเขาทั้งหมดมีสคริปต์การกำหนดค่าและการตั้งค่าที่แตกต่างกัน ฉันจะพูดถึงส่วนเพิ่มเติมทั่วไปบางส่วนที่คุณอาจพิจารณาเพิ่ม:

• การตั้งค่า NUnit ซึ่งระบุว่าแอสเซมบลีใดมีการทดสอบที่จะดำเนินการบนเซิร์ฟเวอร์ CI สำหรับงานเฉพาะ การทดสอบทั้งหมดถูกแบ่งออกเป็นสองสามหมวดหมู่ มี การทดสอบหน่วย ที่ควรรันในทุกบิลด์ การทดสอบประสิทธิภาพ ที่ดำเนินการทุกคืน และ การทดสอบการรวม จะดำเนินการตามแต่ละรุ่น
• การตั้งค่า NCover ซึ่งระบุชุดทดสอบที่ควรวิเคราะห์เพื่อให้ครอบคลุมการทดสอบ
• การตั้งค่า SonarQube ซึ่งกำหนดตัวชี้วัดซอฟต์แวร์จะถูกรวบรวม
• สคริปต์งาน เช่น NAnt, PowerShell หรือไฟล์แบตช์ของ Windows

การกำหนดค่าโครงการ

ไฟล์โครงการ ได้แก่ .csproj หรือ . .vbpro มีการตั้งค่าทั้งหมดที่ใช้โดย Visual Studio และ MSBuild อย่างไรก็ตาม มีไม่ทั้งหมดจากหน้าต่างคุณสมบัติโปรเจ็กต์ ในการแก้ไขไฟล์เหล่านี้ใน Visual Studio ด้วยตนเอง คุณควรทำดังต่อไปนี้:

• คลิกขวาที่โปรเจ็กต์ในมุมมอง Solution Explorer
• เลือก ยกเลิกการโหลดโปรเจ็ กต์
• คลิกขวาอีกครั้งเพื่อเลือกการดำเนินการ Edit xyz.csproj
• แก้ไขให้สมบูรณ์
• คลิกขวาที่โปรเจ็กต์อีกครั้ง และเลือก รี โหลดโปรเจ็ กต์

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

คำเตือน การควบคุม

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

 <WarningLevel>4</WarningLevel> <TreatWarningsAsErrors>true</TreatWarningsAsErrors>

และตรวจสอบให้แน่ใจว่าคุณไม่มีการตั้งค่าเดียวกันในกลุ่มคุณสมบัติอื่นๆ มิฉะนั้น จะแทนที่คุณสมบัติที่เกี่ยวข้องจากกลุ่มทั่วไป

FxCop

การรัน FxCop นั้นทำได้จริงในทุกบิลด์ ทีมส่วนใหญ่ต้องการเรียกใช้ FxCop เป็นครั้งคราว (โดยปกติก่อนการเปิดตัว) เพื่อให้แน่ใจว่าไม่มีข้อผิดพลาดร้ายแรงเกิดขึ้น อย่างไรก็ตาม หากคุณต้องการตรวจสอบขั้นสุดท้ายในทุกบิลด์ ให้เพิ่มตัวเลือกนี้:

 <RunCodeAnalysis>true</RunCodeAnalysis>

โปรดทราบว่า FxCop เช่น StyleCop มีการตั้งค่าของตัวเองซึ่งสามารถวางไว้ในโฟลเดอร์รากและเพิ่มไปยังตัวควบคุมแหล่งที่มาได้ การตั้งค่าเหล่านี้มักใช้เมื่อเรียกใช้ FxCop บนเซิร์ฟเวอร์ CI

เอกสาร

ส่วนนี้เกี่ยวกับ XmlDoc หากคุณกำลังสร้าง API สาธารณะ คุณควรสร้างและดูแลรักษาเอกสาร API นักพัฒนาส่วนใหญ่เริ่มต้นด้วยการพัฒนา API (การเข้ารหัสจริง) และก่อนการเปิดตัว พวกเขาจะเปิดใช้งานการตั้งค่าโครงการ Build / XML documentation file โดยปกติ หลังจากสร้างใหม่อีกครั้ง ข้อผิดพลาดจำนวนมากจะปรากฏขึ้น เนื่องจาก XmlDoc ที่หายไปทุกอันจะทำให้เกิดข้อผิดพลาดในการสร้าง เพื่อหลีกเลี่ยงปัญหานี้ คุณควรเปิดใช้งานตัวเลือกดังกล่าวในตอนเริ่มต้น

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

รหัสสัญญา

Code Contracts เป็นเฟรมเวิร์กที่ยอดเยี่ยมจาก Microsoft Research ซึ่งช่วยให้คุณแสดงเงื่อนไขเบื้องต้น เงื่อนไขภายหลัง และค่าคงที่อ็อบเจ็กต์ในโค้ดของคุณสำหรับการตรวจสอบรันไทม์ การวิเคราะห์แบบสถิต และเอกสารประกอบ ฉันใช้สิ่งนี้ในโครงการสำคัญๆ มากมาย และมันช่วยได้มาก ฉันขอแนะนำให้คุณลองดู

หากคุณตัดสินใจที่จะใช้ Code Contracts สิ่งสำคัญคือต้องเปิดใช้งานสัญญาตั้งแต่เริ่มต้น เมื่อคุณเพิ่งสร้างโครงการใหม่ การเพิ่มสัญญาในช่วงกลางของการพัฒนาเป็นไปได้ แต่จะต้องมีการเปลี่ยนแปลงในหลายคลาสเพื่อให้ผู้ติดต่อจับคู่กัน ดังนั้น อย่าลืมเปิดใช้งานการตั้งค่าที่จำเป็นทั้งหมด (อย่างน้อย CodeContractsEnableRuntimeChecking ) และตรวจสอบให้แน่ใจว่าการตั้งค่าเหล่านี้ปรากฏในกลุ่มคุณสมบัติทั่วไป

การบังคับใช้ StyleCop

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

โดยปกติจะทำโดยการปรับเปลี่ยนไฟล์โครงการด้วยตนเอง คุณต้องยกเลิกการโหลดโครงการใน Visual Studio แก้ไขไฟล์โครงการแล้วโหลดโครงการกลับ:

 <PropertyGroup> <!— add this to the common property group (common to Debug/Release/etc) —> <StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings> </PropertyGroup> <!— add this Import in the very bottom —> <Import Project="$(ProgramFiles)\MSBuild\Microsoft\StyleCop\v4.3\Microsoft.StyleCop.targets">

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

คุณอาจสังเกตเห็นเส้นทางไปยัง Program Files เนื่องจากนักพัฒนาซอฟต์แวร์อาจติดตั้ง StyleCop เวอร์ชันต่างๆ กัน บางทีมจึงต้องการเก็บสำเนาส่วนตัวของการติดตั้ง StyleCop เดียวกันไว้ภายใต้การควบคุมแหล่งที่มา ในกรณีนี้ เส้นทางจะสัมพันธ์กัน นอกจากนี้ยังทำให้การตั้งค่าเครื่อง CI ง่ายขึ้น เนื่องจากคุณไม่จำเป็นต้องติดตั้ง StyleCop ในเครื่อง

AssemblyInfo

ทุกโปรเจ็กต์ .NET ที่สร้างโดยวิซาร์ด Visual Studio จะมีไฟล์ AssemblyInfo.cs ที่เติมโดยอัตโนมัติ (ดูโฟลเดอร์ย่อย Properties ) ซึ่งประกอบด้วยแอททริบิวต์ Assembly บางส่วน แต่ไม่มีวิซาร์ดใดที่สามารถเติมแอ็ตทริบิวต์ Assembly ทั้งหมดให้คุณได้ ตรวจสอบให้แน่ใจว่าคุณมีแอตทริบิวต์เหล่านี้อย่างน้อย:

• AssemblyTitle
• AssemblyDescription
• AssemblyCompany
• AssemblyProduct
• AssemblyCopyright
• AssemblyVersion

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

คุณยังสามารถเติมพร็อพเพอร์ตี้อีกหนึ่งรายการในตอนเริ่มต้น:

 InternalsVisibleTo

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

สายเชื่อมต่อ

วิธีจัดการสตริงการเชื่อมต่อเป็นคำถามยอดนิยมใน Stack Overflow ปัญหาคือวิธีทำให้สตริงการเชื่อมต่อไม่ซ้ำกันสำหรับนักพัฒนาหรืองาน CI ทุกราย และไม่เปิดเผยรายละเอียดการเชื่อมต่อขณะเผยแพร่ซอร์สโค้ด

ใน App.config (สำหรับแอปพลิเคชันเดสก์ท็อป) หรือ Web.config (สำหรับเว็บแอปพลิเคชัน) ให้ตั้งค่าต่อไปนี้ซึ่งจะโหลดไฟล์ user.config ในรันไทม์ เก็บไว้ภายใต้การควบคุมแหล่งที่มาของคุณ:

 <?xml version="1.0" encoding="utf-8" ?> <configuration> <connectionStrings configSource="user.config"></connectionStrings> </configuration>

เห็นได้ชัดว่าไฟล์ user.config ควรแยกออกจากการควบคุมแหล่งที่มา และนักพัฒนาทุกคนควรมีสำเนาของไฟล์นี้ในเครื่อง เพื่อรักษาความเป็นส่วนตัวของสตริงการเชื่อมต่อ:

 <connectionStrings> <add name="test" connectionString="Server=.;Database=...;"/> </connectionStrings>

.gitignore

สำหรับผู้ที่ใช้ Git เป็นตัวควบคุมต้นทาง จำเป็นต้องเพิ่มรูปแบบไฟล์บางรูปแบบลงในไฟล์ .gitignore อย่างไรก็ตาม ชุมชนอัจฉริยะของเราได้สร้างไฟล์ทั่วไปแล้ว ซึ่งสามารถพบได้ที่นี่: github.com/github/gitignore/blob/master/VisualStudio.gitignore

คุณควรใช้เป็นไฟล์อ้างอิง .gitignore และเพียงเพิ่มการยกเว้นที่กำหนดเองซึ่งคุณอาจต้องใช้เพิ่มเติม

ป้าย GitHub

คุณอาจเคยเห็นป้ายที่ดูดีปรากฏบนหน้าโครงการ README หากคุณกำลังเผยแพร่โครงการของคุณบน GitHub ให้พิจารณาเชื่อมต่อโครงการของคุณกับบริการสาธารณะสำหรับ:

• อาคาร: เพื่อแสดงว่าบิลด์ล้มเหลวหรือผ่าน
• การทดสอบ: เพื่อแสดงขอบเขตการทดสอบและสถานะการดำเนินการทดสอบ
• การเผยแพร่: เพื่อแสดงแพ็คเกจ NuGet เวอร์ชันล่าสุด

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

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

ตัวอย่างป้ายลดราคา จากโครงการ Roslyn:

[![Build Status]([http://dotnet-ci.cloudapp.net/job/roslyn_master_win_dbg_unit32/badge/icon)](http://dotnet-ci.cloudapp.net/job/roslyn_master_win_dbg_unit32/)](http://dotnet-ci.cloudapp.net/job/roslyn_master_win_dbg_unit32/badge/icon)](http://dotnet-ci.cloudapp.net/job/roslyn_master_win_dbg_unit32/)) [![Join the chat at [https://gitter.im/dotnet/roslyn](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/dotnet/roslyn?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)](https://gitter.im/dotnet/roslyn](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/dotnet/roslyn?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge))

การตรวจสอบโครงสร้างโซลูชันอัตโนมัติ

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

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

ฉันพบว่าการดูข้อผิดพลาดเหล่านี้ใน Code Reviews มักเกิดข้อผิดพลาดและควรดำเนินการโดยอัตโนมัติ ดังนั้นฉันจึงเขียนเครื่องมือง่ายๆ ที่ดำเนินการเหล่านี้และการตรวจสอบอื่นๆ อีกมากมายเพื่อตรวจสอบความสอดคล้องของโซลูชัน พบกับ SolutionInspector นี่คือโอเพ่นซอร์สและเผยแพร่ภายใต้ใบอนุญาต MIT คุณสามารถสร้างจากซอร์สโค้ดหรือติดตั้งจาก NuGet:

 Install-Package SolutionInspector

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

ไม่จำเป็นต้องใช้ไฟล์การกำหนดค่าตามค่าเริ่มต้น ในกรณีนี้ เครื่องมือจะใช้กฎที่มีอยู่ทั้งหมดและให้ปัญหาทั้งหมดกับคอนโซล

นี่คือตัวอย่างไฟล์การกำหนดค่า:

 <?xml version="1.0" encoding="utf-8"?> <Settings xmlns:xsi="[http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">](http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">) <SolutionSettings> <MinSolutionFormatVersion>12.00</MinSolutionFormatVersion> <MaxSolutionFormatVersion>12.00</MaxSolutionFormatVersion> <DetectMissingFiles>true</DetectMissingFiles> <ProjectNamePrefix>MyCompany.MyProduct.</ProjectNamePrefix> <ProjectNameIsFileName>true</ProjectNameIsFileName> <IgnoredProjects> AVerySpecialProject1; AVerySpecialProject2; </IgnoredProjects> </SolutionSettings> <ProjectSettings> <DetectMissingFiles>true</DetectMissingFiles> <AllowBuildEvents>true</AllowBuildEvents> <AssemblyNameIsProjectName>true</AssemblyNameIsProjectName> <RootNamespaceIsAssemblyName>true</RootNamespaceIsAssemblyName> <RequiredImports>StyleCop.MSBuild.Targets</RequiredImports> <Properties> <TreatWarningsAsErrors>true</TreatWarningsAsErrors> <StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings> </Properties> </ProjectSettings> </Settings>

แม้ว่าการตั้งค่าจะค่อนข้างอธิบายได้ แต่ฉันจะอธิบายบางส่วนของพวกเขา:

• MinSolutionFormatVersion / MaxSolutionFormatVersion จะป้องกันไม่ให้นักพัฒนาของคุณเปลี่ยนเวอร์ชัน Visual Studio
• DetectMissingFiles มีประโยชน์มากสำหรับเนื้อหาเว็บแบบสแตติกหรือไฟล์ที่ไม่ใช่โค้ดอื่นๆ ที่เพิ่มลงในโซลูชันหรือโปรเจ็กต์
• AllowBuildEvents สามารถป้องกันไม่ให้เพิ่มเหตุการณ์บิลด์ที่กำหนดเอง ซึ่งอาจทำสิ่งที่ไม่จำเป็น
• Properties เป็นองค์ประกอบที่ยืดหยุ่นที่สุด: คุณสามารถตรวจสอบคุณสมบัติใดๆ กับค่าที่ต้องการได้ ไม่ว่าจะเป็นคุณสมบัติที่รู้จักหรือกำหนดเอง

บทสรุป

เราได้ตรวจสอบแนวทางปฏิบัติมาตรฐาน ไฟล์การกำหนดค่า และการตั้งค่าโครงการต่างๆ ที่คุณสามารถนำไปใช้เมื่อเริ่มโครงการใหม่ การทำเช่นนี้ในตอนเริ่มต้นจะช่วยลดหนี้ทางเทคนิคในอนาคต และจะทำให้ซอร์สโค้ดผลิตภัณฑ์ของคุณดูดีและเป็นมืออาชีพ สำหรับโครงการโอเพ่นซอร์ส สิ่งนี้มีความสำคัญเป็นพิเศษ เนื่องจากผู้มีส่วนร่วมจะทราบความคาดหวังของคุณโดยตรวจสอบการกำหนดค่าโซลูชันและไฟล์โครงการ