In Windows Phone 7, you will typically define your UI in XAML and write the code in C#. If you’re an advanced XAML coder, you might want to harness the power XAML bindings to limit the amount of code you’ll have to write, and define as much as possible in XAML. If you’re a game developer, you might opt for the XNA framework, in that case you UI will be written from scratch. In any case, regardless of the UI framework you decide to use, your business logic will be coded in C#.
The reason why C# is required comes from the constraint that in WP7, your application is confined run on top of the CLR (Common Language Runtime). The CLR concept is very similar to a Java virtual machine : the code is converted to an intermediary language that the virtual machine will execute. The CLR environment is commonly called the “managed” mode. The managed mode comes with many great advantages, most notably garbage collection and reflection. C# is a managed language.
That changed in Windows Phone 8! In addition to the managed framework, developers can write in “native” code. Native code, in comparison with managed code, does not run on top of a virtual machine, but is compiled directly into machine code. As you might expect, native code typically execute slightly faster than managed code. On WP8, native code is written in C or C++.
It is possible to glue pieces of native code with pieces of managed code, thanks to the Windows Phone Runtime framework. The framework takes care of the magic required to convert objects across managed and native runtimes. This Nokia developer wiki gives a quick tutorial how to get started with the Windows Phone Runtime, while this article C++ support from Windows Phone 8 goes into deeper details.
There are some limitations how one passes objects back and forth between managed and native runtimes, and while the “Windows Phone Runtime Component” code template shipping with Visual Studio provides all the necessarily plumbing to call a Native object from a Managed object, it may not be that obvious how to call a managed object from a Native object. For example, when a developer needs to call from C++ the functionality only provided by .NET, like modifying live tiles, send a SMS, … The same wiki article provides a solution for such a scenario.
Of course, it’s not because you can that you should! Stick with C#, unless you really need that little extra speed improvement. Or if you have a C++ library that does a great job and just do not want to convert it to C#: that would be such a waste of your time.