เก็บโครงการ Visual Studio ไว้ในไดรฟ์เครือข่าย

ในขณะที่เราใช้ Source Control เรายังดำเนินโครงการทั้งหมดของเราจากไดรฟ์เครือข่าย (ไม่ใช่ไดเร็กทอรีที่ใช้ร่วมกัน, ไดเร็กทอรีส่วนตัวบนไดรฟ์เครือข่าย) ไดรฟ์เครือข่ายได้รับการสำรองข้อมูลทุกคืน และยังใช้ Volume Shadow Copy ดังนั้น หากคุณต้องการเปลี่ยนกลับเป็นก่อนที่จะถึง SC คุณก็สามารถทำได้

เพื่อให้โครงการทำงานได้อย่างถูกต้องโดยได้รับอนุญาตอย่างถูกต้อง ให้ทำตาม ขั้นตอนเหล่านี้

โดยพื้นฐานแล้ว คุณเพียงแค่ต้องแมปไดเร็กทอรีที่แชร์กับไดรฟ์ จากนั้นให้อนุญาตตาม URL นั้นกับโค้ดทั้งหมด สมมติว่าคุณแมปกับ "N:\" จากนั้นใช้ "N:\*" เป็นรูปแบบ URL ของคุณ ไม่ชัดเจนว่าคุณจะต้องใช้ไวด์การ์ด แต่คุณต้องทำ

คำถามนี้ค่อนข้างกว้าง ดังนั้นฉันจะให้คำตอบสำหรับปัญหาหนึ่งที่ฉันเผชิญอยู่

ฉันรัน Visual Studio 2010 โดยใช้เครื่องเสมือน Parallels บน Mac ของฉันในขณะที่เก็บโปรเจ็กต์ทั้งหมดของฉันไว้ที่ฝั่ง Mac ผ่านการแชร์เครือข่าย Visual Studio จะไม่โหลดไฟล์แอสเซมบลีของโครงการจากที่นั่น การพยายามตั้งค่าสิทธิ์โดยใช้ "caspol" เพียงอย่างเดียวไม่ได้ช่วยอะไรในกรณีของฉัน

ในที่สุดสิ่งที่ใช้ได้ผลสำหรับฉันในการอนุญาตให้ Visual Studio โหลดแอสเซมบลีจากการแชร์เครือข่ายคือการแก้ไขไฟล์ "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config" (สมมติว่าเป็นค่าเริ่มต้น การติดตั้ง).

ในส่วน xml "‹runtime>" คุณต้องเพิ่ม

<loadFromRemoteSources enabled="true"/>

คุณอาจต้องเปลี่ยนการอนุญาตในไฟล์นั้นเพื่อให้สามารถเข้าถึงการเขียนได้ บันทึกไฟล์. รีสตาร์ท Visual Studio

เพื่อประโยชน์ในการตอบคำถามนี้ ฉันจึงคัดลอกความคิดเห็นนี้จาก jcarle.com:

การแชร์เครือข่ายที่เชื่อถือได้ด้วย Visual Studio 2010 / .NET Framework v4.0

20 มกราคม 2554, 16:10 น. หากคุณเป็นเหมือนฉันและเก็บโค้ดทั้งหมดไว้บนเซิร์ฟเวอร์ คุณจะได้เรียนรู้เกี่ยวกับการเชื่อถือเครือข่ายที่ใช้ร่วมกันโดยใช้ CasPol.exe อย่างไรก็ตาม เมื่อย้ายจาก Visual Studio 2008 (.NET Framework 2.0/3.0/3.5) มาเป็น Visual Studio 2010 (.NET Framework 4.0) คุณอาจพบว่าตัวเองเกาหัว

หากคุณคุ้นเคยกับการใช้ Visual Studio Command Prompt เพื่อเข้าถึง CasPol อย่างรวดเร็ว คุณอาจพบว่าบางโครงการของคุณดูเหมือนจะไม่เคารพการตั้งค่า FullTrust ใหม่ของคุณ เหตุผลก็คือว่า เว้นแต่คุณจะให้ความสนใจอย่างระมัดระวัง Visual Studio Command Prompt จะมีค่าเริ่มต้นในการเพิ่มโฟลเดอร์ .NET Framework 4.0 ลงในเส้นทาง หากโปรเจ็กต์ของคุณยังคงทำงานภายใต้ .NET Framework 2.0/3.0/3.5 จะต้องมีการตั้งค่า CasPol สำหรับเวอร์ชันเหล่านั้นด้วย โปรดทราบว่าโดยส่วนตัวแล้วฉันยังประสบความสำเร็จมากขึ้นด้วยการใช้ 1 เป็นกลุ่มโค้ดแทนที่จะเป็น 1.2

หากต้องการเชื่อถือการแชร์เครือข่ายสำหรับ .NET Framework ทุกเวอร์ชัน เพียงเรียก CasPol สำหรับแต่ละเวอร์ชันโดยใช้เส้นทางแบบเต็มดังต่อไปนี้:

C:\Windows\Microsoft.NET\Framework\v2.0.50727\CasPol -m -ag 1 -url ไฟล์://YourSharePath* FullTrust
C:\Windows\Microsoft.NET\Framework\v4.0.30319\CasPol - m -ag 1 -url ไฟล์://YourSharePath* FullTrust

ฉันไม่แนะนำให้ทำเช่นนั้นหากคุณมี (หรือไม่มี) หลายคนที่ทำงานในโครงการนี้ คุณแค่ถามถึงปัญหา

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

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

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

ฉันเข้าใจว่านี่เป็นเธรดเก่า แต่นี่เป็นเธรดที่ดีที่สุดที่ฉันพบเมื่อต้องการแก้ไขปัญหาที่คล้ายกัน ฉันมี Visual Studio 2013 บนกล่องเสมือน (โดยใช้ Win 8.1) และโค้ดบนเครื่องโฮสต์ (Win 7) แม้ว่าฉันจะเปิดโซลูชันได้ แต่ฉันก็ไม่สามารถคอมไพล์ได้ คำตอบอื่น ๆ ทั้งหมดในเรื่องนี้เกี่ยวข้องกับซอฟต์แวร์รุ่นเก่า ดังนั้นฉันจึงเพิ่มคำตอบนี้เพื่ออัปเดตคำถามที่พบบ่อยนี้ด้วยวิธีแก้ไขปัญหาที่เหมาะกับฉัน

นี่คือสิ่งที่ฉันทำ สร้างรายการรีจิสทรีเพื่อให้สามารถใช้เส้นทาง UNC เป็นไดเร็กทอรีปัจจุบันได้

คำเตือน: การใช้ Registry Editor ไม่ถูกต้องอาจทำให้เกิดปัญหาร้ายแรงทั้งระบบ ซึ่งอาจจำเป็นต้องติดตั้ง Windows NT ใหม่เพื่อแก้ไขปัญหาดังกล่าว Microsoft ไม่สามารถรับประกันได้ว่าปัญหาใดๆ ที่เกิดจากการใช้ Registry Editor จะสามารถแก้ไขได้ ใช้เครื่องมือนี้ด้วยความเสี่ยงของคุณเอง

ภายใต้เส้นทางรีจิสทรี: HKEY_CURRENT_USER \Software \Microsoft \Command Processor

เพิ่มค่า DisableUNCCheck REG_DWORD และตั้งค่าเป็น 0 x 1 (Hex)

คำเตือน: หากคุณเปิดใช้งานคุณลักษณะนี้และเริ่มคอนโซลที่มีไดเร็กทอรีปัจจุบันเป็นชื่อ UNC ให้เริ่มแอปพลิเคชันจากคอนโซลนั้น จากนั้นปิดคอนโซล อาจทำให้เกิดปัญหาในแอปพลิเคชันที่เริ่มต้นจากคอนโซลนั้น

พบข้อมูลนี้ที่ลิงก์: http://support.microsoft.com/kb/156276

แล้วเราจะเรียบเรียงคำถามนี้ให้เป็นคำถามที่ทุกคนสามารถตอบได้ล่ะ? ฉันมีปัญหาเดียวกันกับโปสเตอร์เริ่มแรก

ฉันมีสำเนาของ VB 2008 (เพิ่งอัพเกรดจาก VB6) หากฉันจัดเก็บโซลูชันไว้ในไดรฟ์เครือข่ายที่สำรองไว้ ระบบจะไม่ทำงานเลยแม้แต่ครั้งเดียว มันทำให้เกิดข้อผิดพลาด "ผู้โทรที่เชื่อถือได้บางส่วน" สำหรับการเข้าถึงโมดูล แม้ว่าจะถูกตั้งค่า "allowpartiallytrustedcallers" ในแอสเซมบลีก็ตาม ถ้าฉันเก็บไฟล์ไว้ใน C: (ไม่ได้สำรองข้อมูล) ของฉัน มันจะทำงานได้อย่างยอดเยี่ยม จนกว่าฉันจะใส่มันลงในแชร์ไดรฟ์เพื่อให้ทุกคนได้ใช้ และฉันก็จะกลับสู่ปัญหาเดิมอีกครั้ง

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

- แก้ไข: ฉันพบปัญหาว่าทำไมมันถึงเพิกเฉยคำสั่ง AllowPartiallyTrustedCallers ฉันกำลังพยายามอ้างอิง ADODB ซึ่งไม่อนุญาตให้เชื่อถือได้บางส่วน ดังนั้นไม่มีเครือข่ายใดที่ปฏิบัติการได้สามารถเข้าถึงฐานข้อมูลได้? Microsoft มีอะไรกับอินทราเน็ตอยู่แล้ว?

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

PS: นี่ฟังดูเหมือนเป็นกรณีทั่วไปของการวิศวกรรมมากเกินไปสำหรับฉัน

คุณประสบปัญหาเฉพาะหรือไม่?

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

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

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

ฉันอยากจะวางเรื่องนี้ไว้เพราะฉันใช้เวลาครึ่งวันในการพยายามคิดออกและคิดว่ามันอาจช่วยคนอื่นได้บ้าง ขอบคุณมากและขอให้โชคดี!!!

เอริค

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

ปัญหา: โปรเจ็กต์ NET 4.0, SVN repo, โฟลเดอร์ชำระเงินอยู่ในไดรฟ์ในเครื่อง, แอสเซมบลีที่อ้างอิงถูกสร้างโดยเซิร์ฟเวอร์บิลด์และพร้อมใช้งานบนไดรฟ์เครือข่าย Visual Studio บน W7 สามารถเพิ่มข้อมูลอ้างอิงได้ แต่ไม่สามารถสร้างโครงการได้

วิธีแก้ไข: เนื่องจาก NET 4.0 ไม่ได้จัดเตรียมแซนด์บ็อกซ์โดยอัตโนมัติสำหรับแอสเซมบลีเครือข่ายอีกต่อไป คุณจึงต้องสร้างแซนด์บ็อกซ์ที่เชื่อถือได้อย่างสมบูรณ์ผ่านการอัพเดต machine.config http://msdn.microsoft.com/en-us/library/dd409252.aspx

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

e.g.

mklink /D "C:\Users\Self\Documents" "\\domain.net\users\self\My Documents"

จากนั้นคุณก็สามารถเปิดโปรเจ็กต์ได้โดยใช้เส้นทาง C:\Users\Self\Documents\ แทนที่จะเป็นเส้นทาง UNC

(คุณต้องระวัง เนื่องจาก Visual Studio จะนำคุณไปยังเส้นทาง '\\domain.net..' โดยอัตโนมัติ หากคุณคลิกสองครั้งที่ symlink เมื่อคุณเรียกดูโครงการ ฉันต้องคัดลอกและวาง 'C: \Users\' เพื่อให้เปิดด้วยเส้นทางอักษรระบุไดรฟ์)

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

คุณควรได้รับคำเตือนว่าคุณลักษณะบางอย่างใน Visual Studio จะปฏิเสธที่จะทำงานกับไดรฟ์เครือข่าย

ตัวอย่างเช่น ไฟล์ mdf ของอินสแตนซ์ผู้ใช้ SQL Express จะต้องอยู่ในไดรฟ์ในเครื่อง

อีกตัวอย่างหนึ่ง หากคุณใช้เส้นทาง UNC คุณต้องแน่ใจว่าเส้นทางเหล่านั้นสั้นเพียงพอ

ฉันพบว่าสิ่งนี้มีประโยชน์ในขณะที่ลองใช้ vc11 ที่มีความคล้ายคลึงซึ่งทำงานบน mac: http://social.msdn.microsoft.com/Forums/en-US/toolsforwinapps/thread/2ffdcb01-c511-4961-834b-afd5f2fbb8e1 และโดยเฉพาะ:

1) คุณสามารถเปลี่ยนจากการดีบักในเครื่องเป็นการดีบักแบบระยะไกลและตั้งชื่อเครื่องเป็น 'localhost' การดำเนินการนี้จะทำการปรับใช้ระยะไกลบนเครื่องท้องถิ่นของคุณ (ซึ่งจะไม่ใช้ไดเร็กทอรีของโปรเจ็กต์) คุณไม่จำเป็นต้องติดตั้งเครื่องมือ Remote Debugger หรือเริ่ม msvsmon เพื่อให้สิ่งนี้ทำงานบน localhost

ในกรณีที่สิ่งนี้ช่วยเหลือผู้อื่นได้ ฉันต้องทำตามขั้นตอนที่ระบุไว้ที่นี่เพื่อเพิ่มตำแหน่งการแชร์เครือข่ายลงในโซนอินทราเน็ต Windows โดยเฉพาะอย่างยิ่ง ฉันมีปัญหากับ Visual Studio ค้างเมื่อโหลดเมื่อเปิดโซลูชันบนเครือข่ายที่ใช้ร่วมกัน (เช่น การใช้ VMware Fusion และการเปิดโซลูชันจากฮาร์ดไดรฟ์ของ Mac ของฉัน) ฉันยังมีปัญหากับ PostSharp ที่ทำงานในสถานการณ์นี้ด้วย

"ฉันจะทำให้มันทำงานได้อย่างไร" คุณมีทางเลือกสองทาง:

ตัวเลือก A: 1. ย้ายไฟล์ทั้งหมดกลับไปยังฮาร์ดไดรฟ์ในเครื่องของคุณ 2. ใช้ซอฟต์แวร์สำรองข้อมูลบางประเภทในเครื่องของคุณ 3. ทดสอบโซลูชันการสำรองข้อมูลดังกล่าว 4. เขียนโค้ดต่อไป

ทางเลือก B: 1. รับสำเนาหนึ่งในผลิตภัณฑ์ควบคุมแหล่งที่มาฟรีและนำไปใช้งาน 2. ตรวจสอบให้แน่ใจว่าได้รับการสำรองข้อมูลแล้ว 3. ทดสอบ

ตัวเลือก C: ใช้หนึ่งในแหล่งเก็บข้อมูลการควบคุมแหล่งที่มาออนไลน์ที่มีอยู่ Google, SourceForge, CodePlex อะไรสักอย่าง

คำถามของฉันก็คือทำไมคุณถึงถามเรื่องนี้ มันไม่ทำงานเมื่อคุณจัดเก็บไว้ในไดรฟ์เครือข่ายใช่ไหม ฉันไม่ได้ลองด้วยตัวเอง และปัญหาหนึ่งที่ฉันจินตนาการได้ก็คือโค้ด .NET ที่ทำงานจากไดรฟ์เครือข่าย (เช่น จากไดเร็กทอรี bin\Debug ซึ่งอยู่บนไดรฟ์เครือข่ายด้วย) จะทำงานในโหมดแซนด์บ็อกซ์ เว้นแต่ว่าคุณจะยุ่งกับ CASPOL (หรือใช้ 3.5 SP1 ซึ่งฉันได้ยินมาว่าได้ขจัดอุปสรรคนั้นออกไปแล้ว)

หากคุณมีปัญหาเฉพาะ ให้ถามเกี่ยวกับปัญหาเหล่านั้น อย่าถามว่า "ทำไม X ถึงไม่ทำงาน"

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