But, a good part of the point of .Net was that the managed code was in MSIL and being compiled to X86 down the line rather than by the developer, so the argument that ARM support requires a move from .Net really doesn't hold water.
I'm hoping there's more to this than meets the eye, but... Here's a test case for you. VB6 apps are supposed to be going out of support relatively soon, but there's a lot of them still out in the wild. The understanding had been to redevelop them in .Net, but based on this exactly what should the authors commit their investment to? Frankly if this doesn't get cleared up soon, for me the answer would be 'anything but Microsoft's stack' - it's just too unpredictable.
> "the argument that ARM support requires a move from .Net really doesn't hold water."
I would draw a thick, dark line between managed .Net and "legacy". When people talk about legacy Windows code, they're talking about those massive enterprise apps running front ends written in VB6/MFC-era code. Those are the ones that Microsoft has to push to the curb in Win8 [1].
That said, any number of .Net tricks to enable legacy behaviors will likely pose roadblocks for particular apps. So some .Net incompatibility will be at issue as well.
> "but based on this exactly what should the authors commit their investment to"
I'd imagine the question Microsoft is grappling with, is which versions and parts of .Net they can reasonably support. Though I'd be surprised if anything they recommended in the last five or so years that wasn't supported.
That said, anyone designing an enterprise replacement in the last five years, who did so as anything other than a web app is likely out of their gourd [2].
[1] i.e. live on in an XP-mode style ghetto only on Win8x86
[2] Sure, some of have some steep client requirements that rule out web apps. But that's a tiny minority amongst enterprise apps. The overwhelming majority are workflow/database interfaces.
Frankly if this doesn't get cleared up soon, for me the answer would be 'anything but Microsoft's stack' - it's just too unpredictable.
Don't get carried away. MS has been very clear that you can run any Windows app here. If you're porting over old VB6 apps it seems clear that porting to VB.NET makes the most sense. .NET development isn't going away as at the very least MS's web server-side story is still all .NET.
Yeah, that's what is confusing to me about any .NET developer employment angst. ASP.NET and other business infrastructure technology seem unaffected by desktop software innovation. I have to believe that desktop software is a small piece of all .NET development and innovation in this area shouldn't threaten the platform.
I'm hoping there's more to this than meets the eye, but... Here's a test case for you. VB6 apps are supposed to be going out of support relatively soon, but there's a lot of them still out in the wild. The understanding had been to redevelop them in .Net, but based on this exactly what should the authors commit their investment to? Frankly if this doesn't get cleared up soon, for me the answer would be 'anything but Microsoft's stack' - it's just too unpredictable.