Description

C#, Visual Basic and the .NET tools have first-class support for the Windows Runtime. Learn about this integration and how to use C# and Visual Basic to write Metro style apps that call the Windows Runtime and how to build libraries that integrate with your Metro style apps using HTML.

For more information, check out these courses on Microsoft Virtual Academy:

If I'm not mistaken, it's been said in the directx and direct3d sessions that directx is not currently exposed to C# through winrt, so the only way to access it is through native C++ code. I'm sure there is a good reason for that (performance), but even given those reasons, shouldn't WinRT have some subset of DirectX exposed through WinRT metadata to C#/VB/JavaScript? As it stands, the only way to create a 3D or non-trivial 2D game using C# is by writing your own abstraction layer in native code and P/Invoking it (or creating a native WinRT component). Xna's availability on Windows Phone has been a major component in the explosion of games on that platform, and I think even C++ developers would benefit from a higher-level abstraction layer than raw DirectX api calls, even if that layer is not Xna specifically.

Testing out the new Windows Runtime system. I am having an issue creating winMD components containing PropertyChanged event handlers. I keep getting a System.TypeLoadException when "public event PropertyChangedEventHandler PropertyChanged;"is placed within a sealed C# class. Am I missing something? Will it be possible to expose the INotifyPropertyChanged interface in the Windows Runtime Components?

cbae: of course you can. that's the whole point, once a winrt class is written in C++ or C# or VB, it can be consumed by all 3 languages plus Javascript. The only restriction looks to be, that you cannot build winrt classes in Javascript, only consume them.

@Ralf Hoffmann:If you're only targeting managed apps w/ your library, you can continue to build DLLs the way you always have. If you want to project to JS and C++, you have to build WInRT components. When crossing language boundaries, you do have to be mindful of marshaling costs - even for managed code accessing managed WinRT components.

The samples provided seem to assume that the person that is creating a WinRT extension has access to the implementation. If a 3rd party supplier provides algorithms, etc that I can only get as a DLL implementation that do not break WinRT extension rules, then I would expect to be able to use it. Right?

@SteveK, I just double checked w/ the CLR team on your question. Yes you can build a managed WinRT component that uses p/invoke to access Win32 APIs that are allowable from Metro style apps. The .NET profile for Metro style apps includes DllImporet, MarshalAs, etc.

as for your 3rd party supplier, so long as that DLL works w/ the Metro .NET profile, then yes your scenario will work. Only the public surface area of your component has to conform to the WinRT type system. Other assemblies you reference aren't part of that surface area by default.

I would think that is a common scenario - build a managed DLL component as a portable assemblies that can be used in Windows, Windows Phone, maybe even Xbox and then build a WinRT wrapper around it so the component is available to JS and C++ as well.

Where is the source code? As I was typing this up in Dev11, the await keyword is problematic (complaining that it can only be used when its containing method or lambda expression is marked with the async modifier), I'm not sure if Photo is a control on the Xaml page, and the file object does not contain a method for opening a file asynchronously.