Microsoft and .NET (by yag)

I read a comment to a thread on Scott Hanselman’s blog that said “The day Microsoft is writing Office, Media Player, Visual Studio totally in .NET is the day I would expect that Windows Forms are finally ready.” I wanted to talk about that and a few other misconceptions (as I see them).

When a company moves to a new development framework like .NET – I don’t expect anyone to immediately do so. You pick a new application, build it, see the ROI, the training time involved, and work from there. You select portions of applications that are being built and can be separated, and start there. We’re doing that her at Microsoft. Here’s a partial list of applications (internal and external) that use .NET. I’m not including things like Windows Server 2003 that included the framework; but I am including any applications that ship with it and are built on the framework.


  • Windows Server 2003 
    • .NET Framework required to use Sharepoint Team Services
    • .NET Framework required to use UDDI Services
  • Small Business Server 2003
    • Remote Web Workplace and the Backup Snap-in
  • Windows XP Tablet PC Edition –
    • Tablet API written in managed code
  • Windows XP Media Center Edition
    • Media Center applications written in managed code
  • Windows “Longhorn” – Managed API


  • Frontpage 11 requires the .NET Framework for working with ASP.NET
  • Outlook Business Contact Manager – Majority of application is managed code
  • Office System – Sharepoint Portal Server 2.0
    • Requires .NET Framework 1.1, written in managed code

Server Products

  • SQL Server
    • “Yukon” will natively host .NET Framework 2.0, parts are written in managed code
  • SQL Server Reporting Services – Majority of application written in managed code
  • Exchange 2003 – Outlook Mobile Access is written in managed code using ASP.NET mobile controls
  • BizTalk 2004 - parts are written in managed code
  • Commerce Server 2002 - parts are written in managed code
  • Content Management Server 2002 - parts are written in managed code
  • MSN Messenger Server (Presence server and admin/config tools)
  • Microsoft Business Network written in managed code, requires .NET Framework 1.1
  • MS-CRM – parts are written in managed code
  • SharePoint Portal Server 2003 – Parts written in managed code
  • Speech Server 2004 – Parts written in managed code

Developer Tools

  • ASP.NET Web Matrix – Fully written in managed code
  • Visual Studio .NET 2002/3 - parts are written in managed code
  • .NET Framework 1.0/1.1 - parts are written in managed code
  • Assignment Manager - fully written in managed code

Web Properties

Internal applications

  • Account Explorer
  • HeadTrax
  • Consensus
  • MS Contract
  • eSupport
  • Enterprise Product Roadmap (EPR) Explorer
  • TSP Academy Virtual Instructor
  • Strategic Impact Report (SIR)
  • Country Manager Content
  • TANLink Contributor and Explorer (2 applications)

My point here is that we have made a bet across the company on managed code. We use it internally in our own IT systems, we are writing new applications with it, and we are continuing to do so.

A similar question often arises – which language does Microsoft use? The answer is yes. <g> Many of our applications were written in C++, and those developers now write applications in Managed C++ and C#. Much of our testing and many internal systems were written in VB6, and are now being written in VB.NET. The nice thing is that these can all interoperate, and you can use your knowledge in the other languages to move forward to the .NET versions.

Comments (19)
  1. AndrewSeven says:

    I’m a c# web guy.

    The comment seemed to only take issue with Windows Form, not with .Net in general.

    "Frontpage 11 requires the .NET Framework for working with ASP.NET"

    -Uh yes, of course, you need .Net to use .Net

    "Commerce Server 2002 – parts are written in managed code"

    Other than the PIA? Do you mean the APIs that returns DataSet instead of Recordset?

    Or do you mean the Feature Pack?

    .Net has made wonderfull progress on the server, but not so much on the desktop. (sounds a bit like Linux 😛 )

  2. yag says:

    As an FYI – a number of these are Windows Forms apps – both products and internal systems. I agree with you that I could have kept FP11 out. <g>

  3. Most of the .NET framework is wrapper code and abstraction of existing Win32 libraries. (I know this, because I worked on it). It then builds on top of that.

    Not much of the Visual Studio UI is entirely managed code – a lot of it is wrapped Office libraries. The editor (IIRC) is entirely C++, with a COM layer for add-in support.

    So the people complaining have a point. When the WHOLE of Visual Studio is written using Winforms – and NOT wrapped win32 libraries, .NET will be a proven framework.

    Same goes for Office.

    Basically, you need to make sure that you can write an entire app without dropping into the Win32 framework. Given that GDI+ has lousy support for multilingual text, and Uniscribe is not part of .NET (you need to import it manually – there’s no wrapper pre-made), and GDI is not part of .NET either (so no glyph reordering support, etc)…. you can’t do a large scale app entirely in .NET at this time because of this.

    This is a problem that needs to be addressed. Hopefully pre-Avalon.

  4. Bob Riemersma says:

    > .Net has made wonderfull progress on the

    > server, but not so much on the desktop.

    > (sounds a bit like Linux 😛 )

    I’d say more like "deJava vu all over again" but it’s getting there, slowly.

    I can’t keep up though. Doesn’t Avalon’s position suggest a sunset on WinForms down the road? Or do people simply regard Avalon as WinForms II and think of "Winforms" as a generic term now?

  5. Fantastic list! Thanks for posting and for clearing this up!

  6. You left off the Web Services Enhancements which are mostly written in managed code (including VS addin)

  7. AndrewSeven says:

    .Net has proven itself to me, I don’t want to use anything else.

    I don’t make Windows Forms app, just Asp.Net and libraries

  8. Andrew, .NET is great for serverside stuff like web services and web apps.

    It’s client-side where things get murky.

  9. Kris says:

    It would have been nice if InfoPath was implemented in .NET

  10. I wish you could write Media Center Applications in .NET

    Media Center 2005 comes with support for add-ins written in .NET what is really cool, but the applications still have to be HTML/JScript 🙁 (although most parts of Media Center are managed code).

  11. MBA says:

    Helpful For MBA Fans.

Comments are closed.

Skip to main content