locked
C# versioning in WinRT/Metro vs .NET RRS feed

  • Question

  • How is MS approaching the versioning of C# (or VB) in .NET and WinRT?  Will the latest and greatest C# always be in sync across .NET and WinRT? 
    Wednesday, September 14, 2011 4:02 PM

Answers

  • You might want to come to my talk at 2pm today, and then the C# talk at 3.30 to get more clarity on these.

    C# code using the WinRT still runs on the 4.5 CLR. When you write a Metro style app in C#, you have a CLR loaded in your process, and you have access to a subset of managed APIs chosen specifically for use with Metro style applications.

    WinRT is a protocol and a set of Native APIs, allowing each language to remain true to its existing execution environment - Chakra for JavaScript, CLR for C# and the CRT/raw native code for C++.

    Martyn Lovell
    Development Manager
    Windows Developer Experience

    • Marked as answer by ZeroBugBounce Wednesday, September 14, 2011 7:03 PM
    Wednesday, September 14, 2011 7:00 PM
  • From my understanding, yes, when you write an app in C#, it will run under the .NET, but you will have access to the WinRT functions through some wrappers which are provided by Microsoft; and actually, they are automatically generated, so they will grow in sync with the native API they represent.
    • Marked as answer by ZeroBugBounce Wednesday, September 14, 2011 7:03 PM
    Wednesday, September 14, 2011 6:31 PM

All replies

  • The C# classes which represents WinRT seems to be autogenerated, so I would expect that they will be kept synced with the current API.
    Wednesday, September 14, 2011 4:38 PM
  • That's interesting... in what way do they seem to be autogenerated?  Sounds reasonable that they would be in sync, I'm just wondering what you see that brings you to that conclusion?
    Wednesday, September 14, 2011 4:45 PM
  • @ZeroBugBounce: Can you expand on your question a little bit? Are you asking how the CLR itself will be versioned, how C# code you write yourself will be versioned, or how the WinRT projection in C# will version?

    @MCCZ is right about the way the projection of the WinRT works. The WinRT and CLR work together to expose the Windows functionality directly. This means that if you run a Metro style app on a future version of Windows, WinRT objects from that version will be exposed into your app.

    Martyn Lovell
    Development Manager
    Windows Runtime Experience

    Wednesday, September 14, 2011 5:10 PM
  • Hi Martyn, I may be assuming some things in my question based on what I saw in the presentations.

    My assumption was that WinRT would support C# natively (or some compiler would compile C# to native WinRT bytecode) and that the C# used in Metro apps would NOT be running under a CLR or .NET, but I think you are saying that's not the case maybe? So are you saying that when you write C# for a Metro/WinRT app, it will in fact be running on .NET (4.5 or some WinRT subset, like Windows Phone 7)?

    Wednesday, September 14, 2011 6:29 PM
  • From my understanding, yes, when you write an app in C#, it will run under the .NET, but you will have access to the WinRT functions through some wrappers which are provided by Microsoft; and actually, they are automatically generated, so they will grow in sync with the native API they represent.
    • Marked as answer by ZeroBugBounce Wednesday, September 14, 2011 7:03 PM
    Wednesday, September 14, 2011 6:31 PM
  • You might want to come to my talk at 2pm today, and then the C# talk at 3.30 to get more clarity on these.

    C# code using the WinRT still runs on the 4.5 CLR. When you write a Metro style app in C#, you have a CLR loaded in your process, and you have access to a subset of managed APIs chosen specifically for use with Metro style applications.

    WinRT is a protocol and a set of Native APIs, allowing each language to remain true to its existing execution environment - Chakra for JavaScript, CLR for C# and the CRT/raw native code for C++.

    Martyn Lovell
    Development Manager
    Windows Developer Experience

    • Marked as answer by ZeroBugBounce Wednesday, September 14, 2011 7:03 PM
    Wednesday, September 14, 2011 7:00 PM
  • Thanks to you both.  Were I at BUILD I would come to your talk, but I'll have to settle for viewing the session videos a little later on, if available, which I will certainly do.

     

    Cheers,

    Richard

    Wednesday, September 14, 2011 7:04 PM
  • The session videos will be available pretty soon after the event.

    Martyn

    Wednesday, September 14, 2011 7:17 PM
  • Is it possible to incorporate WinRT API into Desktop Applications(Non Metro/Aero Styled) developed using .Net or Win32?
    Thursday, September 15, 2011 7:41 AM
  • No, MS seems very clear on the two worlds (Metro & WinRT vs. legacy Win32) being very separate and distinct. 
    Thursday, September 15, 2011 3:03 PM
  • If not atleast they should provide some wrappers or any other API's to use metro ui components,animation elements in .Net and Win32...

     


    • Edited by nsathya10 Thursday, September 15, 2011 3:25 PM
    Thursday, September 15, 2011 3:19 PM
  • It does not looks like WinRT generates any wrapper. In documentation I saw that the assemblies are already present for WinRT.

    For example http://msdn.microsoft.com/en-us/library/windows/apps/windows.storage.storagefile

    There is an existing assembly called Windows.Storage.dll (Scroll down the page to see the details)

    So, it looks like the required assembly is already present to act like an intermediate wrapper in windows 8 to avoid any dynamic wrapper generation.

    In short, your C# compiled managed code will use this dll (assembly) to communicate with the native windows 8 without generating any intermediate wrapper.


    Kajal Sinha
    Friday, September 23, 2011 9:56 AM
  • Kajal is right. Only minor correction: Windows.Storage.dll is native implementation of the interfaces. The assembly with MetaData describing the types in it is Windows.Storage.winmd and is stored in %WINDIR%\system32\WinMetadata directory. If you run ildasm on the .winmd file, you will see classes as .NET sees them.

    -Karel

    Friday, September 23, 2011 4:05 PM
    Moderator