WinRT .NET 4.5 และ RCW

แค่อยากรู้ว่ามีใครมีเวลาเพียงพอกับ WinRT หรือไม่ที่จะเข้าใจว่ามีพื้นที่ใน WinRT และ .NET 4.5 ที่ส่งผลกระทบต่อโปรแกรมเมอร์ .NET บางส่วนของรายการเก่า ๆ ที่พบในการเขียนโปรแกรม VSTO และ COM Interop Office ที่เกี่ยวข้องกับ RCW และความแตกต่างใน การนับการอ้างอิง COM และ .NET GC นอกเหนือจากการไม่ใช้ตัวสรุป (ตรวจสอบให้แน่ใจว่าคุณได้รับการอ้างอิงถึง .NET RCW ทั้งหมด ฯลฯ)

ไม่ใช่เรื่องใหญ่แค่อยากรู้ว่าพวกเขาแยกการพิจารณาเหล่านั้นออกไปหรือดีกว่านั้น แต่สถาปัตยกรรมก็แตกต่างอย่างมาก และข้อกังวลเหล่านี้ก็ใช้ไม่ได้ด้วยซ้ำ

ขอบคุณล่วงหน้า

บางทีวิธีที่ดีกว่าในการถามคำถามก็คือว่ามันยังคงเป็นสถาปัตยกรรมเดียวกันของวัตถุ. NET ในรูปแบบหน่วยความจำที่รวบรวมที่มีการจัดการ / ขยะที่อ้างอิงถึงวัตถุ COM (WinRT) ในสถาปัตยกรรมหน่วยความจำนับอ้างอิงที่ไม่ได้รับการจัดการ (ยังแซนด์บ็อกซ์) หรือไม่

เว้นแต่ว่าจะมี "ความมหัศจรรย์" บางอย่างในการผูกข้อมูลเมตาหรือสภาพแวดล้อมแบบแซนด์บ็อกซ์ เราก็จำเป็นต้องใช้แนวทางเดียวกันกับที่เรามีกับ RCW


c# windows-runtime windows-8
person Alexander Hunter    schedule 04.10.2011    source แหล่งที่มา
comment
ทุกสิ่งที่ฉันเคยได้ยินและเห็นมาจนถึงตอนนี้ยังคงชี้ไปที่ RCW และธุรกิจตามปกติ หากมีการเปลี่ยนแปลงใด ๆ ใน CLR 4.5 หรือการเปลี่ยนแปลงใด ๆ ที่วางแผนไว้ ก็ถือว่าเป็นความลับที่ดี stackoverflow.com/questions/7457371/why-is- winrt-unmanaged/ ไม่มีสิ่งใดในการสัมภาษณ์ล่าสุดกับ Vance Morrison channel9.msdn.com/posts/   -  person Hans Passant    schedule 05.10.2011
comment
ฉันเพิ่งพบความคิดเห็นในโพสต์แยกต่างหาก ในขณะที่เลเยอร์ thunking ใช้ RCW แต่ RCW สำหรับรันไทม์ของ windows นั้นเบากว่า P/Invoke RCW แบบเก่า – Larry Osterman 15 ก.ย. เวลา 14:02 น. การแมปข้อมูลเมตาที่อยู่ลึกลงไปใน CLR ถือเป็นความช่วยเหลืออย่างมาก (ขอบคุณสำหรับการโพสต์ Paul) เหนือ COM Interop ก่อนหน้า สิ่งที่ฉันต้องดำเนินการคือแนวทางปฏิบัติเก่า ๆ บางอย่าง (VSTO ฯลฯ ) ในการทำให้แน่ใจว่าคุณมีการอ้างอิงที่ชัดเจนเกี่ยวกับ RCW แต่ละรายการนั้นยังคงเล่นอยู่หรือไม่ ดังนั้นคุณจะไม่จบลงด้วย RCW ที่อ้างอิงวัตถุ COM และคุณสามารถทำได้ อย่าทำให้อันใดอันหนึ่งหมดความทรงจำ   -  person Alexander Hunter    schedule 05.10.2011

คำตอบ (3)


arrow_upward
1
arrow_downward

ฉันได้สร้างแอปที่สมบูรณ์สองแอปบนหน้าตัวอย่างสำหรับนักพัฒนาซอฟต์แวร์ใน C#/XAML วัตถุ WinRT ให้ความรู้สึกเหมือนกับวัตถุ C# ทั่วไป ไม่จำเป็นต้องมีการสรุปผลหรือการทำงานร่วมกันของ .NET/COM แบบดั้งเดิมอื่นๆ การคาดการณ์ถึง .NET ทำให้ WinRT API ค่อนข้างราบรื่น

มีบางพื้นที่ที่ COM รั่วไหลผ่าน

  • ข้อยกเว้นที่เกิดขึ้นจากวัตถุ WinRT ไม่มีการติดตามสแต็ก
  • ข้อยกเว้นส่วนใหญ่ที่เกิดขึ้นจากวัตถุ WinRT มีประเภทข้อยกเว้นทั่วไปและมีรหัสข้อผิดพลาด HRESULT

ฉันคาดว่าปัญหาเหล่านี้จะได้รับการแก้ไขใน Windows 8 รุ่นต่อๆ ไป

นอกจากนี้ยังมีความซ้ำซ้อนบางอย่างในขณะนี้ซึ่งมีการกำหนดประเภทที่คล้ายกันทั้งใน WinRT และ .NET (IObservableVector และ INotifyCollectionChanged)

person Robert Sweeney    schedule 22.02.2012

arrow_upward
0
arrow_downward

[นอกเหนือจากคำตอบของ Robert Sweeney]

ตาม โพสต์ในบล็อก:

.NET API ไม่ได้ถูกเปิดเผยผ่าน WinRT แต่ยังคงทำงานต่อไปตามปกติ ซึ่งถูกเปิดเผยโดย CLR

นอกจากนี้มันบอกว่า:

นักพัฒนา .NET ไม่ใช่คนแปลกหน้าในการทำงานร่วมกันของเทคโนโลยี คุณสามารถใช้ทั้ง COM Interop และ P/inrigg เพื่อเรียกใช้ API ดั้งเดิมจากโค้ด .NET

person Annie    schedule 27.11.2012

arrow_upward
-1
arrow_downward

การทำงานร่วมกันของ COM ไม่สามารถใช้ได้กับ WinRT จริงๆ เนื่องจาก WinRT ข้ามสถาปัตยกรรม Win32 โดยสิ้นเชิง (นั่นคือมีอยู่เคียงข้างกัน) เนื่องจาก COM อยู่เหนือ Win32 จึงเป็นข้อตกลงที่แยกจากกันโดยสิ้นเชิงในบริบทของ WinRT

แก้ไข: ขออภัย - ฉันผิดที่นี่ WinRT เข้าใจผิดโดยสิ้นเชิง! โปรดดูความคิดเห็นของ svick ด้านล่าง

person Polynomial    schedule 04.10.2011
comment
ไม่จริง ประเภท WinRT เป็นเพียงประเภท COM ที่ใช้ IInspectable อินเทอร์เฟซ - person svick; 05.10.2011
comment
ตามที่ฉันเข้าใจ WinRT ได้รับการนำไปใช้กับ Win32 จริงๆ และประเภท WinRT เป็นเพียง COM พร้อมข้อมูลเมตา - person Gabe; 05.10.2011
comment
@svick - ถูกต้องอย่างแน่นอน ฉันเข้าใจผิดโดยสิ้นเชิงว่า WinRT ทำงานอย่างไร ขออภัยสำหรับข้อมูลที่ผิดของฉัน แก้ไขข้อความเพื่อกล่าวถึงเรื่องนี้ - person Polynomial; 05.10.2011