NO, Microsoft hasn't given up on .Net, and YES it's all about cloud

MS SOP, Stage 2

Embrace

Then sit back an wait. If people start to use it and sales of their flagship systems suffer as a result, they will IMHO sue the pants off them all. It won't matter what the patent pleges say, I am sure there is some get out clause burried deep in 4pt type that will let them do it. ergo stage 3, Extinguish.

Why else would they do this? It can't be a money winner now can it?

My Patent Pledge.

No Mono libraries will ever come anywhere near my Linux systems or any of the systems I manage.

The catch

How much of the fluff do you actually expect to work?

So, they've finally improved packaging, though I'm not sure if I like dependency injection being handled by the runtime.

And what is designed for the cloud supposed to mean? Is everything suddenly massively parallel?

Embrace, extend, extinguish

As many others have said, the catch is that MS is now on the first stage. Embrace means that .Net will be competitive with the alternatives, or even better. You'll be able to deploy .Net anywhere, Linux included, and it will be easier than the alternatives.

This is not difficult for MS to achieve, as in a lot of "enterprise" environments Linux deployment is seen as a black art due to the missing installation wizards where you have to press "Next" a few times and everything works by default.

Second stage is "Extend"; where MS starts to add extensions and wizards everywhere so that "enterprise" developers get more of these wizard dialogs to press "Next" a few times and get skeleton applications working that they deploy with the click of a mouse.

Then comes "Extinguish", where all those wizards and extensions get new versions and using them with anything other than MS technologies becomes either very, very hard or impossible. So unless you use a complete Microsoft stack you'll end up in a nightmare of incompatibilities and configuration details that no one really understands. Worse, there is no wizard to fix them.

It has happened in the past. MS did that with IE killing Netscape. Tried to do that with Java, but Sun stopped them in their tracks and they "invented" .Net (recruiting the Delphi main architect to design it, killing two birds with the same stone). They acquired FoxPro only to lead it into irrelevance but making sure Clipper went nowhere. VisualStudio has been supporting over the years a succession of proprietary frameworks and technologies while still not being fully C/C++ standards compliant, not even close to the free alternatives.

There are areas where MS competes and wins because they have a better product. There are some others where they compete and lose. Then there are market segments where they use the "embrace, extend, extinguish" tactic and have won in the past.

I really hope is not going to end like that this time.

"...what's the catch?"

They'll change their minds again in 18 months.

Re: "no changes"?

"every single iteration of product out of Redmond has necessitated plumbing, reworking or outright retooling"

That's not my exerience. Generally just a recompile, and at worst a few code tweaks.

Re: "no changes"?

Then you're doing it wrong.

"For mr 1.8 Billion downloads, divide that by 3 to 6 as that is how many version .Net downloads each PC has"

Nope - that's not possible. The only current RTM install options are 3.x and / or 4.x - so at worst 2 versions. You must be confusing .Net with Java...

And it says 1.8 Billion installs, not downloads.

Re: Dear Sirs

All you should need to install is 3.5 and 4.5.x to be able to run all .Net code.

If you are having compatability problems then your PC is almost certainly not fully patched - a number of minor .Net fixes have been released via Windows Update.

Re: Dear Sirs

"One of the early promises of .NET was an end to "dependency hell"."

That was the clearest possible indication that the early promises were worthless.

Dependency hell is caused by people releasing new versions of old libraries that have different behaviour from the old ones. Shock news: you can do that in *any* language or platform. Indeed, it would hardly be a platform worth using if you couldn't produce a version 2 that fixed the bugs of version 1. Dependency hell is therefore caused by a lack of testing and discipline by practitioners, not a lack of appropriate technology. Anyone trying to sell you a solution to a behavioural problem is selling snake oil.

Meanwhile, unseen (and probably unused) by most, Microsoft have actually rolled out a thoroughly-horrible-but-functional solution to dependency hell, through the medium of activation contexts and manifests. Nothing particularly to do with .NET, though. They are supported for both native and managed code.