.sln ควรมุ่งมั่นที่จะควบคุมแหล่งที่มาหรือไม่?

101

เป็นแนวทางปฏิบัติที่ดีที่สุดในการส่งไฟล์. sln ไปยังตัวควบคุมแหล่งที่มา เมื่อใดที่เหมาะสมหรือไม่เหมาะสมที่จะทำ

อัปเดต คำตอบมีจุดดีหลายประการ ขอบคุณสำหรับคำตอบ!

21

ฉันเชื่อว่าเป็นไฟล์. SUO ที่คุณไม่ต้องการกระทำ

— apandit

สำหรับบันทึกฉันเชื่อว่ารายการงาน (ถ้าคุณใช้) จะถูกเก็บไว้ในไฟล์. SUO ... ดังนั้นแม้ว่าคุณอาจไม่ต้องการกำหนดให้ควบคุมแหล่งที่มา แต่คุณอาจไม่ต้องการ 'เพียงแค่ลบ' เป็น cruft ภายนอก

— Benjol

69

ฉันคิดว่ามันชัดเจนจากคำตอบอื่น ๆ ว่าไฟล์โซลูชันมีประโยชน์และควรมีความมุ่งมั่นแม้ว่าจะไม่ได้ใช้สำหรับงานสร้างอย่างเป็นทางการก็ตาม สะดวกสำหรับทุกคนที่ใช้ฟีเจอร์ Visual Studio เช่น Go To Definition / Declaration

โดยค่าเริ่มต้นจะไม่มีเส้นทางสัมบูรณ์หรือสิ่งประดิษฐ์เฉพาะเครื่องอื่น ๆ (น่าเสียดายที่เครื่องมือเพิ่มเติมบางอย่างไม่ได้รักษาคุณสมบัตินี้ไว้อย่างถูกต้องเช่น AMD CodeAnalyst) หากคุณระมัดระวังในการใช้เส้นทางสัมพัทธ์ในไฟล์โครงการของคุณ (ทั้ง C ++ และ C #) เครื่องมือเหล่านี้จะไม่ขึ้นกับเครื่อง เกินไป.

คำถามที่น่าจะเป็นประโยชน์กว่าคือคุณควรยกเว้นไฟล์อะไร นี่คือเนื้อหาของไฟล์. gitignore สำหรับโครงการ VS 2008 ของฉัน:

*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/

(รายการสุดท้ายสำหรับผู้สร้างโปรไฟล์ AMD CodeAnalyst เท่านั้น)

สำหรับ VS 2010 คุณควรยกเว้นสิ่งต่อไปนี้:

ipch/
*.sdf
*.opensdf

— เทรเวอร์โรบินสัน
แหล่งที่มา

2

ฉันยังมีกฎการละเว้นสำหรับผลการทดสอบหน่วย บางคนอาจจะเช็คอิน แต่ฉันไม่ชอบความยุ่ง

— Matthew Whited

9

+1 - โดยส่วนตัวแล้วฉันเองก็ไม่ได้กระทำสิ่งใดที่สร้างขึ้นดังนั้น bin / และ obj /

— Steven Evers

ฉันยอมรับเฉพาะไฟล์. sln ที่มีมากกว่า 1 โปรเจ็กต์

— Justin

2

นี่คือรูปแบบการละเว้นการโค่นล้มของฉันทั่วโลก: * .vsmdi * .suo * / [Bb] ใน [Bb] ใน * / obj obj TestResults *. [Uu] ser * Thumbs.db * Web.Publish.xml * WebApplication.Publish xml * Web.log

— Merritt

นี่คือไฟล์. gitignore ที่ใช้ร่วมกันโดยทั่วไปซึ่งมีไฟล์ชั่วคราวผลลัพธ์การสร้างและไฟล์ที่สร้างโดยโปรแกรมเสริม Visual Studio ยอดนิยม

— Lauren Van Sloun

58

ใช่ - ฉันคิดว่ามันเหมาะสมเสมอ การตั้งค่าเฉพาะของผู้ใช้อยู่ในไฟล์อื่น ๆ

— ลูฟรังโก
แหล่งที่มา

3

แน่นอน. sln มีการอ้างอิงถึงไฟล์. prj (โปรเจ็กต์)

— dplante

20

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

ไม่มีการตั้งค่าเฉพาะผู้ใช้

— จาเร็ดพาร์
แหล่งที่มา

13

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

— Mehrdad Afshari
แหล่งที่มา

8

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

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

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

— Brian Rasmussen
แหล่งที่มา

ดูเหมือนว่านี่อาจเป็นคำตอบสำหรับคำถามที่ยังไม่มีคำตอบของฉัน ( stackoverflow.com/questions/1490728/… ) มีโอกาสที่จะได้รับสำเนาของปลั๊กอินนี้หรือไม่?

— Benjol

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

— Brian Rasmussen

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

— Benjol

8

ใช่สิ่งที่คุณควรกระทำคือ:

วิธีแก้ปัญหา (* .sln)
ไฟล์โครงการ
ไฟล์ต้นฉบับทั้งหมด
ไฟล์ config ของแอพ
สร้างสคริปต์

สิ่งที่คุณไม่ควรกระทำ ได้แก่ :

ตัวเลือกผู้ใช้โซลูชัน (.suo) ไฟล์
สร้างไฟล์ที่สร้างขึ้น (เช่นการใช้สคริปต์การสร้าง) [แก้ไข:] - เฉพาะในกรณีที่สคริปต์และเครื่องมือการสร้างที่จำเป็นทั้งหมดพร้อมใช้งานภายใต้การควบคุมเวอร์ชัน (เพื่อให้แน่ใจว่าบิลด์เป็นของจริงในประวัติ cvs)

เกี่ยวกับไฟล์ที่สร้างขึ้นโดยอัตโนมัติอื่น ๆ มีหัวข้อแยก

— กรู
แหล่งที่มา

1

ฉันไม่เห็นด้วยกับ "ไฟล์ที่สร้างขึ้นโดยอัตโนมัติ"

— Mehrdad Afshari

@Mehrdad คุณคิดว่าไฟล์ Intelisense ควรได้รับการยอมรับด้วยหรือไม่?

— Edison Gustavo Muenz

1

@ เอดิสัน: ไม่. ฉันอ้างถึงไฟล์ต้นฉบับที่สร้างขึ้นโดยอัตโนมัติเช่น LINQ กับบริบทข้อมูล SQL เป็นต้น

— Mehrdad Afshari

2

ไม่ใช่ไฟล์ Formname.Designer.cs ที่ถือว่าสร้างขึ้นโดยอัตโนมัติใช่หรือไม่

— jasonh

1

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

— Groo

5

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

— Arnkrishn
แหล่งที่มา

5

ภายใต้สถานการณ์ส่วนใหญ่ควรยอมรับไฟล์. sln กับการควบคุมแหล่งที่มา

หากไฟล์. sln ของคุณถูกสร้างขึ้นโดยเครื่องมืออื่น (เช่น CMake) แสดงว่าอาจไม่เหมาะสมที่จะนำไฟล์เหล่านี้ไปใช้ในการควบคุมแหล่งที่มา

— Ferruccio
แหล่งที่มา

4

ใช่คุณต้องการรวมไฟล์. sln ไว้เสมอซึ่งจะมีลิงก์ไปยังโครงการทั้งหมดที่อยู่ในโซลูชัน

— Josh Weatherly
แหล่งที่มา

2

เราทำเพราะทำให้ทุกอย่างตรงกัน โครงการที่จำเป็นทั้งหมดตั้งอยู่ด้วยกันและไม่มีใครต้องกังวลว่าจะพลาดโครงการใดไป บิลด์เซิร์ฟเวอร์ของเรา (Ant Hill Pro) ยังใช้ sln เพื่อกำหนดว่าจะสร้างโปรเจ็กต์ใดสำหรับรีลีส

— kemiller2002
แหล่งที่มา

2

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

— นายกเทศมนตรี
แหล่งที่มา

1

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

— โจ
แหล่งที่มา

1

ใช่ - ทุกสิ่งที่ใช้ในการสร้างผลิตภัณฑ์ของคุณควรอยู่ในการควบคุมแหล่งที่มา

— ไมเคิล
แหล่งที่มา

1

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

— Sylvain Rodrigue
แหล่งที่มา

0

.slns เป็นสิ่งเดียวที่เราไม่มีปัญหาใน tfs!

— รหัส Silverback
แหล่งที่มา

1

มันตลกดี ... SLN เป็นไฟล์เดียวที่ฉันเคยต้องแก้ไข ... แต่ปัญหาเกิดจาก devs ไม่ระวังการผสาน

— Matthew Whited