4

Just curious if anyone has had sufficient time with WinRT yet to understand whether there are areas in WinRT and .NET 4.5 that efface to the .NET programmer some of the old items encountered in VSTO and COM Interop Office programming pertaining to RCWs and the differences in the COM reference counting and .NET GC beyond not using finalizer (making sure you get a reference to all .NET RCWs, etc).

Not a big deal just curious if they abstracted away those considerations or better yet the architecture is materially different and these concerns are not even applicable.

Thanks in advance

Maybe a better way of asking the question is whether it still is materially the same architecture of .NET Objects in a managed/garbage collected memory model referencing COM (WinRT) objects in an unmanaged (yet sandboxed) reference counting memory architecture?

Unless there is some "magic" in the meta data bindings or the sandboxed environment, then we will just need to apply the same approach we had with RCWs.

Alexander Hunter
  • 89
  • 6
  • Everything I've heard and seen so far still point to RCWs and business as usual. If there have been any changes in CLR 4.5 or any changes planned then it is a well kept secret. http://stackoverflow.com/questions/7457371/why-is-winrt-unmanaged/7457964#7457964 Nothing in the recent interview with Vance Morrison either http://channel9.msdn.com/posts/NET-45-Vance-Morrison-Performance-and-Memory-Usage-Improvements – Hans Passant Oct 04 '11 at 23:19
  • I just found a comment on separate post "While the thunking layer does use RCWs, the RCWs for the windows runtime are more lightweight than the old P/Invoke RCWs. – Larry Osterman Sep 15 at 14:02". The meta data mapping deep in the CLR is a big help (thx for postings Paul) over prior COM Interop. What I need to bang on is whether some of the old practices (VSTO, etc) of making sure you have an explicit reference to each RCW are still in play so you don't end up with a RCW referencing a COM object and you can't get either one of them out of memory. – Alexander Hunter Oct 05 '11 at 16:10

3 Answers3

1

I've built two complete apps on the developer preview in C#/XAML. The WinRT objects feel just like regular C# objects. No need for finalizers or other traditional .NET/COM interop stuff. The projections to .NET make the WinRT API pretty seamless.

There are some areas where COM leaks through.

  • Exceptions thrown by WinRT objects have no stack trace
  • The majority of the exceptions thrown by WinRT objects have a generic exception type and include an HRESULT error code.

I expect these issues will get resolved in future builds of Windows 8.

There are also some redundancies now where similar types are defined in both WinRT and .NET (IObservableVector and INotifyCollectionChanged)

Robert Sweeney
  • 186
  • 1
  • 6
0

[An addition to Robert Sweeney's answer]

According to .NET framework's official blog post:

The .NET APIs are not exposed via WinRT, but continue to work as they always have, exposed by the CLR.

Further it says:

.NET developers are not strangers to interop technologies. You can use both COM Interop and P/invoke to call into native APIs from .NET code.

Community
  • 1
  • 1
Annie
  • 3,090
  • 9
  • 36
  • 74
-1

COM interop isn't really applicable in WinRT, because WinRT entirely bypasses the Win32 architecture (i.e. they exist side-by-side). Since COM sits on top of Win32, it's a completely separate deal in the context of WinRT.

Edit: Sorry - I'm wrong here. Totally misunderstood WinRT! Please see svick's comment below.

Polynomial
  • 27,674
  • 12
  • 80
  • 107
  • 5
    Not really, WinRT types are basically just COM types that implement the [`IInspectable` interface](http://msdn.microsoft.com/en-us/library/br205821%28v=vs.85%29.aspx). – svick Oct 04 '11 at 23:03
  • As I understand it, WinRT is really implemented with Win32 and WinRT types are just COM with metadata. – Gabe Oct 05 '11 at 01:43
  • @svick - Absolutely correct, I totally misunderstood how WinRT worked. Apologies for my misinformation. Edited the post to mention this. – Polynomial Oct 05 '11 at 05:48