Where's the Windows 7 love for .NET developers?

I remember the heady days of 2003 when we were being promised that in the very near future .NET would be the default way to program Windows for everything other than device drivers and such. WinFX had a very definite meaning - it was the idea of .NET being a managed API for Windows.
While Longhorn ran like a dog and something clearly had to be done, I still think that was the right idea: let's face it, the native Windows API is very much showing its age - much of what I used to think I didn't like about C++ actually turned out to be things I don't like about the way it's used to program for Windows. The native API is simply not a useful level of abstraction - and don't get me started on all those people who say it's write to use COM for this and that because "it's very powerful" - they're just cruising for a slapping.
Oh, and all those shouty structs give me a headache. And do there really have to be 10000 different kinds of strings, none of which are sanely interoperable?
But I digress. I was worried when WinFX was rebranded, and when Vista was released I saw my fears were well-founded: yet more essential features only accessible via native code - and we got Vista Bridge as a half-hearted squib thrown in our direction.
But with Windows 7, despite its admitted wonderfulness, things appear to be much worse. Not only are there yet more native-only APIs, but while features that were previously released in managed-only form have now been provided in native versions, the converse has not been done. That looks like a conscious rejection of .NET as something to be taken seriously for Windows development...the final victory of the bearded elitists. Yes boys and girls, we have been relegated to that ghetto that some of you may recall with something less than affection from the old VB days, while rampant Real Programmerism stalks the streets.
This is not only sad, disappointing and annoying, it is also unnecessary. Ironically, I truly believe that with .NET 3.5 SP1 we finally have a version of .NET that nobody should hesitate to use to write shrink-wrapped applications. Start-up speeds are now truly impressive - and unlike the Windows API the .NET Framework is actually well-designed (that said, for a simple comand line utility I'd still recommend just using C, but that has more to do with my heretical belief that not all problems demand or benefit from object orientation than a native vs. managed issue)

Larry Osterman said:

FWIW, I believe that Windows 7 contains the .Net framework 3.5 SP1 (not 100% sure though).

That's correct (actually, add/remove windows components lists it as .Net Framework 3.5.1, but I assume that just means SP1).

This is the same transition of DirectX to Managed DirectX / XNA. Just be patient. I only hope MS can transfer all their future products to .Net based appliations. You know, at least showing off what .Net can do. So far, I have seen some really good looking flashy warehouse managment software using .Net though.

Larry Osterman said:

FWIW, I believe that Windows 7 contains the .Net framework 3.5 SP1 (not 100% sure though).

The presence of the Framework is a given, it's providing new managed APIs for Windows features that I'm concerned about - and it bothers me that it doesn't seem to be happening. As I pointed out this contrasts with the situation where new native APIs for features previously only available from .NET are being released. It's a good thing that that's being done, but I don't see why it's all one way. I do think it's a lost opportunity.

Kevin Daly said:

Larry Osterman said:

*snip*

The presence of the Framework is a given, it's providing new managed APIs for Windows features that I'm concerned about - and it bothers me that it doesn't seem to be happening. As I pointed out this contrasts with the situation where new native APIs for features previously only available from .NET are being released. It's a good thing that that's being done, but I don't see why it's all one way. I do think it's a lost opportunity.

Wich features would you like to be included natively in .Net?

And seriously, .Net is the workhorse of Microsoft's development platform. They would shoot themselves in the foot before dropping support for it.

I foresee a 2-tier Windows in the future. You will have your core OS, then you (in Win 7) have your Windows Live platform.

Analogously, you have your core OS (again), and your business, silverlight application written in .NET. I'v been doing some job hunting recently, and pretty much all .NET jobs (in England at least) are ASP.NET based. With Silverlight, I can only see this trend continuing. I recently completed a .NET winforms application for a warehouse/distribution centre, and would rather had done it in Silverlight, but there were no controls a year ago, and still no firm data accessaccees technology. Virtualisation is huge in the business world, and people are going for thin clients wherever possible.

I fail to see the necessity of the core OS and it's API, as I won't really ever need the native dialogs, because I don't typically write programs like nero, that interact with the OS, most .NET applications don't really have a need for this. That granted, I checked out the vista bridge (did not know that existed till yesterday) and that has some very useful stuff. It is possible to create a genuine Vista/Win 7 looking application using Winforms, Vista Bridge and some interop albeit rather painful.

The big issue is that Microsoft said they would continue to support windows forms but this (by VS 2010) will not have had an any update or bug fixes (and there are a few) for 5 years. It is the Windows forms code/controls they need to update to reflect the new native API's, because there are a plethora of winforms applications that will remain so for some time into the future.

littleguru said:

I wonder if there's ever going to be something like the Win.NET. By that I mean a managed Windows API over the native APIs. That Win.NET would come with Windows like Win32 is right now... Would be nice.

http://www.pinvoke.net/

And you can ofcourse download the P-Invoke helper from Red Gate,...

All the unmanaged calls you will ever need,...

I too am waiting for a nice .net wrapper, maybe start an CodePlex project?

littleguru said:

I wonder if there's ever going to be something like the Win.NET. By that I mean a managed Windows API over the native APIs. That Win.NET would come with Windows like Win32 is right now... Would be nice.

The problem I have is with things like the User32.dll. If you look at the Office 2007 treeview for instance, I know they tried, but that is still very buggy. They have performed miracles with it in Vista/Win7 but it is a very hard control to modify. Even if you have a managed wrapper around it, the code to get it looking right is very ugly and this is the big problem I have with managed wrappers. Try debugging the .NET source for any winforms control for instance.

Sometimes there are API's that you would like managed wrappers for, and like pinvoke.net, there are loads that exist. This inherantly increases the complexity of your codebase when developing an application, so making further modifications down the road becomes more expensive. You end up with an application like Windows, and it's dialogues that nobody wants to change because

a) it is expensive to do so
b) you may end up introducing more bugs into something that was working already.

I have changed my way of thinking after some serious Win32 programming over the last year, and where possible, just rewrite the native control in managed code because the maintenance of the application becomes that much easier in the future. Yes there are boffins that like very complex programs that do all sorts but .NET programs littered with p/invoke calls are not very maintainable.

Maddus asks a very pertinent question, and it would be nice to know exactly what people are missing from the native API's? 

littleguru said:

Maddus Mattus said:

*snip*

Yeah... imagine what website I use all the time But I guess you got the point... it would be nice to have an out-of-the-box solution.

There's probeply some architectural decision not to make all these API calls availible to .Net developers.

We here are all ultra highly skilled developers who know what we are doing. So for us the threshold for starting P-Invoking unmanaged stuff is not so high. But for the average Joe it's rocket science and I think they intend to keep it that way. That stuff can certainly f00bar up your system. Imagine you writing message filters that grab stuff off the Vista UI message queue, that would seriously open up possibilites for writing all kinds of crappy trojans and virusses running in managed code!

That kind of stuff should stay in the unmanaged world, with a seriously high threshold.

Maddus Mattus said:

littleguru said:

*snip*

There's probeply some architectural decision not to make all these API calls availible to .Net developers.

We here are all ultra highly skilled developers who know what we are doing. So for us the threshold for starting P-Invoking unmanaged stuff is not so high. But for the average Joe it's rocket science and I think they intend to keep it that way. That stuff can certainly f00bar up your system. Imagine you writing message filters that grab stuff off the Vista UI message queue, that would seriously open up possibilites for writing all kinds of crappy trojans and virusses running in managed code!

That kind of stuff should stay in the unmanaged world, with a seriously high threshold.

Windows is developed primarily by native code developers using C/C++. So when it comes to thinking of APIs, they're thinking in terms of native code. Pretty much any Managed Code API is going to be some sort of wrapper around that, it's inevitable and naturally it's going to come further down the line because you can't wrap something till it's finished.

While the intent at one point defintely seemed to be to provide a managed version of everything that made practical sense, I suspect the reality of doing so has proved somewhat more difficult. You can see this in the introduction of much better interoperability functionality in C# 4.0, which is clearly going down the route of making interop less painful and reducing the need for managed wrappers for things like the Office COM objects.

AndyC said:

Maddus Mattus said:

*snip*

Windows is developed primarily by native code developers using C/C++. So when it comes to thinking of APIs, they're thinking in terms of native code. Pretty much any Managed Code API is going to be some sort of wrapper around that, it's inevitable and naturally it's going to come further down the line because you can't wrap something till it's finished.

While the intent at one point defintely seemed to be to provide a managed version of everything that made practical sense, I suspect the reality of doing so has proved somewhat more difficult. You can see this in the introduction of much better interoperability functionality in C# 4.0, which is clearly going down the route of making interop less painful and reducing the need for managed wrappers for things like the Office COM objects.

The more .NET coding you develop, the more you realise that .NET itself is quite hard. Unmanaged developers make the mistake of thinking that everything in .NET is easy, and that there are no new problems that .NET faces, that the native world has not faced.

People need to stop thinking of .NET as a layer that exists on top of C/C++, and that everything in it is easy because this is fallacious. There are some very difficult algorithms that .NET can solve and they are equally hard in native C/C++ or C#/F#. Yes there is a great desire to access the underlying runtime controls for a lot of people, but why limit yourself to a control that was written over a decade ago?

Over the last year or so, every pain point I have had in Windows forms is easily solved using WPF. It really is as simple as that. Take the Office 2007 treeview for example or even the Vista/Win 7 treeview. If you are owner drawing the controls you have to handle some really tricky code, and it takes some time to get the control right, especially when drawing images and node text. Try and do the same with WPF, yes you have to learn some new concepts, but really at the end of the day, it ends up taking the same amount of time but you are not limited by an ageing API.

I don't want to turn this into a WPF Vs Win32 rant, but writing both isn't exactly a walk in the park. .NET is very well designed compared with C/C++ but not everything in it is easier that C/C++. Indeed some things are harder, as you have new concepts to understand, that do not exist in the native world. This is by no means saying that there is equilibrium in the complexity of both, but .NET is very difficult as well.

magicalclick said:

This is the same transition of DirectX to Managed DirectX / XNA. Just be patient. I only hope MS can transfer all their future products to .Net based appliations. You know, at least showing off what .Net can do. So far, I have seen some really good looking flashy warehouse managment software using .Net though.

Managed DirectX has been dead for years and will likely never be brought back to life. XNA is a dead-end as its too tied to the 360 to be able to take advantage of any recent or semi-recent hardware developments. That's more of a perfect example of how Microsoft has failed to deliver a .Net API than a success story.