เหตุใดจึงต้องใช้แอสเซมบลีที่มีชื่อรัดกุม


107

ข้อดีของการใช้แอสเซมบลีที่มีชื่อรัดกุมคืออะไร?

อะไรคือสิ่งที่ไม่สามารถทำได้ด้วยชุดประกอบปกติ?

คำตอบ:


92

ให้ฉันระบุประโยชน์ของการตั้งชื่อชุดประกอบของคุณให้รัดกุมก่อน:

  1. การตั้งชื่อแอสเซมบลีของคุณให้รัดกุมช่วยให้คุณรวมแอสเซมบลีของคุณไว้ในGlobal Assembly Cache (GAC) ดังนั้นจึงช่วยให้คุณสามารถแบ่งปันระหว่างแอพพลิเคชั่นต่างๆ

  2. การตั้งชื่อที่ชัดเจนจะรับประกันชื่อเฉพาะสำหรับชุดประกอบนั้น ดังนั้นจึงไม่มีใครสามารถใช้ชื่อแอสเซมบลีเดียวกันได้

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

ข้อมูลเพิ่มเติมเกี่ยวกับการตั้งชื่อที่ชัดเจนจาก Microsoft อยู่ในStrong-Named Assemblies ( MSDN )


1
แน่ใจในข้อ 4? ฉันคิดว่าอาจจะมีการเปลี่ยนแปลงพฤติกรรมนี้เมื่อไม่นานมานี้ ฉันพยายามทำให้การโหลดแอสเซมบลีที่มีชื่อแน่นหนาล้มเหลวโดยการแก้ไข แต่มันโหลดโดยไม่มีอะไรเกิดขึ้น
Jens

19
เกี่ยวกับ # 4 ที่ไม่ถูกต้อง ไม่ได้ออกแบบมาเพื่อป้องกันการงัดแงะ ดูblogs.msdn.com/b/shawnfa/archive/2005/12/13/…สำหรับข้อมูลเพิ่มเติม
Colin Bowern

1
@ RobV8R 90% ของการอ้างอิงของเราเป็นโอเพนซอร์ซคีย์ส่วนตัวอยู่ใน git repos สาธารณะ (ตามคำแนะนำของ Microsoft) และทุกคนที่ต้องการใช้งานได้
trampster

1
@ RobV8R คุณไม่สามารถใช้คำว่าประนีประนอมในที่นี้ได้ซึ่งหมายความว่าตั้งใจให้เป็นความลับตั้งแต่แรก แนวทางของ Microsoft คือควรเก็บคีย์ส่วนตัวไว้ในที่เก็บซอร์สสาธารณะของคุณ คีย์ส่วนตัวจะไม่ถูกบุกรุกโดยเจตนาเผยแพร่ เนื่องจากว่าคีย์ส่วนตัวเป็นที่รู้จักและมีวัตถุประสงค์เพื่อใช้โดยผู้ที่แก้ไขโค้ดโอเพนซอร์สของโปรเจ็กต์หลัก (มิฉะนั้นจะละเมิดสิทธิ์การใช้งานในหลาย ๆ กรณี) ผู้ที่ทำเช่นนี้จะใช้หมายเลขเวอร์ชันอื่น แต่เป็นคีย์เดียวกันในกรณีนี้ ในกรณีที่จำเป็นต้องมีการเปลี่ยนเส้นทางการเชื่อมโยง
trampster

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

9

อะไรคือสิ่งที่ไม่สามารถทำได้ด้วยชุดประกอบปกติ?

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

หากคุณใช้แอปอัตโนมัติหรือการตั้งค่าแอปพลิเคชันที่กำหนดขอบเขตผู้ใช้ให้โดย VisualStudio (สืบทอด System.Configuration.ApplicationSettingsBase) ชื่อที่คาดเดายากจะสร้างไดเร็กทอรี 1 รายการภายใน% LOCALAPPDATA% ที่มีชื่อเช่น "YourApplication.exe_StrongName_kjsdfzsuzdfiuzgpoisdiufzsdouifE" ไม่ว่า EXE จะเป็นอย่างไร ตั้งอยู่.

แต่หากไม่มีชื่อที่ชัดเจนตำแหน่ง (= พา ธ ) ของ EXE จะถูกใช้เพื่อสร้างค่าแฮชซึ่งแตกต่างกันอยู่แล้วระหว่างการสร้าง DEBUG และ RELEASE การสร้างไดเรกทอรีจำนวนมากภายใน% LOCALAPPDATA% ที่มีชื่อว่า "YourApplication.exe_Url_dfg8778d6fs7g6d7f8g69sdf" ทำให้ใช้ไม่ได้สำหรับการปรับใช้ ClickOnce ที่ไดเร็กทอรีการติดตั้งเปลี่ยนแปลงทุกครั้งที่อัพเดต


5

ฉันต้องการเพิ่มว่าหากไม่มีชื่อที่ชัดเจนคุณไม่สามารถใช้การเปลี่ยนเส้นทางการผูกในไฟล์กำหนดค่าได้

สิ่งนี้จะไม่ทำงาน:

  <dependentAssembly>
    <assemblyIdentity name="MyAssembly.MyComponent" publicKeyToken="null" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
  </dependentAssembly>

คุณต้องมีโทเค็นคีย์สาธารณะ

  <dependentAssembly>
    <assemblyIdentity name="MyAssembly.MyComponent" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
  </dependentAssembly>

9
ไม่จำเป็นต้องมีการเปลี่ยนเส้นทางการเชื่อมโยงหากคุณไม่มีชื่อที่รัดกุม
trampster

0

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.