สมมติว่าคุณมีเว็บแอปทั่วไปและมีการกำหนดค่าไฟล์อย่างไรก็ตาม นักพัฒนาทุกคนที่ทำงานในโครงการจะมีเวอร์ชันเดียวสำหรับกล่องสำหรับผู้พัฒนาของพวกเขาจะมีเวอร์ชัน dev, prod และ stage คุณจัดการกับสิ่งนี้อย่างไรในการควบคุมแหล่งที่มา? ไม่เช็คอินไฟล์นี้เลยตรวจสอบด้วยชื่ออื่นหรือทำอะไรแปลก ๆ ไปพร้อมกัน?
คำตอบ:
สิ่งที่ฉันเคยทำในอดีตคือการมีไฟล์กำหนดค่าเริ่มต้นซึ่งตรวจสอบในการควบคุมแหล่งที่มา จากนั้นนักพัฒนาแต่ละรายจะมีไฟล์กำหนดค่าการลบล้างของตนเองซึ่งไม่รวมอยู่ในการควบคุมแหล่งที่มา ก่อนอื่นแอปจะโหลดค่าเริ่มต้นจากนั้นหากมีไฟล์ลบล้างอยู่ให้โหลดและใช้การตั้งค่าใด ๆ จากการแทนที่ในการตั้งค่าไปยังไฟล์เริ่มต้น
โดยทั่วไปไฟล์ลบล้างที่มีขนาดเล็กจะดีกว่า แต่ก็สามารถมีการตั้งค่าเพิ่มเติมสำหรับนักพัฒนาที่มีสภาพแวดล้อมที่ไม่ได้มาตรฐาน
การกำหนดค่าเป็นรหัสและคุณควรกำหนดเวอร์ชัน เรายึดไฟล์การกำหนดค่าของเราตามชื่อผู้ใช้ ทั้งใน UNIX / Mac และ Windows คุณสามารถเข้าถึงชื่อล็อกอินของผู้ใช้ได้และตราบใดที่สิ่งเหล่านี้ไม่ซ้ำกับโปรเจ็กต์คุณก็สบายดี คุณสามารถแทนที่สิ่งนี้ได้ในสภาพแวดล้อม แต่คุณควรควบคุมเวอร์ชันทั้งหมด
นอกจากนี้ยังช่วยให้คุณตรวจสอบการกำหนดค่าของผู้อื่นซึ่งสามารถช่วยวินิจฉัยปัญหาของโครงสร้างและแพลตฟอร์มได้
อย่าเวอร์ชันไฟล์นั้น เวอร์ชันเทมเพลตหรือบางสิ่งบางอย่าง
ทีมของฉันเก็บไฟล์การกำหนดค่าเวอร์ชันแยกกันสำหรับแต่ละสภาวะแวดล้อม (web.config.dev, web.config.test, web.config.prod) สคริปต์การปรับใช้ของเราคัดลอกเวอร์ชันที่ถูกต้องเปลี่ยนชื่อเป็น web.config ด้วยวิธีนี้เรามีการควบคุมเวอร์ชันเต็มของไฟล์กำหนดค่าสำหรับแต่ละสภาพแวดล้อมสามารถดำเนินการต่างได้อย่างง่ายดาย ฯลฯ
ขณะนี้ฉันมีไฟล์กำหนดค่า "template" ที่มีนามสกุลเพิ่มเติมเช่น:
web.config.rename
อย่างไรก็ตามฉันพบปัญหากับวิธีนี้หากมีการเปลี่ยนแปลงที่สำคัญ
+1 ในแนวทางเทมเพลต
แต่เนื่องจากคำถามนี้มีแท็ก Git จึงมีทางเลือกอื่นที่กระจายอยู่ในใจซึ่งการปรับแต่งจะถูกเก็บไว้ในสาขาการทดสอบส่วนตัว:
A---B---C---D--- <- mainline (public)
\ \
B'------D'--- <- testing (private)
ในโครงร่างนี้ mainline มีไฟล์กำหนดค่า "template" ทั่วไปซึ่งต้องการการปรับเปลี่ยนเพียงเล็กน้อยเพื่อให้ใช้งานได้
ตอนนี้นักพัฒนา / ผู้ทดสอบสามารถปรับแต่งไฟล์กำหนดค่าให้ตรงกับเนื้อหาของหัวใจและยอมรับการเปลี่ยนแปลงเหล่านี้เฉพาะในสาขาการทดสอบส่วนตัว (เช่น B '= B + customizations) ทุกครั้งที่เมนไลน์ก้าวหน้าขึ้นพวกเขาจะรวมเข้ากับการทดสอบได้อย่างง่ายดายซึ่งส่งผลให้เกิดการรวมคอมมิตเช่น D '(= D + เวอร์ชันผสานของการปรับแต่งของ B)
โครงร่างนี้จะเปล่งประกายเมื่อมีการอัปเดตไฟล์กำหนดค่า "เทมเพลต": การเปลี่ยนแปลงจากทั้งสองฝ่ายจะรวมเข้าด้วยกันและมีแนวโน้มอย่างมากที่จะทำให้เกิดความขัดแย้ง (หรือการทดสอบล้มเหลว) หากเข้ากันไม่ได้!
วิธีแก้ปัญหาที่เราใช้คือมีเพียงไฟล์คอนฟิกูเรชันไฟล์เดียว (web.config / app.config) แต่เราเพิ่มส่วนพิเศษให้กับไฟล์ที่มีการตั้งค่าสำหรับทุกสภาพแวดล้อม
มีLOCAL, DEV, QA, PRODUCTIONแต่ละส่วนประกอบด้วยคีย์การกำหนดค่าที่เกี่ยวข้องกับสภาพแวดล้อมนั้นในไฟล์กำหนดค่าของเรา
สิ่งที่ทำให้ทั้งหมดนี้ทำงานได้คือชุดประกอบชื่อxxx สภาพแวดล้อมที่อ้างอิงในแอปพลิเคชันทั้งหมดของเรา (winforms และ webforms) ซึ่งจะบอกแอปพลิเคชันว่าทำงานบนสภาพแวดล้อมใด
ชุด xxx.Environment อ่านข้อมูลบรรทัดเดียวจากเครื่องกำหนดรูปแบบของเครื่องที่ระบุซึ่งบอกว่าอยู่บน DEV, QA และอื่น ๆ รายการนี้มีอยู่ในเวิร์กสเตชันและเซิร์ฟเวอร์ทั้งหมดของเรา
หวังว่านี่จะช่วยได้
ฉันเก็บไฟล์ config ทุกเวอร์ชันไว้ใน source control เสมอในโฟลเดอร์เดียวกับไฟล์ web.config
ตัวอย่างเช่น
web.config
web.qa.config
web.staging.config
web.production.config
ฉันชอบหลักการตั้งชื่อนี้ (ตรงข้ามกับ web.config.production หรือ production.web.config) เพราะ
ควรกำหนดค่าไฟล์กำหนดค่าเริ่มต้นเพื่อให้คุณสามารถเรียกใช้แอปพลิเคชันภายในเครื่องของคุณเอง
ที่สำคัญที่สุดไฟล์เหล่านี้ควรจะเหมือนกันเกือบ 100% ในทุกๆด้านแม้แต่การจัดรูปแบบ คุณไม่ควรใช้แท็บในเวอร์ชันหนึ่งและเว้นวรรคในอีกเวอร์ชันสำหรับการเยื้อง คุณควรจะสามารถเรียกใช้เครื่องมือที่แตกต่างกับไฟล์เพื่อดูว่าอะไรแตกต่างกันอย่างไร ฉันชอบที่จะใช้ WinMerge เพื่อแยกไฟล์
เมื่อกระบวนการสร้างของคุณสร้างไบนารีควรมีงานที่เขียนทับ web.config ด้วยไฟล์ config ที่เหมาะสมกับสภาพแวดล้อมนั้น หากไฟล์ถูกบีบอัดไฟล์ที่ไม่เกี่ยวข้องควรถูกลบออกจากบิลด์นั้น
ฉันเคยใช้เทมเพลตมาก่อนเช่น web.dev.config, web.prod.config เป็นต้น แต่ตอนนี้ชอบใช้เทคนิค 'override file' มากกว่า ไฟล์ web.config มีการตั้งค่าส่วนใหญ่ แต่ไฟล์ภายนอกมีค่าเฉพาะสภาพแวดล้อมเช่นการเชื่อมต่อ db คำอธิบายที่ดีในบล็อกพอลวิลสัน
ฉันคิดว่าสิ่งนี้ช่วยลดจำนวนการทำซ้ำระหว่างไฟล์กำหนดค่าซึ่งอาจทำให้เกิดความเจ็บปวดเมื่อเพิ่มค่า / แอตทริบิวต์ใหม่
@ แกรนท์พูดถูก
ฉันอยู่ในทีมที่มีนักพัฒนาอื่น ๆ เกือบ 100 คนและไฟล์กำหนดค่าของเราไม่ได้ถูกตรวจสอบในการควบคุมแหล่งที่มา เรามีเวอร์ชันของไฟล์ในที่เก็บซึ่งถูกดึงออกมาพร้อมกับการเช็คเอาต์แต่ละครั้ง แต่จะไม่เปลี่ยนแปลง
มันได้ผลดีสำหรับเรา
ฉันควบคุมเวอร์ชัน แต่ไม่เคยส่งไปยังเซิร์ฟเวอร์อื่น หากเซิร์ฟเวอร์ที่ใช้งานจริงต้องการการเปลี่ยนแปลงฉันทำการเปลี่ยนแปลงนั้นโดยตรงกับไฟล์กำหนดค่า
มันอาจจะไม่สวย แต่ก็ใช้ได้ดี
app / web.config เวอร์ชันวานิลลาที่เช็คอินควรเป็นแบบทั่วไปเพียงพอที่จะทำงานบนเครื่องของนักพัฒนาทั้งหมดและได้รับการอัปเดตอยู่เสมอเมื่อมีการเปลี่ยนแปลงการตั้งค่าใหม่ ๆ ฯลฯ หากคุณต้องการชุดการตั้งค่าเฉพาะสำหรับ dev / การตั้งค่าการทดสอบ / การผลิตตรวจสอบในไฟล์แยกต่างหากด้วยการตั้งค่าเหล่านั้นตามที่ GateKiller ระบุด้วยหลักการตั้งชื่อบางประเภทแม้ว่าฉันมักจะใช้ "web.prod.config" เพื่อไม่ให้เปลี่ยนนามสกุลไฟล์
เราใช้ไฟล์กำหนดค่าเทมเพลตที่เช็คอินในการควบคุมเวอร์ชันจากนั้นขั้นตอนในบิลด์อัตโนมัติของเราเพื่อแทนที่รายการเฉพาะในไฟล์เทมเพลตด้วยการตั้งค่าเฉพาะสภาพแวดล้อม การตั้งค่าเฉพาะสภาพแวดล้อมจะถูกเก็บไว้ในไฟล์ XML แยกต่างหากซึ่งอยู่ภายใต้การควบคุมเวอร์ชันด้วย
เรากำลังใช้ MSBuild ในบิลด์อัตโนมัติของเราดังนั้นเราจึงใช้งาน XmlUpdate จากMSBuild Community Tasksเพื่ออัปเดตค่า
เป็นเวลานานที่ฉันได้ทำสิ่งที่ bcwood ทำ ฉันเก็บสำเนาของ web.dev.config, web.test.config, web.prod.config และอื่น ๆ ภายใต้การควบคุมแหล่งที่มาจากนั้นระบบสร้าง / ปรับใช้ของฉันจะเปลี่ยนชื่อโดยอัตโนมัติเมื่อปรับใช้กับสภาพแวดล้อมต่างๆ คุณได้รับความซ้ำซ้อนจำนวนหนึ่งระหว่างไฟล์ (โดยเฉพาะอย่างยิ่งกับสิ่งที่อยู่ใน asp.net ทั้งหมด) แต่โดยทั่วไปแล้วมันใช้งานได้ดีจริงๆ คุณต้องแน่ใจด้วยว่าทุกคนในทีมจำได้ว่าอัปเดตทั้งหมดไฟล์ที่เมื่อพวกเขาทำให้เกิดการเปลี่ยนแปลง
ยังไงก็ตามฉันชอบเก็บ ".config" ต่อท้ายเป็นนามสกุลเพื่อไม่ให้การเชื่อมโยงไฟล์เสียหาย
สำหรับไฟล์ config เวอร์ชันสำหรับนักพัฒนาท้องถิ่นฉันพยายามอย่างเต็มที่เพื่อสนับสนุนให้ผู้คนใช้การตั้งค่าในเครื่องเดียวกันให้มากที่สุดเพื่อที่จะได้ไม่จำเป็นต้องมีเวอร์ชันของคุณเอง มันไม่ได้ผลสำหรับทุกคนเสมอไปซึ่งในกรณีนี้ผู้คนมักจะเปลี่ยนมันในท้องถิ่นตามความจำเป็นและไปจากที่นั่น มันไม่เจ็บปวดเกินไปหรืออะไร
ในโครงการของเราเรามีการกำหนดค่าที่เก็บไว้ในไฟล์ที่มีคำนำหน้าจากนั้นระบบบิวด์ของเราจะดึงการกำหนดค่าที่เหมาะสมตามชื่อโฮสต์ของระบบปัจจุบัน สิ่งนี้ใช้ได้ดีสำหรับเราในทีมที่ค่อนข้างเล็กทำให้เราสามารถใช้การเปลี่ยนแปลงการกำหนดค่ากับไฟล์ของคนอื่นได้หาก / เมื่อเราเพิ่มรายการกำหนดค่าใหม่ เห็นได้ชัดว่านี่ไม่ได้ปรับขนาดโครงการโอเพ่นซอร์สที่มีนักพัฒนาจำนวนไม่ จำกัด
เรามีปัญหาสองประการที่นี่
ประการแรกเราต้องควบคุมไฟล์การกำหนดค่าที่มาพร้อมกับซอฟต์แวร์
เป็นเรื่องง่ายทั้งสองอย่างสำหรับนักพัฒนาในการตรวจสอบสิ่งที่ไม่ต้องการเพื่อเปลี่ยนเป็นไฟล์ config หลักหากพวกเขากำลังใช้ไฟล์เดียวกันในสภาพแวดล้อม devolvement
ในอีกด้านหนึ่งหากคุณมีไฟล์คอนฟิกูเรชันแยกต่างหากที่รวมอยู่ในโปรแกรมติดตั้งมันง่ายมากที่จะลืมเพิ่มการตั้งค่าใหม่ลงไปหรือปล่อยให้ความคิดเห็นในนั้นไม่ตรงกันกับความคิดเห็นในการเบี่ยงเบน การกำหนดค่าไฟล์
จากนั้นเรามีปัญหาที่นักพัฒนาต้องเก็บสำเนาของไฟล์คอนฟิกูเรชันให้เป็นปัจจุบันเนื่องจากนักพัฒนารายอื่นเพิ่มการตั้งค่าคอนฟิกใหม่ อย่างไรก็ตามการตั้งค่าบางอย่างเช่นสตริงการเชื่อมต่อฐานข้อมูลจะแตกต่างกันสำหรับนักพัฒนาแต่ละราย
มีปัญหาที่ 3 ที่คำถาม / คำตอบไม่ครอบคลุม คุณจะรวมการเปลี่ยนแปลงที่ลูกค้าทำกับไฟล์คอนฟิกูเรชันของคุณได้อย่างไรเมื่อคุณติดตั้งซอฟต์แวร์เวอร์ชันใหม่
ฉันยังไม่เห็นโซลูชันที่ดีที่ใช้งานได้ดีในทุกกรณีอย่างไรก็ตามฉันได้เห็นวิธีแก้ปัญหาบางส่วน (ซึ่งสามารถรวมกันในชุดต่างๆได้ตามต้องการ) ซึ่งช่วยลดปัญหาได้มาก
อันดับแรกลดจำนวนรายการคอนฟิกูเรชันที่คุณมีในไฟล์คอนฟิกูเรชันหลักของคุณ
หากคุณไม่จำเป็นต้องให้ลูกค้าเปลี่ยนการแมปของคุณให้ใช้ Fluent NHibernate (หรืออื่น ๆ ) เพื่อย้ายการกำหนดค่าเป็นโค้ด
ในทำนองเดียวกันสำหรับการตั้งค่าการฉีดตำแหน่ง
แยกไฟล์คอนฟิกูเรชันเมื่อเป็นไปได้เช่นใช้ไฟล์แยกต่างหากเพื่อกำหนดค่าบันทึก Log4Net ใด
อย่าทำรายการซ้ำระหว่างไฟล์การกำหนดค่าจำนวนมากเช่นหากคุณมีเว็บแอปพลิเคชัน 4 รายการที่ติดตั้งทั้งหมดในเครื่องเดียวกันให้มีไฟล์การกำหนดค่าโดยรวมที่ไฟล์ web.config ในแต่ละแอปพลิเคชันชี้ไป
(ใช้เส้นทางสัมพัทธ์ตามค่าเริ่มต้นดังนั้นจึงเป็นเรื่องยากที่จะต้องเปลี่ยนไฟล์ web.config)
ประมวลผลไฟล์คอนฟิกูเรชันการพัฒนาเพื่อรับไฟล์คอนฟิกูเรชันการจัดส่ง
สามารถทำได้โดยมีค่าเริ่มต้นในข้อคิดเห็น Xml ที่ตั้งค่าไว้ในไฟล์คอนฟิกูเรชันเมื่อสร้างเสร็จ หรือมีส่วนที่ถูกลบเป็นส่วนหนึ่งของกระบวนการสร้างตัวติดตั้ง.
แทนที่จะมีสตริงการเชื่อมต่อฐานข้อมูลเพียงหนึ่งสตริงให้มีหนึ่งสตริงต่อผู้พัฒนา
เช่นขั้นแรกให้มองหา“ database_ianr” (โดยที่ ianr คือชื่อผู้ใช้หรือชื่อเครื่องของฉัน) ในไฟล์การกำหนดค่าในขณะทำงานหากไม่พบให้มองหา“ ฐานข้อมูล”
มีระดับที่ 2 "เช่น -oracle หรือ -sqlserver" ทำให้ผู้พัฒนาเข้าถึงระบบฐานข้อมูลทั้งสองได้เร็วขึ้น
แน่นอนว่าสิ่งนี้สามารถทำได้สำหรับค่าคอนฟิกูเรชันอื่น ๆ
จากนั้นค่าทั้งหมดที่ลงท้ายด้วย“ _userName” สามารถกำหนดลายได้ก่อนที่จะส่งไฟล์การกำหนดค่า
อย่างไรก็ตามท้ายที่สุดแล้วคุณคือ“ เจ้าของไฟล์คอนฟิกูเรชัน” ที่รับผิดชอบในการจัดการไฟล์คอนฟิกูเรชันตามด้านบนหรืออย่างอื่นอย่างมีความรับผิดชอบ นอกจากนี้เขา / เธอควรทำความแตกต่างในไฟล์การกำหนดค่าการหันหน้าเข้าหาลูกค้าก่อนการจัดส่งแต่ละครั้ง
คุณไม่สามารถขจัดความต้องการคนที่ห่วงใยปัญหาสั้น ๆ นี้ได้
ฉันไม่คิดว่าจะมีโซลูชันเดียวที่ใช้ได้กับทุกกรณีเนื่องจากอาจขึ้นอยู่กับความไวของข้อมูลในไฟล์กำหนดค่าหรือภาษาโปรแกรมที่คุณใช้และปัจจัยอื่น ๆ อีกมากมาย แต่ฉันคิดว่าสิ่งสำคัญคือต้องเก็บไฟล์ config สำหรับสภาพแวดล้อมทั้งหมดภายใต้การควบคุมแหล่งที่มาดังนั้นคุณสามารถรู้ได้ตลอดเวลาว่ามีการเปลี่ยนแปลงเมื่อใดและโดยใครและที่สำคัญกว่านั้นคือสามารถกู้คืนได้หากมีสิ่งผิดปกติเกิดขึ้น และพวกเขาจะ
นี่คือวิธีที่ฉันทำ โดยปกติแล้วสำหรับโครงการ nodejs แต่ฉันคิดว่ามันใช้ได้กับเฟรมเวิร์กและภาษาอื่นด้วย
สิ่งที่ฉันทำคือสร้างconfigsไดเร็กทอรีที่รูทของโปรเจ็กต์และภายใต้ไดเร็กทอรีนั้นจะเก็บไฟล์หลายไฟล์สำหรับทุกสภาพแวดล้อม (และบางครั้งก็แยกไฟล์สำหรับสภาวะแวดล้อมของผู้พัฒนาแต่ละรายด้วย) ซึ่งทั้งหมดจะถูกติดตามในการควบคุมซอร์ส และมีไฟล์จริงที่โค้ดใช้ชื่อconfigที่รูทของโปรเจ็กต์ นี่เป็นไฟล์เดียวที่ไม่ได้ติดตาม มันก็เป็นแบบนี้
root
|
|- config (not tracked)
|
|- configs/ (all tracked)
|- development
|- staging
|- live
|- James
เมื่อมีคนตรวจสอบโครงการเขาคัดลอกไฟล์กำหนดค่าที่เขาต้องการใช้ในรายการที่ไม่ถูกติดตาม configไฟล์ที่ไม่ได้และเขามีอิสระที่จะแก้ไขได้ตามที่ต้องการ แต่ยังรับผิดชอบในการคัดลอกการเปลี่ยนแปลงเหล่านี้ก่อนที่เขาจะส่งไปยังไฟล์สภาพแวดล้อมอื่น ๆ ตามต้องการ
และบนเซิร์ฟเวอร์ไฟล์ที่ไม่ได้ติดตามอาจเป็นเพียงสำเนา (หรือข้อมูลอ้างอิง) ของไฟล์ที่ติดตามซึ่งสอดคล้องกับสภาพแวดล้อมนั้น ใน JS คุณสามารถมี 1 บรรทัดเพื่อต้องการไฟล์นั้น
ขั้นตอนนี้อาจซับซ้อนเล็กน้อยในตอนแรก แต่ก็มีข้อดีคือ 1. คุณไม่ต้องกังวลว่าไฟล์ config จะถูกลบหรือแก้ไขบนเซิร์ฟเวอร์โดยไม่ต้องสำรองข้อมูล 2. เช่นเดียวกันหากนักพัฒนามีการกำหนดค่าที่กำหนดเอง เครื่องและเครื่องของเขาหยุดทำงานไม่ว่าด้วยเหตุผลใดก็ตาม 3. ก่อนการปรับใช้ใด ๆ คุณสามารถแตกไฟล์ config สำหรับdevelopmentและstagingตัวอย่างและดูว่ามีอะไรขาดหายไปหรือเสียหายหรือไม่
เราเพียงตรวจสอบไฟล์การกำหนดค่าการผลิตต่อไปผู้พัฒนามีหน้าที่เปลี่ยนไฟล์เมื่อดึงออกจากแหล่งที่มาอย่างปลอดภัยสำหรับการจัดเตรียมหรือการพัฒนา สิ่งนี้เผาเราในอดีตดังนั้นฉันจะไม่แนะนำ
ฉันประสบปัญหาเดียวกันนี้และพบวิธีแก้ปัญหา ก่อนอื่นฉันเพิ่มไฟล์ทั้งหมดลงในที่เก็บส่วนกลาง (รวมถึงไฟล์ของนักพัฒนาด้วย)
ดังนั้นหากนักพัฒนาดึงไฟล์จากที่เก็บก็จะมีการกำหนดค่านักพัฒนาอยู่ที่นั่นด้วย เมื่อทำการเปลี่ยนแปลงไฟล์นี้ Git ไม่ควรตระหนักถึงการเปลี่ยนแปลงเหล่านี้ การเปลี่ยนแปลงดังกล่าวไม่สามารถผลักดัน / ตกลงกับที่เก็บได้ แต่ยังคงอยู่ในเครื่อง
update-index --assume-unchangedฉันจะแก้ไขเรื่องนี้โดยใช้คำสั่งคอมไพล์: ฉันสร้างไฟล์ bat ที่ดำเนินการใน prebuild ของโปรเจ็กต์ที่มีไฟล์ที่ Git ควรละเว้นการเปลี่ยนแปลง นี่คือรหัสที่ฉันใส่ในไฟล์ bat:
IF NOT EXIST %2%\.git GOTO NOGIT
set fileName=%1
set fileName=%fileName:\=/%
for /f "useback tokens=*" %%a in ('%fileName%') do set fileName=%%~a
set "gitUpdate=git update-index --assume-unchanged"
set parameter= "%gitUpdate% %fileName%"
echo %parameter% as parameter for git
"C:\Program Files (x86)\Git\bin\sh.exe" --login -i -c %parameter%
echo Make FIleBehaveLikeUnchangedForGit Done.
GOTO END
:NOGIT
echo no git here.
echo %2%
:END
ในการสร้างล่วงหน้าของฉันฉันจะโทรไปที่ไฟล์ bat ตัวอย่างเช่น:
call "$(ProjectDir)\..\..\MakeFileBehaveLikeUnchangedForGit.bat" "$(ProjectDir)Web.config.developer" "$(SolutionDir)"
ฉันพบไฟล์ bat ใน SO ที่คัดลอกไฟล์ config ที่ถูกต้องไปยัง web.config / app.config ฉันยังเรียกไฟล์ค้างคาวนี้ในการสร้างล่วงหน้า รหัสสำหรับไฟล์ bat นี้คือ:
@echo off
echo Comparing two files: %1 with %2
if not exist %1 goto File1NotFound
if not exist %2 goto File2NotFound
fc %1 %2
if %ERRORLEVEL%==0 GOTO NoCopy
echo Files are not the same. Copying %1 over %2
copy %1 %2 /y & goto END
:NoCopy
echo Files are the same. Did nothing
goto END
:File1NotFound
echo %1 not found.
goto END
:File2NotFound
copy %1 %2 /y
goto END
:END
echo Done.
ในการสร้างล่วงหน้าของฉันฉันจะโทรไปที่ไฟล์ bat ตัวอย่างเช่น:
call "$(ProjectDir)\..\..\copyifnewer.bat" "$(ProjectDir)web.config.$(ConfigurationName)" "$(ProjectDir)web.config