I don't see how: it always goes via MSIL and Mono runs MSIL. Admittedly, apps or libraries published solely as "native" binaries won't run on Mono, but I strongly suspect that those are typically native end-user apps which are very often Windows-specific already. Windows Store stuff, and similar.
(I also strongly suspect that this entire "native" move was fueled purely by that top-of-the-bill Windows 8 computers take 5 seconds to start up the damn Weather app)
On the library side, there's a strong move towards the opposite, actually: you can now make a (MSIL) DLL that runs on Windows, Windows Phone, iPhone, Android, Mono, etc etc without having do distribute different versions (basically, what Java always had) of the binary. It's overdue, but it's really nice.
I'm not worried (and I run a dev team that runs a C# backend on mono/linux).
I also strongly suspect that this entire "native" move was fueled purely by that top-of-the-bill Windows 8 computers take 5 seconds to start up the damn Weather app
Bingo. Especially on 64-bit machines, the time it takes for apps to launch can be downright embarrassing.
If you fully understand Microsoft's portfolio it makes more sense.
Desktop Windows 8 is a scenario, but not a very good representative. While
64-bit JIT time can take a while and CLR startup time can be really long, both
of these things can be addressed in a variety of ways in vanilla Windows
machines, ranging from NGen improvements to CLR pre-loading strategies.
The real killer is alternate platforms. Every time you JIT in a mobile device it
wastes time, CPU power, and battery life, all of which are much more limited
than in a desktop machine. CLR startup can be mitigated somewhat, but resident
memory is an especially precious commodity on mobile.
The last real kicker is that security concerns mean that many platforms (XBox)
mark a lot of their pages as NX, making JIT-ing in these pages very difficult or
impossible. Moreover, better security infrastructure means doing this on more
platforms more of the time, so this will become increasingly problematic.
All together, this makes a very compelling case for AOT compilation.
The Weather App, as I understand it, is built by the Bing team, who use WinJS (javascript) for their apps. This native compiler backend is for .NET, so they wont benefit from this at all.
(I also strongly suspect that this entire "native" move was fueled purely by that top-of-the-bill Windows 8 computers take 5 seconds to start up the damn Weather app)
On the library side, there's a strong move towards the opposite, actually: you can now make a (MSIL) DLL that runs on Windows, Windows Phone, iPhone, Android, Mono, etc etc without having do distribute different versions (basically, what Java always had) of the binary. It's overdue, but it's really nice.
I'm not worried (and I run a dev team that runs a C# backend on mono/linux).