คำถามติดแท็ก appdomain

8
วิธีโหลดแอสเซมบลีไปยัง AppDomain พร้อมการอ้างอิงทั้งหมดแบบวนซ้ำ
ฉันต้องการโหลดไปยังAppDomainแอสเซมบลีใหม่ซึ่งมีโครงสร้างอ้างอิงที่ซับซ้อน (MyDll.dll -> Microsoft.Office.Interop.Excel.dll -> Microsoft.Vbe.Interop.dll -> Office.dll -> stdole.dll) เท่าที่ฉันเข้าใจเมื่อกำลังโหลดแอสเซมบลีการAppDomainอ้างอิงจะไม่ถูกโหลดโดยอัตโนมัติและฉันต้องโหลดด้วยตนเอง ดังนั้นเมื่อฉันทำ: string dir = @"SomePath"; // different from AppDomain.CurrentDomain.BaseDirectory string path = System.IO.Path.Combine(dir, "MyDll.dll"); AppDomainSetup setup = AppDomain.CurrentDomain.SetupInformation; setup.ApplicationBase = dir; AppDomain domain = AppDomain.CreateDomain("SomeAppDomain", null, setup); domain.Load(AssemblyName.GetAssemblyName(path)); และได้รับFileNotFoundException: ไม่สามารถโหลดไฟล์หรือแอสเซมบลี 'MyDll, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = …

3
ฉันจะใช้ ISerializable ใน. NET 4+ โดยไม่ละเมิดกฎความปลอดภัยในการสืบทอดได้อย่างไร
ความเป็นมา: Noda Timeมีโครงสร้างที่ต่อเนื่องกันได้มากมาย แม้ว่าฉันไม่ชอบการทำให้เป็นอนุกรมไบนารี แต่เราก็ได้รับคำขอให้สนับสนุนมากมายกลับมาในไทม์ไลน์ 1.x เราสนับสนุนโดยใช้ISerializableอินเทอร์เฟซ เราได้รับเมื่อเร็ว ๆ นี้รายงานปัญหาของ Noda เวลา 2.x ล้มเหลวภายใน .NET ซอ รหัสเดียวกันที่ใช้ Noda Time 1.x ทำงานได้ดี ข้อยกเว้นที่เกิดขึ้นคือ: กฎความปลอดภัยในการสืบทอดถูกละเมิดในขณะที่แทนที่สมาชิก: 'NodaTime.Duration.System.Runtime.Serialization.ISerializable.GetObjectData (System.Runtime.Serialization.SerializationInfo, System.Runtime.Serialization.StreamingContext) " ความสามารถในการเข้าถึงความปลอดภัยของวิธีการลบล้างต้องตรงกับความสามารถในการเข้าถึงความปลอดภัยของวิธีการที่ถูกลบล้าง ฉันได้ จำกัด สิ่งนี้ให้แคบลงเป็นกรอบงานที่กำหนดเป้าหมาย: 1.x เป้าหมาย. NET 3.5 (โปรไฟล์ลูกค้า); 2.x เป้าหมาย. NET 4.5 พวกเขามีความแตกต่างอย่างมากในแง่ของการสนับสนุน PCL เทียบกับ. NET Core และโครงสร้างไฟล์โครงการ แต่ดูเหมือนว่าจะไม่เกี่ยวข้อง ฉันสามารถทำซ้ำสิ่งนี้ในโครงการในพื้นที่ได้ แต่ฉันไม่พบวิธีแก้ปัญหา ขั้นตอนในการสร้างซ้ำใน …

8
ฉันจะกำหนดประเภทของตัวแปรที่ประกาศโดยใช้ var ณ เวลาออกแบบได้อย่างน่าเชื่อถือได้อย่างไร
ฉันกำลังดำเนินการสิ่งอำนวยความสะดวก (Intellisense) สำหรับ C # ใน emacs แนวคิดคือถ้าผู้ใช้พิมพ์แฟรกเมนต์แล้วขอให้ดำเนินการเสร็จสิ้นโดยใช้การกดแป้นพิมพ์ร่วมกันสิ่งอำนวยความสะดวกในการทำให้เสร็จสมบูรณ์จะใช้การสะท้อน. NET เพื่อพิจารณาความสำเร็จที่เป็นไปได้ การทำเช่นนี้ต้องการให้ทราบประเภทของสิ่งที่จะเสร็จสมบูรณ์ หากเป็นสตริงจะมีชุดวิธีการและคุณสมบัติที่เป็นไปได้ ถ้าเป็น Int32 จะมีชุดแยกต่างหากและอื่น ๆ การใช้ความหมายแพคเกจรหัส lexer / parser ที่มีอยู่ใน emacs ฉันสามารถค้นหาการประกาศตัวแปรและประเภทของตัวแปรได้ ด้วยเหตุนี้จึงเป็นเรื่องง่ายที่จะใช้การสะท้อนเพื่อรับวิธีการและคุณสมบัติของประเภทจากนั้นจึงนำเสนอรายการตัวเลือกให้กับผู้ใช้ (โอเคไม่ตรงไปตรงมาที่จะทำภายใน emacs แต่การใช้ความสามารถในการเรียกใช้กระบวนการ powershell ภายใน emacsมันจะง่ายกว่ามากฉันเขียนแอสเซมบลี. NET ที่กำหนดเองเพื่อทำการสะท้อนโหลดลงใน powershell จากนั้น elisp ทำงานภายใน emacs สามารถส่งคำสั่งไปยัง powershell และอ่านการตอบกลับผ่าน comint ดังนั้น emacs จึงได้ผลลัพธ์ของการสะท้อนกลับอย่างรวดเร็ว) ปัญหามาถึงเมื่อรหัสใช้varในการประกาศสิ่งที่เสร็จสมบูรณ์ นั่นหมายความว่าไม่มีการระบุประเภทอย่างชัดเจนและการกรอกข้อมูลจะไม่ทำงาน ฉันจะกำหนดประเภทจริงที่ใช้อย่างน่าเชื่อถือได้อย่างไรเมื่อประกาศตัวแปรด้วยvarคีย์เวิร์ด เพื่อความชัดเจนฉันไม่จำเป็นต้องกำหนดตอนรันไทม์ ฉันต้องการตรวจสอบที่ "เวลาออกแบบ" …

6
ไม่มี AppDomains ใน. NET Core! ทำไม?
มีเหตุผลที่ชัดเจนว่าทำไม Microsoft จึงเลือกที่จะไม่สนับสนุน AppDomains ใน. NET Core? AppDomains มีประโยชน์อย่างยิ่งเมื่อสร้างแอปเซิร์ฟเวอร์ที่ใช้งานมานานซึ่งเราอาจต้องการอัปเดตแอสเซมบลีที่เซิร์ฟเวอร์โหลดเป็นวิธีที่ดีโดยไม่ต้องปิดเซิร์ฟเวอร์ หากไม่มี AppDomains เราจะเปลี่ยนแอสเซมบลีของเราในกระบวนการเซิร์ฟเวอร์ที่ใช้งานยาวนานได้อย่างไร AppDomains ยังให้เราแยกส่วนต่างๆของรหัสเซิร์ฟเวอร์ เช่นเดียวกับเซิร์ฟเวอร์ websocket ที่กำหนดเองสามารถมีรหัสซ็อกเก็ตใน appdomain หลักในขณะที่บริการของเราทำงานใน appdomain รอง หากไม่มี AppDomains สถานการณ์ข้างต้นจะเป็นไปไม่ได้ ฉันเห็นข้อโต้แย้งที่อาจพูดถึงการใช้แนวคิด VMs ของ Cloud สำหรับจัดการการเปลี่ยนแปลงแอสเซมบลีและไม่ต้องเสียค่าใช้จ่ายของ AppDomains แต่นี่คือสิ่งที่ Microsoft คิดหรือพูด? หรือมีเหตุผลและทางเลือกเฉพาะสำหรับสถานการณ์ข้างต้น?
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.