ในชั่วพริบตา เป็นเวลา 4 ปีแล้วนับตั้งแต่ Microsoft เปิดตัวแพลตฟอร์ม .net และ .net ก็ได้รับการอัปเกรดจาก 1.0 เป็น 1.1 เป็น 2.0 เช่นกัน เนื่องจากการดึงดูดของคุณสมบัติที่เหนือกว่าต่างๆ ของ asp.net 2.0 และเทียบกับ 2005 IDE ทุกคนจึงยุ่งอยู่กับการเรียนรู้ 2.0 และอัปเกรดโปรเจ็กต์เป็นเทียบกับปี 2005 เพื่อการพัฒนา แต่ในความเป็นจริงแล้ว หลายโครงการไม่สามารถอัปเกรดเป็นเวอร์ชันใหม่ได้เนื่องจากสาเหตุหลายประการ เมื่อเวลาผ่านไป ปัญหาในการบำรุงรักษาโปรเจ็กต์เวอร์ชันเก่าจะกลายเป็นปัญหามากขึ้นเรื่อยๆ แม้ว่า .net จะถือกำเนิดมาได้ไม่นาน แต่เวลา 4 ปีก็เพียงพอที่จะสะสมโปรเจ็กต์จำนวนมาก
ฉันมีโปรเจ็กต์ที่พัฒนาด้วย vs.net 2002 ซึ่งยังไม่ได้รับการอัปเกรดเนื่องจากสาเหตุหลายประการ (ส่วนใหญ่เป็นเพราะโปรเจ็กต์ทำงานได้ดีมาระยะหนึ่งแล้วก่อนที่ vs.net 2003 จะออกมา และโปรแกรม asp.net อื่น ๆ บนเซิร์ฟเวอร์ไม่สามารถใช้งานได้ เพื่อปรับให้เข้ากับข้อกำหนดด้านความปลอดภัยของ .net 1.1)
เมื่อแพลตฟอร์มการพัฒนาของบริษัทได้รับการอัพเกรด vs.net 2002 และ vs.net 2003 จะถูกติดตั้งบนคอมพิวเตอร์ในเวลาเดียวกัน ซึ่งช่วยแก้ไขปัญหาการบำรุงรักษาเวอร์ชันต่างๆ ของโปรเจ็กต์เป็นการชั่วคราว ต่อมาโครงการได้ผ่านช่วงการบำรุงรักษาและไม่ได้รับการอัปเดตเป็นเวลานาน คอมพิวเตอร์ของฉันก็ถูกติดตั้งใหม่เช่นกัน และ vs.net 2002 ก็ถูกกำจัดไปโดยสิ้นเชิง แต่ภายในปี 2005 ลูกค้าขอให้มีการปรับเปลี่ยนทุกๆ หนึ่งหรือสองเดือน และต้องดำเนินการอย่างรวดเร็ว ไม่มีทางอื่นใดที่ลูกค้าทำได้ยอดเยี่ยมมากจนต้องทำการเปลี่ยนแปลงแม้หลังจากผ่านช่วงการบำรุงรักษาไปแล้ว แต่ปัญหาก็มาถึง หากไม่มี vs 2002 ก็ไม่สามารถคอมไพล์ได้
การติดตั้ง .net framework 1.0 บนคอมพิวเตอร์และเรียก csc ด้วยตนเองเพื่อคอมไพล์โค้ดที่แก้ไขนั้นยุ่งยากมาก โครงการนี้มีการอ้างอิงจำนวนมาก และการเขียนบรรทัดคำสั่งนั้นซับซ้อนมาก สิ่งนี้จะเจ็บปวดอย่างยิ่งเมื่อโปรเจ็กต์มีหลายโฟลเดอร์ ฉันยังทำแบบทดสอบและเขียนโปรแกรมเพื่อคอมไพล์ด้วย แต่ฉันขี้เกียจและไม่เคยรู้เลย
วันนี้ฉันต้องแก้ไขโปรแกรมอีกครั้งและทันใดนั้นฉันก็จำได้ว่าฉันใช้แอตทริบิวต์ Src ของคำสั่ง @Page ครั้งหนึ่งเร็วมาก (ในปี 2545) เมื่อใช้แอตทริบิวต์นี้ asp.net จะใช้โมเดลการคอมไพล์ของตัวเองแทนการใช้ CodeBehind ของ vs.net IDE ด้วยวิธีนี้สามารถเผยแพร่โค้ดได้โดยไม่ต้องคอมไพล์เป็น dll เมื่อเข้าถึงไซต์ asp, net จะรวบรวมไฟล์ aspx และไฟล์ .aspx.vb เข้าด้วยกันโดยอัตโนมัติ มีข้อเสียหลักสองประการของวิธีนี้: 1. ไฟล์โค้ด (.vb) จะต้องเผยแพร่ไปยังเซิร์ฟเวอร์ 2. vs.net IDE ไม่รองรับ เนื่องจากปัญหาที่สอง ฉันจึงเลิกใช้มันและลืมมันไป ตอนนี้ฉันกังวลว่าจะไม่สามารถคอมไพล์โปรแกรมได้ ตราบใดที่โค้ดที่แก้ไขยังคงมีผล ข้อบกพร่องอื่นๆ จะไม่ได้รับการพิจารณา อย่างไรก็ตาม ซอร์สโค้ดทั้งหมดจะถูกเผยแพร่ไปยังเซิร์ฟเวอร์ ฉันเพิ่มแอตทริบิวต์ Src ให้กับคำสั่ง @Page โดยใช้ค่าเดียวกันกับแอตทริบิวต์ CodeBehind โดยชี้ไปที่ไฟล์โค้ด จากนั้นแก้ไขโค้ดในไฟล์ .vb รีเฟรช การแก้ไขมีผล และการบำรุงรักษาเสร็จสิ้น เจ๋งมาก นั่นคือสิ่งที่ฉันจะทำต่อจากนี้ไป เนื่องจาก vs.net IDE ไม่รองรับและมีการกล่าวถึงใน MSDN จึงมีเพียงไม่กี่คนที่รู้ว่า .net มีโมเดลการคอมไพล์นี้ แชร์เลย ถ้าใครประสบปัญหาแบบเดียวกับผมลองเพิ่ม Src ลงเพจได้นะครับ 555 ง่ายและรวดเร็วครับ เพื่อหาเครื่องมือในการคอมไพล์
สรุป: หลายๆ คนรวมทั้งฉันด้วย ชอบที่จะคอมไพล์โปรแกรมเป็น dll ซึ่งให้ความรู้สึกเหมือนเป็นซอฟต์แวร์ที่เปิดตัวมากกว่า ในความเป็นจริง วิธีการ "เผยแพร่ซอร์สโค้ดทั้งหมดไปยังเซิร์ฟเวอร์และรวบรวมโค้ดอย่างสมบูรณ์ระหว่างรันไทม์" นั้นดีมาก และทำให้งานบำรุงรักษาในอนาคตง่ายขึ้นอย่างมาก บริษัทหลายแห่งทำโปรเจ็กต์สำหรับลูกค้าโดยไม่จำเป็นต้องซ่อนซอร์สโค้ดจากลูกค้า ในกรณีนี้ การใช้วิธีนี้จะนำมาซึ่งประโยชน์อย่างมากต่องานบำรุงรักษาในอนาคต ไม่ว่าจะอัปเกรด .net n ครั้งหรือติดตั้งเครื่องมือพัฒนาเวอร์ชันที่เกี่ยวข้องบนคอมพิวเตอร์ของคุณ คุณก็ไม่ต้องกังวล จัดการทุกอย่าง
หมายเหตุ: asp.net ทุกเวอร์ชันรองรับโหมดการคอมไพล์นี้ แต่ IDE ของ vs.net 2002 และ 2003 ไม่รองรับและไม่สามารถเปิดมุมมองการออกแบบได้ IDE เทียบกับ 2005 ที่เพิ่งเปิดตัวใหม่รองรับโหมดการคอมไพล์นี้ เมื่อใช้แอตทริบิวต์ Src ไม่จำเป็นต้องใช้แอตทริบิวต์ CodeBehind อีกต่อไป แต่ขอแนะนำให้คุณคงไว้ซึ่งยังช่วยคุณได้หากคุณต้องการกลับสู่มุมมองการคำนวณโดยฉับพลัน ไม่จำเป็นต้องใช้แอตทริบิวต์ Inherits แต่ขอแนะนำอย่างยิ่งว่าอย่าลบออก เนื่องจากหากคุณผูกเหตุการณ์โดยตรงในการประกาศควบคุมของไฟล์ aspx (เช่น: OnClick="....") จะมี เกิดข้อผิดพลาดโดยไม่มีแอตทริบิวต์ Inherits
ที่มา: cwbboy BLOG