.NET Programmers In Demand, Despite MS Moves To Metro

mikejuk writes "Are you a newbie programmer looking for a job? It seems your best bet is to opt for .NET. According to technical jobs website Dice.com, companies in the U.S. have posted more than 10,000 positions requesting .NET experience — a 25 percent increase compared to last year's .NET job count. So Microsoft may want us to move on to Metro but the rest of the world seems to want to stay with .NET."

Comments

Metro isnt a replacement for .NET

[Anonymous Coward]

Metro is merely a new style of app interface that can be written using .NET, not a replacement for it.

Quite crappy headline

[giuseppemag]

Metro is a UI on top of Windows 8.

WinRT is the new Windows 8 runtime, which will be accessible by C++, C# and any .Net language. The .Net standard libraries will be available for Windows 8 Desktop applications but not for Metro applications, which will be written targeting WinRT.

So, the summary is wrong because:
a) Metro is not a development framework
b) .Net-related skills remain central in Windows 8 even when targeting Metro

Re:Quite crappy headline

[westlake]

WinRT is the new Windows 8 runtime, which will be accessible by C++, C# and any .Net language.

WinRT demystified [Miguel de Icaza]

WinRT is a new set of APIs that have the following properties:

It implements the new Metro look.
Has a simple UI programming model for Windows developers (You do not need to learn Win32, what an HDC, WndProc or LPARAM is).
It exposes the WPF/Silverlight XAML UI model to developers.
The APIs are all designed to be asynchronous.
It is a sandboxed API, designed for creating self-contained, AppStore-ready applications. You wont get everything you want to create for example Backup Software or Hard Disk Partitioning software.
WinRT wraps both the new UI system as well as old Win32 APIs and it happens that this implementation is based on top of COM.

Some developers are confused as to whether .NET is there or not in the first place, as not all of the .NET APIs are present (File I/O, Sockets), many were moved and others were introduced to integrate with WinRT.

When you use C# and VB, you are using the full .NET framework. But they have chosen to expose a smaller subset of the API to developers to push the new vision for Windows 8.

And this new vision includes safety/sandboxed systems and asynchronous programming. This is why you do not get direct file system access or socket access and why synchronous APIs that you were used to consuming are not exposed.

Now, you notice that I said "exposed" and not "gone".

What they did was that they only exposed to the compiler a set of APIs when you target the Metro profile.

You might be thinking that you can use some trick (referencing the GAC library instead of the compiler reference or using reflection to get to private APIs, or P/Invoking into Win32). But all of those uses will be caught by AppStore review application and you wont be able to publish your app through Microsoft's store.

You can still do whatever ugly hack you please on your system. It just wont be possible to publish that through the AppStore.

Re:Confused

[Tacvek]

I as understand it WinRT replaces COM.

WinRT consists of several parts.
The first such part is a replacement for COM, heavilly inspired by managed code. Indeed the restrictions on the exported interface are explicitly designed such that objects remain easy to call from managed code. It also lifts some idiotic restrictions that COM had. The interfaces are now described using CLI metadata in the form of a WinRT file. Despite being heavily inspired b y managed code, this is still all native code, and does not require a garbage collector.

The second part of WinRT is a set of APIs that replace many Win32 Apis, exported using this new COM replacement. These APIs are also inspired by managed code, especially the naming and namespacing conventions. The APIs are not particularly low level, but are actually rather similar to many of the APIs in the .Net Framework. For example, consider the 'Windows.Data.Json' namespace. That hardly seems low level. Or how about 'Windows.Data.Xml.Dom' which is very roughly a ported version of the .NET 'System.Xml' namespace?

When writing .NET metro style apps in C#, the Full .Net framework is actually available, although only a portion of it is exposed by default, because the app store will reject Metro-style apps that use APIs not exposed by default, because those APIs can be used to escape the Metro Sandbox. (This is much like how metro-style C++ code could call any win32 API, even those not exposed by default, but that will cause the application to be rejected from the app store).

Re:Confused

[BitZtream]

Sigh ... please tell me you don't tell people you know the .NET framework.

What makes WinRT a royal pain is that it is low level C++ API. Thus C# becomes a second rate citizen and C++ a first rate citizen and it uses COM technologies.

The Windowing and other GUI apis have ALWAYS been low level C (not C++) APIs, and likely always will be. Windows.Forms was built on top of that. I'm not real sure how you can say that C# is a second class citizen or a first class citizen, it is neither and both. .NET Libraries care not what language they are being used by, sure the API may not feel as natural in one language over the other, but thats not anything new and will always be there.

Its rather retarded to think that any API other than the one at the lowest level is going to be the one that is most natural. Its all implemented in C at the low level, regardless of what lazy language you throw on top of it.

Never thought that would happen in that COM is brought back to life.

Then you have absolutely no idea how the .NET framework is built. .NET Assemblies are extensions to ActiveX, which are ... extensions to COM objects ... which are extensions of OLE2 objects. In fact, every .NET framework assembly is a OLE2 object, as is every ActiveX and COM object, each one just a different set of interface requirements on top of the previous.

It is what it is and personally I think WinRT will fail overall because it means you are completely beholden to the Windows platform!

You mean like Windows.Forms is beholden to the Windows platform? So I guess you're saying it would be absolutely impossible for someone to write a clean implementation of it or a wrapper around Qt or GTK to do the same? Thats odd, why do you seem to think what can be done for the Windows.Forms namespace can't be done again, why do you think thats the case?

I'm fairly certain you have absolutely no idea how the .NET framework works. You have heard of Mono haven't you?