Does Microsoft plan to build its future products using .NET?

I think this question is what everyone wanna ask, as we have discuss again and again here that Microsoft creates a technology they never really use.

Sheva

I would think it depends entirely on the class of application they are building. Some suit .NET, some dont.

Because most Microsoft applications have a large existing codebase in unmanaged code, it is unlikely we'll see a version of Office completely written in .Net anytime soon.

That is not to say MS doesn't use .Net anywhere. Some applications will be completely managed, such as Microsoft Max, some will be largely managed, such as WinFX itself, but most often you will start seeing a lot of integration of .Net with unmanaged products. Examples include the use of managed HttpHandlers in IIS7, managed sprocs in SQL Server 2005, and many more.

As far as MS not using its own technologies... I think microsoft.com is probably one of the largest consumers of ASP.NET. And this sometimes even makes it way into server products they redistribute, such as Windows Server Update Services, which uses an entirely ASP.NET based management system.

They use it. People who complain they don't are expecting them to rewrite VS, Office, IE or maybe even Windows from the ground up in C#. That's not going to happen anytime soon, if ever. There's way too much existing code that nobody is going to throw away. Not to mention there's a lot of places where using managed code simply doesn't make sense.

Watch the Sparkle video. I think that makes the answer pretty clear.

Also watch the latest Hotmail video. They're rewriting Hotmail in 100% .NET. And I think SharePoint is also 100% .NET. And I'm pretty sure a big part of Visual Studio is also written in .NET.

Great explanation Sven, thanks

Sheva

Yes.

- Steve

TommyCarlier wrote:

And I'm pretty sure a big part of Visual Studio is also written in .NET.

Really?  Which part?

TommyCarlier wrote:

And I'm pretty sure a big part of Visual Studio is also written in .NET.

Sorry, don't think so... I believe it is all unmanaged VC++.

JChung2006 wrote:

TommyCarlier wrote: And I'm pretty sure a big part of Visual Studio is also written in .NET.

Really?  Which part?

Visual Studio is an interesting mish-mash of managed and unmanaged code. For instance, the Windows Forms designer is (mostly) managed code.

Not according to Reflector.net.

Manip wrote:

Not according to Reflector.net.

There's quite a few .Net assemblies in my Visual Studio folders, and most of the Windows Forms designer actually uses Windows Forms' own design functionality, which is inherently managed. Ever looked at the System.Windows.Forms.Design namespace? That's the basis of the designer. SharpDevelop uses that too, and that's completely managed code.

According to John Gossman Sparkle is completly managed with only one p/invoke call. Even this wasn't necessary but the chose to use it rather than introduce a dependancy on winforms.

I also remember an interview with the guy that created the new VS2005 XML-editor (with Intellisense for all XML-files that have an XSD-schema), and he said that the editor was also managed.

I've just checked out the VS2005 (beta 2) directories, and there's actually a lot of managed code there:
Go to C:\Program Files\Microsoft Visual Studio 8\Common7\IDE
Check out all the Microsoft.*.dll files: all managed code.

IMO. Managed code is mighiter than unmanaged code in many-multi-core era. CLR will do the job for tweaking MSIL to adapt it to multi-core environment without recompiling source code.

iStation wrote:

IMO. Managed code is mighiter than unmanaged code in many-multi-core era. CLR will do the job for tweaking MSIL to adapt it to multi-core environment without recompiling source code.

That's one typical circumstance in which managed code outplays unmanaged code in terms of performance.

Sheva

iStation wrote:

IMO. Managed code is mighiter than unmanaged code in many-multi-core era. CLR will do the job for tweaking MSIL to adapt it to multi-core environment without recompiling source code.

No VM can magically make a single code stream multithread. Either the application is coded as multithreaded or it isn't. CLR on a multicore won't change squat.

Except for the fact that every .net app uses multiple threads due to the GC. And not to mention the framework libraries that use multiple threads already. Unfortunately last I read Avalon is essentially single threaded.