[wideroots]

The constant framework churning? Examples?

I personally believe having a robust framework that constantly gets updates and new features is a good sign for the development community. Just comparing the changes happened in .NET to Java frameworks, I would to know how moving away from the .NET is a better choice. Is there any other robust framework that you are considering? I don't know any other frameworks that are robust enough. Python and PHP certainly don't have the any comparable size of "ecosystem" when compared to .NET. I use other frameworks when I have to, and this usually happens when I'm developing mobile applications (Object-C for iOS and Java for Android). So far, with changes in Azure, I'm pretty happy with what .NET has done and where .NET is going.

Async/await is something I don't have too much experience, though. So far, I don't think the feature wouldn't be too useful for a complex system and expect the community to stick with how asynchronous programming has been done in the past (e.g. Begin/End methods and IAsyncResults) for such system. However, I think it's a really simple syntactic sugar that developers can take an advantage when they are developing rather relatively small applications, such as windows 8 apps.

[upthedale]

I agree, and I also take issue with the term 'churn'. Churn would imply that features are being removed, replaced with these new ones.

What we are instead seeing is growth of the framework, and community.

To offer an alternative viewpoint to your later point, wideroots, I find the TPL based Task Asyncronous Pattern introduced in .Net4 much more useful that older patterns like Begin/End (APM) pattern, or the event-based pattern (EAP) . I'm looking forward to using the new async/await keywords too. Some things I could rewrite, some things will be better using the underlying tasks directly, and for some things I use other supplementary async technologies, such as Reactive Extensions (Rx) and TPL Dataflow.

But this is just an example of growth, not churn, as the older patterns are still valid, and the community can choose.

As an anecdotal counterpoint to your last sentence, I'm not using these technologies for small applications, rather the complete opposite end of the spectrum. My observation is that the community is embracing these new tools. But again, this is just an example of growth of the community, not churn.

[eckyptang]

Examples: Windows Workflow (rewrites, drop of state machine model), AppFabric, Entity Framework (this is entirely volatile and unreliable), bugginess of MVC3 (attribute lifetimes, DI provider problems), Razor tooling (bugs, changes), IDE schizophrenia and unreliability, the mess that is MS11-100 (breaks every file download for us resulting in hours of work), Silverlight as a whole, ClickOnce being broken in IE9 (6 months for MS support to get us a fix).

I could go on. The whole thing is a dirty great minefield of crap. It's also entirely closed source which means you have to rely on the vendor to fix any problems, which we can't from experience, even though we pay them a fortune every year.

A robust framework is one that you can rely on to act consistently and reliably. It doesn't fulfill that requirement.

For the amount we're paying, we can afford to hire 5 new very senior guys in to fix any problems we have with open source software. That we can't do whilst we're paying for Microsoft.

Also, we feel screwed by the recent policy changes by Microsoft and do not want to end up in a walled garden or cloud service provider model which piggy backs of everyone else's work. Neither are a viable (or legal!) solution for what we do (high finance).

We're trialling various technologies at the moment. Python + Pylons/Pyramid + SQLAlchemy + RabbitMQ + PostgreSQL + ReportLab all on top of OpenStack is looking like the platform choice.

Azure doesn't have a SQL Azure instance that will fit 1/10th of our dataset.