locked
WinRT does not support struct member functions?

    Question

  • From the "Guidelines to port existing XAML code to Metro style code" (http://msdn.microsoft.com/en-us/library/windows/apps/br229571%28v=VS.85%29.aspx):

    "Also WinRT does not support struct member functions so we've created some *Helper types to help app authors port existing code."

    Checking up a random struct defined in WinRT, namely PointerDeviceUsage (http://msdn.microsoft.com/en-us/library/windows/apps/windows.devices.input.pointerdeviceusage%28v=VS.85%29.aspx), I find that there are indeed no methods whatsoever and all data is exposed as public mutable (?) instance fields!

    But those fields are typed as standard numeric types such as System.Int32 which do have methods, and of course C#/VB have built-in type identifiers (int etc.) that are supposed to be synonymous with such standard types as well.

    So how does that work?  Does WinRT only support member functions on certain privileged system-defined value types?  Do we have to reimplement our own struct member functions as extension methods?  What if our structs rely on a particular Equals behavior, will that get routed correctly?

    Wednesday, September 14, 2011 11:22 AM

Answers

  • Here's the response from a CLR developer:

    The Windows Runtime does not support specifying members on structs\value types however .NET projects some Windows Runtime types to a more .NET Friendly type and these .NET types can have members. For example the Windows Runtime defines a new type for representing Dates and Times(Windows.Foundation.DateTime) however .NET already has a type for this System.DateTimeOffset and we want developers to be able to leverage their experience and existing code that works with DateTimeOffset so we convert to and from Windows.Foundation.DateTime that doesn’t have any members to System.DateTimeOffest that does have members.

    If you are defining a Widnows Runtime struct from C#/VB it cannot have any members and it is not possible to override Equals, GetHashCode, ToString. For Equals you will get the default .NET value type equals behavior described http://msdn.microsoft.com/en-us/library/2dts52z7.aspx.

     

    • Marked as answer by Christoph Nahr Thursday, September 15, 2011 5:50 AM
    Wednesday, September 14, 2011 7:44 PM
    Moderator

All replies

  • The core primitive structures have members because we are projecting the WinRT versions to the .NET versions (i.e. Windows.Foundation.Int => System.Int) for managed developers.   I'm currently trying to get more detail from the WinRT projection developers but they are currently at build so it may not be until next week until that happens.

    Wednesday, September 14, 2011 4:51 PM
    Moderator
  • Thanks, Carlos.  More details on this subject would be very welcome.  Being unable to use any user-defined struct methods would quite significantly increase the workload of porting existing .NET apps to Metro, compared to the simple namespace swap shown at Build, so I'm rather concerned about this limitation.  I'd greatly appreciate if it could be removed entirely for WinRT final.
    Wednesday, September 14, 2011 4:59 PM
  • Here's the response from a CLR developer:

    The Windows Runtime does not support specifying members on structs\value types however .NET projects some Windows Runtime types to a more .NET Friendly type and these .NET types can have members. For example the Windows Runtime defines a new type for representing Dates and Times(Windows.Foundation.DateTime) however .NET already has a type for this System.DateTimeOffset and we want developers to be able to leverage their experience and existing code that works with DateTimeOffset so we convert to and from Windows.Foundation.DateTime that doesn’t have any members to System.DateTimeOffest that does have members.

    If you are defining a Widnows Runtime struct from C#/VB it cannot have any members and it is not possible to override Equals, GetHashCode, ToString. For Equals you will get the default .NET value type equals behavior described http://msdn.microsoft.com/en-us/library/2dts52z7.aspx.

     

    • Marked as answer by Christoph Nahr Thursday, September 15, 2011 5:50 AM
    Wednesday, September 14, 2011 7:44 PM
    Moderator
  • Thanks.  All I can say is... wow.  So porting existing .NET applications of any complexity to Metro is going to require a total rewrite, even for non-UI program logic.

     

    EDIT!  Just finished watching the Build session on this subject, and it seems I somewhat misunderstood the situation:

    http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-531T

    So while the public field restriction for structs is in place when exporting structs in WinRT libraries, you can apparently still define regular .NET assemblies that are only used by your own code.  In that case, all user-defined types in these assemblies are running on the CLR as usual, so the restrictions for WinRT types do not apply.

    I think that should be clarified in the documentation, as it specifically talks about "porting existing code to Metro" which led me to assume to any simple recompilation of .NET code for Metro would run into these restrictions.

    Thursday, September 15, 2011 5:56 AM