แนวทางปฏิบัติที่ดีที่สุดสำหรับโซลูชันขนาดใหญ่ใน Visual Studio (2008) [ปิด]

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

• คุณจะจัดการการอ้างอิงระหว่างโครงการอย่างไรให้ดีที่สุด
  • "คัดลอกในเครื่อง" ควรเปิดหรือปิด?

• ทุกโครงการควรสร้างไปยังโฟลเดอร์ของตัวเองหรือควรสร้างไปยังโฟลเดอร์ผลลัพธ์เดียวกัน (ทั้งหมดเป็นส่วนหนึ่งของแอปพลิเคชันเดียวกัน)

• โฟลเดอร์ของโซลูชันเป็นวิธีที่ดีในการจัดระเบียบสิ่งต่างๆหรือไม่?

ฉันรู้ว่าการแยกโซลูชันออกเป็นโซลูชันขนาดเล็กหลาย ๆ ตัวเป็นตัวเลือก แต่มันมาพร้อมกับชุดการปรับโครงสร้างใหม่และการสร้างความปวดหัวดังนั้นบางทีเราสามารถบันทึกได้สำหรับเธรดแยกต่างหาก :-)

คุณอาจสนใจบทความ MSBuild สองบทความที่ฉันเขียนไว้

MSBuild: แนวทางปฏิบัติที่ดีที่สุดสำหรับการสร้างงานสร้างที่เชื่อถือได้ตอนที่ 1

MSBuild: แนวทางปฏิบัติที่ดีที่สุดสำหรับการสร้างงานสร้างที่เชื่อถือได้ตอนที่ 2

ในส่วนที่ 2 มีส่วนการสร้างต้นไม้แหล่งใหญ่ที่คุณอาจต้องการดู

หากต้องการตอบคำถามของคุณสั้น ๆ ที่นี่:

• CopyLocal? แน่นอนว่าปิดสิ่งนี้
• สร้างไปยังโฟลเดอร์เอาต์พุตหนึ่งหรือหลายโฟลเดอร์? สร้างไปยังโฟลเดอร์ผลลัพธ์เดียว
• โฟลเดอร์โซลูชัน? นี่เป็นเรื่องของรสนิยม

กล่าวว่าอิบราฮิมฮาชิมิ

หนังสือของฉัน: ภายใน Microsoft Build Engine: การใช้ MSBuild และ Team Foundation Build

+1 เพื่อประหยัดการใช้โฟลเดอร์โซลูชันเพื่อช่วยจัดระเบียบสิ่งต่างๆ

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

FWIW เราใช้การอ้างอิงโครงการสำหรับโซลูชันและแม้ว่า nuget น่าจะเป็นทางเลือกที่ดีกว่าในปัจจุบัน แต่พบว่า svn: externals ทำงานได้ดีสำหรับทั้งบุคคลที่สามและ (ประเภทเฟรมเวิร์ก) เพียงทำความคุ้นเคยกับการใช้หมายเลขแก้ไขเฉพาะแทนที่จะเป็น HEAD เมื่ออ้างถึง svn: externals (มีความผิดตามที่เรียกเก็บ :)

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

เรามีปัญหาคล้ายกันเนื่องจากเรามีโครงการที่ต้องจัดการ 109 โครงการ ในการตอบคำถามเดิมจากประสบการณ์ของเรา:

1. คุณจัดการการอ้างอิงระหว่างโครงการอย่างไรให้ดีที่สุด

เราใช้ตัวเลือกเมนูบริบท "เพิ่มการอ้างอิง" หากเลือก "โครงการ" การอ้างอิงจะถูกเพิ่มลงในไฟล์โซลูชันส่วนกลางเดียวของเราตามค่าเริ่มต้น

2. ควรเปิดหรือปิด "คัดลอกในเครื่อง"?

ออกจากประสบการณ์ของเรา การคัดลอกพิเศษจะเพิ่มเวลาในการสร้าง

3. ทุกโปรเจ็กต์ควรสร้างไปยังโฟลเดอร์ของตัวเองหรือควรสร้างไปยังโฟลเดอร์เอาต์พุตเดียวกัน (ทั้งหมดเป็นส่วนหนึ่งของแอปพลิเคชันเดียวกัน)

ผลลัพธ์ทั้งหมดของเราจะอยู่ในโฟลเดอร์เดียวที่เรียกว่า 'bin' แนวคิดที่ว่าโฟลเดอร์นี้จะเหมือนกับเมื่อมีการปรับใช้ซอฟต์แวร์ วิธีนี้ช่วยป้องกันปัญหาที่เกิดขึ้นเมื่อการตั้งค่าของนักพัฒนาแตกต่างจากการตั้งค่าการปรับใช้

4. โฟลเดอร์โซลูชันเป็นวิธีที่ดีในการจัดระเบียบสิ่งต่างๆหรือไม่?

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

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

ตัวอย่างบางส่วนของเค้าโครงโซลูชันของเรา:

\bin

OurStuff.SLN

OurStuff.App.Administrator
OurStuff.App.Common
OurStuff.App.Installer.Database
OurStuff.App.MediaPlayer
OurStuff.App.Operator
OurStuff.App.Service.Gateway
OurStuff.App.Service.CollectionStation
OurStuff.App.ServiceLocalLauncher
OurStuff.App.StackTester
OurStuff.Auditing
OurStuff.Data
OurStuff.Database
OurStuff.Database.Constants
OurStuff.Database.ObjectModel
OurStuff.Device
OurStuff.Device.Messaging
OurStuff.Diagnostics
...
[etc]

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

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

ในแง่ของการลดความเจ็บปวดของอาคารคุณสามารถใช้ตัวเลือก "เครื่องมือจัดการการกำหนดค่า ... " สำหรับบิวด์เพื่อเปิดหรือปิดการสร้างโปรเจ็กต์เฉพาะ คุณสามารถมี "โปรเจ็กต์ [n] บิลด์" ที่สามารถยกเว้นโปรเจ็กต์บางโปรเจ็กต์และใช้โปรเจ็กต์นั้นเมื่อคุณกำหนดเป้าหมายโปรเจ็กต์เฉพาะ

เท่าที่โครงการมากกว่า 100 โครงการดำเนินไปฉันรู้ว่าคุณไม่ต้องการถูกตอกกลับในคำถามนี้เกี่ยวกับประโยชน์ของการลดขนาดโซลูชันของคุณ แต่ฉันคิดว่าคุณไม่มีทางเลือกอื่นในการเร่งความเร็วในการโหลด (และ การใช้หน่วยความจำ) ของ devenv

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

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

บันทึก

ข้างต้นใช้ได้กับโซลูชันของฉันซึ่งโดยทั่วไปแล้วจะเป็นเว็บแอปพลิเคชันและฉันไม่พบปัญหาใด ๆ เกี่ยวกับการอ้างอิง แต่อาจเป็นไปได้!

เรามีปัญหาที่คล้ายกัน เราแก้ปัญหาโดยใช้โซลูชันขนาดเล็ก เรามีโซลูชันหลักที่เปิดทุกอย่าง แต่สมบูรณ์แบบ ที่ไม่ดี ดังนั้นเราจึงแบ่งกลุ่มโซลูชันขนาดเล็กตามประเภทของนักพัฒนาซอฟต์แวร์ ดังนั้นนักพัฒนา DB จึงมีโซลูชันที่โหลดโครงการที่พวกเขาสนใจนักพัฒนาบริการและนักพัฒนา UI ในสิ่งเดียวกัน เป็นเรื่องยากที่ใครบางคนต้องเปิดวิธีแก้ปัญหาทั้งหมดเพื่อทำสิ่งที่พวกเขาต้องทำในแต่ละวัน ไม่ใช่ยาครอบจักรวาล แต่มีทั้งด้านบนและด้านล่าง ดู "multi-solution model" ในบทความนี้ (ละเว้นส่วนที่เกี่ยวกับการใช้ VSS :)

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

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

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

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

หวังว่าข้อมูลนี้จะช่วยได้

เรามีโครงการมากกว่า 60 โครงการและเราไม่ได้ใช้ไฟล์โซลูชัน เรามีโครงการ C # และ VB.Net ผสมผสานกัน ประสิทธิภาพเป็นปัญหาเสมอ เราไม่ได้ทำงานในทุกโครงการในเวลาเดียวกัน นักพัฒนาแต่ละคนจะสร้างไฟล์โซลูชันของตนเองตามโครงการที่กำลังดำเนินการอยู่ ไฟล์โซลูชันไม่ได้รับการตรวจสอบในการควบคุมแหล่งที่มาของเรา

โครงการไลบรารีคลาสทั้งหมดจะสร้างไปยังโฟลเดอร์ CommonBin ที่รากของไดเร็กทอรีต้นทาง Executable / Web Projects สร้างขึ้นในแต่ละโฟลเดอร์

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

เราใช้สิ่งนี้มาสองสามปีแล้วและไม่มีข้อร้องเรียนใด ๆ

ทุกอย่างเกี่ยวข้องกับคำจำกัดความและมุมมองของคุณว่าโซลูชันและโครงการคืออะไร ในความคิดของฉันวิธีแก้ปัญหาก็คือการจัดกลุ่มโครงการเชิงตรรกะที่ช่วยแก้ปัญหาความต้องการที่เฉพาะเจาะจงมาก เราพัฒนาแอปพลิเคชันอินทราเน็ตขนาดใหญ่ แต่ละแอปพลิเคชันภายในอินทราเน็ตนั้นมีโซลูชันของตัวเองซึ่งอาจมีโปรเจ็กต์สำหรับ exes หรือบริการ windows ด้วย จากนั้นเรามีเฟรมเวิร์กรวมศูนย์ซึ่งมีสิ่งต่างๆเช่นคลาสพื้นฐานและตัวช่วยและ HTTphandlers / httpmodules กรอบงานพื้นฐานมีขนาดใหญ่พอสมควรและถูกใช้โดยแอปพลิเคชันทั้งหมด การแยกโซลูชันจำนวนมากด้วยวิธีนี้จะช่วยลดปริมาณโครงการที่ต้องใช้ในการแก้ปัญหาเนื่องจากส่วนใหญ่ไม่มีอะไรเกี่ยวข้องกัน

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

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

หากคุณต้องการอ้างอิงโดยตรงกับ DLL คุณจะต้องอ้างอิงในโปรเจ็กต์ของคุณด้วยการ copy local false (บางที่เช่น c: \ mycompany \ bin \ mycompany.dll) รันไทม์คุณจะต้องเพิ่มการตั้งค่าบางอย่างใน app.config หรือ web.config เพื่อให้อ้างอิงไฟล์ที่ไม่อยู่ใน GAC หรือรันไทม์ bin ในความเป็นจริงทั้งหมดไม่สำคัญว่าจะคัดลอกในเครื่องหรือไม่หรือถ้า dll ลงท้ายด้วย bin หรือแม้แต่ใน GAC เนื่องจากการกำหนดค่าจะแทนที่ทั้งสองอย่าง ฉันคิดว่ามันเป็นการปฏิบัติที่ไม่ดีในการคัดลอกท้องถิ่นและมีระบบที่ยุ่งเหยิง คุณมักจะต้องคัดลอกโลคัลชั่วคราวหากคุณต้องการดีบักเป็นหนึ่งในแอสเซมบลีเหล่านั้น

คุณสามารถอ่านบทความของฉันเกี่ยวกับวิธีใช้ DLL ทั่วโลกโดยไม่ต้องใช้ GAC ฉันไม่ชอบ GAC เป็นส่วนใหญ่เพราะมันป้องกันการใช้งาน xcopy และไม่ได้ทริกเกอร์การเริ่มต้นอัตโนมัติในแอปพลิเคชัน

http://nbaked.wordpress.com/2010/03/28/gac-alternative/

การตั้งค่า CopyLocal = false จะลดเวลาในการสร้าง แต่อาจทำให้เกิดปัญหาที่แตกต่างกันในช่วงเวลาการปรับใช้

มีหลายสถานการณ์เมื่อคุณต้องการให้ Copy Local เหลือ 'ไว้ที่ True เช่นโปรเจ็กต์ระดับบนสุดการอ้างอิงระดับที่สอง DLL ที่เรียกโดยการสะท้อนกลับ

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