Slashdot Mirror

← Back to Stories (view on slashdot.org)

.NET Programmers In Demand, Despite MS Moves To Metro

Posted by timothy on from the lagging-indicator dept.

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."

28 of 319 comments (clear)

  1. Confused by sourcerror · · Score: 5, Insightful

    Isn't Metro just a different GUI library on top of .Net?

    1. Re:Confused by SerpentMage · · Score: 4, Informative

      Here is Miguel on the topic and I think he does a great job of explaining it...

      http://tirania.org/blog/archive/2011/Sep-15.html

      --

      "You can't make a race horse of a pig"
      "No," said Samuel, "but you can make very fast pig"
    2. Re:Confused by SpryGuy · · Score: 4, Insightful

      That is factually untrue.

      "Microsoft demoed creating new WinRT components on both C++ and .NET."

      http://tirania.org/blog/archive/2011/Sep-15.html

      --

      - Spryguy
      There are three kinds of people in this world: those that can count and those that can't
    3. Re:Confused by derGoldstein · · Score: 4, Interesting

      It's this type of attitude that separates programmers into idiotic "camps". I'm not talking about MS behaving weirdly and making nonsensical decisions -- that's a given. I mean making it sound like C# is oceans apart from modern C++. When you're programming in C++ and STL (along with some Boost, as required), most programs are going to be almost identical in structure. I know this because I've had to port code back and forth from C# to ANSI C++, and apart from some specific, easy-to-isolate areas (like interfacing with the GUI), the structure of the programs remains the same. You should be separating the code that talks with the GUI no matter what language you use, unless your program is heavily intertwined with the GUI (like graphics programs or visualizers).

      You should be comfortable using both languages. If you're coming from C# to C++, then check out Accelerated C++, and (some time later) follow that up with this advice.

      This isn't like moving from C# to C, it's much closer. Also, you should aim to be a Programmer, rather than a (C++ || Java || C# || Python) Programmer. It'll make your life easier and make you better at your job.

      --
      Entomologically speaking, the spider is not a bug, it's a feature.
    4. Re:Confused by Tacvek · · Score: 5, Informative

      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).

      --
      Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
    5. Re:Confused by PhrostyMcByte · · Score: 3, Interesting

      WinRT doesn't replace .NET or the Win32 API, nor is it a second-class citizen when used from C#.

      Metro apps are intended to be small—about the size of a cell phone app. They aren't made to replace full desktop apps meant to get work done. The .NET APIs you get for Metro apps have been scrubbed, getting rid of "insecure" APIs as well as ones that WinRT made redundant. A lot of the .NET API you've become used to is still available, though.

      It uses COM behind the scenes, but there's no hint of COM in the API -- in fact, people in the Mono project have already begun work on a purely managed WinRT implementation. It definitely doesn't feel like a second-class citizen while using it. I'll be curious to see how much overhead it introduces.

      WinRT in C++ is a little weird. There are two ways to use it: WinRTL, which is written in standard C++ but has all the verbosity of COM, or C++/CX, some extensions to C++ that make using it a breeze if you don't care about portability. It doesn't replace the Win32 API either. They encourage you to use WinRT when possible, but the entire Win32 API is still available. It's not clear if they'll be filtering the APIs you're allowed to use during the review process.

      The biggest problem with Metro apps is that you can't just distribute an exe—all distribution needs to go through the Windows app store, complete with $100/year fees and review process. I'm sure a hack will come out, but this might make life a bit more difficult for many hobby developers trying to reach the common user.

    6. Re:Confused by Coolhand2120 · · Score: 3

      Please read the comments as well as the mia copa at the top of the link you provided.

      http://blog.expensify.com/2011/03/25/ceo-friday-why-we-dont-hire-net-programmers/

      That you think .NET devs are script kiddies speaks volumes about you. I'm curious - what IDE do you think .NET developers should be using? The only thing that VS does for a .NET dev is run the command line for CLI when they click 'build'. Learning how to use CLI to compile from the command line takes 5 minutes to figure out, so there's that hurdle. What other "magic" is VS doing that makes .NET devs so stupid/lazy? Refactoring? Intelesence? Just because you're too ignorant to understand what an IDE is and what the .NET framework is doesn't mean can (without looking like a fool) go around and bash .NET. That you think that .NET devs are script kiddies makes me think that you don't know what .NET is or what a script kiddie is. I'll give you a hint: Script kiddies don't know how to write code - that's what makes them a script kidde.

      But really, I think you've made your little story up there. Please give me the scenario where you would "take a .NET developer out of Visual Studio". Because it sounds a too me like you're fibbing.

    7. Re:Confused by BitZtream · · Score: 5, Informative

      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?

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    8. Re:Confused by shutdown+-p+now · · Score: 3, Informative

      The Windowing and other GUI apis have ALWAYS been low level C (not C++) APIs, and likely always will be.

      The whole point of WinRT is to change that, actually. It's no longer low-level C. It's an object-oriented API from ground up using a framework that's deliberately designed to be consumable from different languages (GC or no GC, static or dynamic typed... there are a lot of considerations there).

      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.

      You are absolutely wrong here. .NET assemblies are not extensions to ActiveX. It doesn't even make sense, because an "ActiveX object" is a COM component with a visual UI. Nor are they COM objects. You can take a .NET class and make it visible to COM as a COM object, but it has to be explicitly done, limits what you can do with such a class, and is implemented via a separate bridge (COM Interop).

      Heck, .NET classes don't implement IUnknown (the most basic requirement for a COM object).

    9. Re:Confused by Eskarel · · Score: 3, Informative

      Except that's not what they're doing, they're un-deprecating C++, not deprecating C#.

      Microsoft seems finally to have come to the conclusion that anyone with a lick of sense could have told them a decade ago. Some things work really well in managed code, some things don't. A large part of Microsoft's product suite has been migrated to .NET, but for reasons anyone with half a brain could tell you, not everything should be written that way. At the absolute least, you need to write enough code to run .NET(or any managed code) in an non managed language because unlike C++, managed code cannot run itself. In addition to that sort of stuff there's plenty of things which could be written in .NET, but for which doing so wouldn't make any real sense.

      At present there are certain things in the Windows OS which are a huge pain to do in C++ since Microsoft has essentially replaced MFC with .NET, so you end up mixing in C# code where it really doesn't make any sense. Microsoft are rectifying this and allowing C++ to be an equal player, they're not getting rid of .NET, they are continuing to build their own software in .NET(where it makes sense), they're just allowing C++ programmers to play too.

    10. Re:Confused by spongman · · Score: 3, Informative

      AFAIK, it's not a replacement of COM, as such. more like a set of enhancements to COM:

      - it's still based on IUnknown
      - instead of CoCreateInstance, HKCR & CLSIDs, theres RoActivateInstance and its string-based registry entries.
      - instead of VB's IDispatch/ITypeInfo, there's IInspectable/IMetaDataImport2 for getting type information
      - instead of BSTR, there's the immutable HSTRING

      the confusing this is that there's a whole bunch of work done in the language environments (C++ compiler, .NET runtime) to make all this invisible.

  2. What a stupid headline by ilsaloving · · Score: 5, Insightful

    Of *course* .NET programmers are demand 'despite the move to metro'. Windows 8 isn't going to be release for at least a year, and Windows shops need software built *now*.

    I mean, c'mon... that's not even wrong!

  3. Metro isnt a replacement for .NET by Anonymous Coward · · Score: 5, Informative

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

  4. Quite crappy headline by giuseppemag · · Score: 5, Informative

    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

    --
    My book: Friendly F#, fun with game development and XNA; my game: Galaxy Wars by VSTeam; my gamedev language: Casanova.
    1. Re:Quite crappy headline by westlake · · Score: 5, Informative

      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.

    2. Re:Quite crappy headline by ljw1004 · · Score: 3, Informative

      That's not quite right.

      The .NET standard libraries exist in several profiles -- "Core", "Client", "Full".

      People today write their libraries under the "Core" profile so that they work equally well on any platform -- Silverlight, desktop, phone. Core contains the common standard libraries -- e.g. things like StringBuilder, LINQ, generic collections, and the other day-to-day programming side. "Client Profile" also contains UI stuff, and "Full Profile" also contains server stuff.

      For Metro, you will use APIs from both .NET Core Profile and from WinRT. WinRT will provide things like local storage APIs and UI. Core Profile will provide all the other stuff.

      NB. I'm on the C#/VB language design team at Microsoft.

    3. Re:Quite crappy headline by ljw1004 · · Score: 3, Informative

      The .NET standard libraries WILL be accessible from Metro applications. You'll write your C#/VB metro applications targeting both WinRT APIs and standard .NET APIs at the same time. I suspect that very nearly all C#/VB metro apps will be using many .NET APIs.

      (you had said that the .NET standard libraries wouldn't be available for Metro apps).

      For example:

      IAsyncInfo ai = MessageBox.ShowAsync("hello world"); // using a WinRT API
      Task t = ai.StartAsTask(); // here we're bridging from WinRT to .NET
      await Task.WhenAll(t, Task.Delay(100)); // here we're using standard .NET APIs

      (disclaimer: I work for Microsoft on the VB/C# language team)

  5. Well duh by TheSpoom · · Score: 3, Interesting

    Nobody ever got fired for recommending IB^H^HMicrosoft.

    --
    It's better to vote for what you want and not get it than to vote for what you don't want and get it.
    - E. Debs
  6. Slashdot needs competent editors, not user surveys by pdxChris · · Score: 4, Insightful

    Slashdot just did a survey, that asked whether readers would recommend Slashdot to others. Here is a perfect example of why I answered No to that question, and would have picked Hell No if that option had been in the survey. An increase in job postings for .Net is newsworthy on a "news for nerds" site. Totally ignorant, misinformed, clueless, stupid, arrogant and worthless editorializing, in the article and the headline, is not at all news for nerds, nor is it stuff that matters. Not only is the commentary about Metro completely wrong, so is the "home for newbies" slant. The linked article clearly indicates that more than 70% of resume searches in .Net are for developers with at least four years of experience. Obviously it's impossible to have four years experience with Metro, but it is entirely possible to have been using .Net for a decade now. The article has no mention at all of Metro. The article also mentioned an utterly ignorant, untrue, trite fear of .Net developers: that their skills do not carry over to other platforms. I guess this means a lot of fearful .Net developer who have never heard of Java? Where does Slashdot get the editors to approve this kind of junk?

  7. Re:Microsoft Does Not Eat Its own Dog Food by PPH · · Score: 4, Insightful

    The demand for .NET programmers is to fill the vacancies created by the previous group having seen the light and fled.

    Dice.com posts ads for positions that companies are having trouble filling.

    --
    Have gnu, will travel.
  8. Metro or .NET, why use any? by loufoque · · Score: 3, Insightful

    Why in your right mind would be using any of these?

    1. Re:Metro or .NET, why use any? by Alkonaut · · Score: 3, Informative
      1) If you write a windows (only) desktop app, I recommend c# over c++ for most scenarios (some high perf. things such as games excluded). The productivity is much higher.

      2) Windows phone apps. You definitely need .NET here.

      3) Streaming video apps for desktop. Html5 can't do it, and Silverlights video streaming beats flash every day of the week. Neither is excellent, and SL has terrible linux support. But still, SL is the least bad one.

  9. Re:People stay with what they know by micheas · · Score: 3, Insightful

    Either that or there is a mass defection of programmers from dot net to other platforms that are viewed as having more of a future.

    There are a lot of possible reasons for the influx of ads for a skilled position. Some of them indicating a healthy platform, some of them not.

    --
    Work bio at MMWD
  10. Re:People stay with what they know by ghjm · · Score: 3, Insightful

    Look, isn't it obvious that .NET is simply transitioning from early mainstream to late mainstream? You can only conceivably call it a "dying" platform if your perspective is 100% early adopter, which is 100% not the perspective of business customers.

  11. Mod Parent Down by bondsbw · · Score: 4, Informative

    This isn't insightful. It's plain wrong. As someone who attended the Build conference and spoke directly with several Microsoft program managers, I can attest that Metro/WinRT is not a replacement for .NET. I asked several times something like "But can I do Q in the sandbox?" and they would say "No, in that case use regular .NET to do Q and distribute your apps through traditional channels (or link to the installer in the app store)." I never got the impression that Metro was always the preferred approach, just the preferred approach for slate devices.

    I don't know what Microsoft wants to do in the future past Windows 8. Maybe you're right, and Microsoft wants to give up their stronghold on enterprise applications that have certain hardware or interoperability requirements not allowed by Metro, so that they get control over tablet apps. But I'm not betting the bank on that.

    --
    All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
  12. Re:People stay with what they know by GigaplexNZ · · Score: 3, Informative

    None of Microsoft's own products are written in .NET.

    Visual Studio is.

  13. Re:People stay with what they know by shutdown+-p+now · · Score: 3, Informative

    None of Microsoft's own products are written in .NET.

    Most Microsoft development tools are written partially or wholly in .NET (guess what I do for a living...).

    FWIW, Windows itself has bits and pieces written in .NET as well. Nothing major, but it's there.

  14. Re:People stay with what they know by Kaenneth · · Score: 3, Informative

    Sharepoint, Visual Studio, Expression suite, the Tablet API, the Surface platform, Silverlight, many of the Windows 'Live' applications, and the XNA game framework are all written with .NET