TOURNEY LOGIC LINK BLOG

Polymorphism Defined (from: Raymond Lewallen)

Tourney Logic — Wed, 16 Mar 2005 20:26:00 GMT

Finally, the final of the 4 posts on object-oriented principles forthose of you just coming to .Net from non-OOP languages. Data Abstraction, Encapsulation and Inheritance we have already discussed. Now we will talk about polymorphism.

Polymorphism means one name, many forms. Polymorphismmanifests itself by having multiple methods all with the same name, butslighty different functionality. Updated statement: Polymorphism can becoupled with inheritance, but inheritance is not a requirement to gainpolymorphic behaviors. Because of this, it can be difficult tofully grasp the full potential of polymorphism until you get somepractice with it and see exactly what happens under differentscenarios. We’re only going to talk about polymorphism, likethe other topics, at the basic level.

There are 2 basic types of polymorphism. Overridding, alsocalled run-time polymorphism, and overloading, which is referred to ascompile-time polymorphism. This difference is, for methodoverloading, the compiler determines which method will beexecuted, and this decision is made when the code gets compiled.Which method will be used for method overriding is determined atruntime based on the dynamic type of an object.

Let’s look at some code:

' Base class for library assets
Public MustInherit Class LibraryAsset
 
    ' Default fine per day for overdue items
    Private Const _finePerDay As Double = 1.25
 
    ' Due date for an item that has been checked out
    Private _dueDate As DateTime
    Public Property DueDate() As DateTime
        Get
            Return _dueDate
        End Get
        Set(ByVal Value As DateTime)
            _dueDate = Value
        End Set
    End Property
 
    ' Calculates the default fine amount for an overdue item
    Public Overridable Function CalculateFineTotal() As Double
        Dim daysOverdue As Int32 = CalculateDaysOverdue()
        If daysOverdue > 0 Then
            Return daysOverdue * _finePerDay
        Else
            Return 0.0
        End If
    End Function
 
    ' Calculates how many days overdue for an item being returned
    Protected Function CalculateDaysOverdue() As Int32
        Return DateDiff(DateInterval.Day, _dueDate, DateTime.Now())
    End Function
 
End Class
 
' Magazine class that inherits LibraryAsset
Public NotInheritable Class Magazine
    Inherits LibraryAsset
 
End Class
 
' Book class that inherits LibraryAsset
Public NotInheritable Class Book
    Inherits LibraryAsset
 
    ' This is morphing the CalculateFineTotal() function of the base class.
    ' This function overrides the base class function, and any call
    '   to CalculateFineTotal from any instantiated Book class will
    '   use this function, not the base class function.
    ' This type of polymorphism is called overriding.
    Public Overrides Function CalculateFineTotal() As Double
        Dim daysOverdue As Int32 = CalculateDaysOverdue()
        If daysOverdue > 0 Then
            Return daysOverdue * 0.75
        Else
            Return 0.0
        End If
    End Function
 
End Class
 
' AudioCassette class that inherits LibraryAsset
Public NotInheritable Class AudioCassette
    Inherits LibraryAsset
 
    ' This is morphing the CalculateFineTotal() function of the base class.
    ' This is morphing the CalculateFineTotal(double) function of the
    '   audiocassette class.
    ' This function overrides the base class function, and any call
    '   to CalculateFineTotal() from any instantiated AudioCassette
    '   Class will use this function, not the base class function.
    ' This type of polymorphism is called overloading and overriding.
    Public Overloads Overrides Function CalculateFineTotal() As Double
        Dim daysOverdue As Int32 = CalculateDaysOverdue()
        If daysOverdue > 0 Then
            Return daysOverdue * 0.25
        Else
            Return 0.0
        End If
    End Function
 
    ' This is morphing the CalculateFineTotal() function of the
    '   audiocassette class.
    ' This type of polymorphism is called overloading.
    Public Overloads Function CalculateFineTotal(ByVal finePerDay As Double) As Double
        Dim daysOverdue As Int32 = CalculateDaysOverdue()
        If daysOverdue > 0 AndAlso finePerDay > 0.0 Then
            Return daysOverdue * finePerDay
        Else
            Return 0.0
        End If
    End Function
End Class
 

You see our library asset class. Pay attention to theoverridable function CalculateFineTotal(). In LibraryAsset, wehave defined the default functionality for this method that any derivedclasses can use. Any class derived from LibraryAsset can use thisdefault behavior and calculate fines based on the defaultimplementation of $1.25 per day late. This is true for ourMagazine class. We didn’t override the function so when late feesare calculated for late magazine returns, it will use the defaultimplementation.

Now look at the book class. We have overridden theCalculateFineTotal to use a different value when determining latefees. The overrides keywork in VB tells the caller that anymethod call will use the virtual method found in Book, not the defaultimplementation found in LibraryAsset. We have implemented runtimepolymorphism – method overriding.

Lets move on to AudioCassette. Here we have the same methodoverriding we found in the book class. Fines are calculated basedon $0.25 per day. Notice we’ve added something extra. We’veadded the Overloads keywork to our function and to a new function withthe same name, except the new function now accepts a parameter. Now the caller can call either method, and depending on whether or nota parameter is passed, that determines with method will beexecuted. Notice we do not include the overrides keywork in the2nd function with a parameter. This is because not method existsin LibraryAsset with that same signature (accepting a parameter of typedouble). You can only override methods with the same signature ina base class.

Now lets look at some code that creates all these library items andchecks them in and cacluates our fines based on returning them 3 dayslate:

Public Class Demo
 
    Public Sub Go()
        ' Set the due date to be three days ago
        Dim dueDate As DateTime = DateAdd(DateInterval.Day, -3, Now())
        ReturnMagazine(dueDate)
        ReturnBook(dueDate)
        ReturnAudioCassette(dueDate)
    End Sub
 
    Public Sub ReturnMagazine(ByVal dueDate As DateTime)
        Dim myMagazine As LibraryAsset = New Magazine
        myMagazine.DueDate = dueDate
        Dim amountDue As Double = myMagazine.CalculateFineTotal()
        Console.WriteLine("Magazine: {0}", amountDue.ToString())
    End Sub
 
    Public Sub ReturnBook(ByVal dueDate As DateTime)
        Dim myBook As LibraryAsset = New Book
        myBook.DueDate = dueDate
        Dim amountDue As Double = myBook.CalculateFineTotal()
        Console.WriteLine("Book: {0}", amountDue.ToString())
    End Sub
 
    Public Sub ReturnAudioCassette(ByVal dueDate As DateTime)
        Dim myAudioCassette As AudioCassette = New AudioCassette
        myAudioCassette.DueDate = dueDate
        Dim amountDue As Double
        amountDue = myAudioCassette.CalculateFineTotal()
        Console.WriteLine("AudioCassette1: {0}", amountDue.ToString())
        amountDue = myAudioCassette.CalculateFineTotal(3.0)
        Console.WriteLine("AudioCassette2: {0}", amountDue.ToString())
    End Sub
 
End Class

The output will look like the following:

Magazine: 3.75
Book: 2.25
AudioCassette1: 0.75
AudioCassette2: 9

You can see how all of our output was different, based on the methodthat was executed. We created a new Magazine, which is a type ofLibraryAsset. That is why the instantiation says “myMagazine AsLibraryAsset”. However, since we actually want a magazine, wecreate a “New Magazine”. Same thing with book. For Book,its a little bit more tricky. Since we created a Book of the typeLibraryAsset, this is where the polymorphism comes into play. Book overrides the CalculateFineTotal of LibraryAsset. Audiocassette is a little bit different. It actually extends theimplementation of LibraryAsset by including an overloaded function forCalculateFineTotal(). If we weren’t going to use the functionthat took a parameter, we would create it the same way we created theBook and Magazine classes. But in order to use the overloadedfunction, we have to create a new AudioCassette of the typeAudioCassette, because LibraryAsset doesn’t support the overloadedfunction.

Only the Magazine used the default method found in the baseclass. Book and AudioCassette used their own implementations ofthe method. Also, at compile time, the decision was made whichmethod would be used when we calculate amountDue for the AudioCassetteclass. The first call used the 1st method in AudioCassettewithout parameters. The 2nd call used the 2nd method with aparameter.

Currently listening to: Paul Revere - Beastie Boys

Shortcut keys to learn this week (from: Jason Haley)

Tourney Logic — Wed, 16 Mar 2005 20:02:00 GMT

This week's short cut keys to learn

Day 16 -Debugging (should already know most of these)

F5 = Start

Shift + F5 = Stop Debugging

Ctrl + F5 = Start Without Debugging

F11 = Step Into

Shift + F11 = Step Out

F10 = Step Over

Day 17 - Debugging windows

Ctrl + Alt V, T = This

Ctrl + Alt + H = Threads

Day 18 - Text editing

Shift + Alt + Down Arrow = Line Down Extend Column

Shift + Alt + Up Arrow = Line Up Extend Column

Day 19 - Text editing

Ctrl + Shift + U = Make Uppercase (Great for those of you who capitalize constants)

Ctrl + U = Make Lowercase

Day 20 - MSDN Help

Shift + Alt + F3 = Search results

Shift + Alt + F2 = Index results

This Blog Hosted On: http://www.DotNetJunkies.com/

Advanced ASP.NET Caching and AddValidationCallBack (from: ComputerZen.com - Scott Hanselman's Weblog)

Tourney Logic — Wed, 16 Mar 2005 20:01:00 GMT

EDIT: Content removed per Scott's request.

http://www.hanselman.com/blog/AdvancedASPNETCachingAndAddValidationCallBack.aspx | Comments

Cool MSI custom action debugging tool (from: Aaron Stebner)

Tourney Logic — Wed, 16 Mar 2005 20:01:00 GMT

I posted an item on my blog last week with some details about how Windows Installer custom actions work behind the scenes. Some of the feedback I got back after posting this item asked some good questions about debugging strategies for custom actions. Based on that, I wanted to share a wrapper DLL written by Jungwook Bae, a developer on the Visual Studio and .NET Framework setup team. His tool makes the process of implementing and debugging DLL custom actions much simpler. You can download the tool itself by clicking here. The following is more information about the wrapper DLL and how to use it:

CATest - a tool that will help developing custom action DLLs

One of the biggest pains when writing custom actions is whenever you modify the DLL, you have to stream the new DLL into the MSI and restart setup. Deferred custom actions are the most difficult because you have to wait until all the files are copied and registry values are written again, which can take a very long time for large products.

To get around this problem, you can use catest.dll as a wrapper for the custom action DLL you are writing. You can test your custom action DLL without streaming it into your MSI, and you can run it as many times you want without restarting setup.

How to use CATest:

Add catest.dll to the binary table of your MSI (by using Orca or some other tool)
Share out your build folder so that your DLL and PDBs are accessible from a test machine
Modify catest.ini to match your custom action name, path to DLL and EntryPoint. You can debug the following 4 types of custom actions: Immediate, Deferred, Rollback, and Commit. You do not need to include all 4 sections in catest.ini; instead you can include only the ones you want to test.
Copy modified catest.ini to %windir% on the machine we are testing.
Modify the custom action records in the CustomAction table of your MSI to point to catest for each of the custom actions you want to debug. Each custom action you want to be able to debug should have "catest" as the Source value and the Target value, and should match the custom actions that you list in catest.ini.
Now you are ready to go, so run the setup. When prompted to attach a debugger, you can attach your favorite debugger and click OK. Then, you can load your symbols and open source files to step through the code. When the custom action finishes, a dialog will ask if you want to retry the custom action. You can update your code and rebuild the DLL, then choose to retry the custom action and debug it again within the same installation session. Note: you will have to reload your symbols if you rebuild and rerun the custom action.

Recycling the ASP.NET worker process at set intervals (from: Steve Hebert)

Tourney Logic — Wed, 16 Mar 2005 20:01:00 GMT

Many ASP.NET developers are not aware of the ability to restart the ASP.NET worker process at given intervals in code. While IIS6.0 makes a number of these features available through the UI, most of the features can be used in IIS5 and 5.1 as well. I've found this useful for rogue components that are consuming memory and this provides a bandaid fix until the root problem is identified.

The <processModel> model configuration setting allows you to set limits that any given running ASPNET_WP process will operate under until it's recycled. For instance, if I set requestLimit="10000", a given ASPNET_WP process will run until 10000 requests have been serviced. At that time, a new ASPNET_WP service will start and requests will be directed at it. The old ASPNET_WP process will then be shut down.

This setting can be made in the machine.config file and affects all processes .Net processes on that machine. The related MSDN article can be found here.

A Boilerplate HttpHandler (from: ComputerZen.com - Scott Hanselman's Weblog)

Tourney Logic — Wed, 16 Mar 2005 20:00:00 GMT

EDIT: Content removed per Scott's request.

http://www.hanselman.com/blog/ABoilerplateHttpHandler.aspx | Comments

.Net performance: Boxing vs. parsing (from: James Geurts)

Tourney Logic — Wed, 16 Mar 2005 20:00:00 GMT

I just asked this in a performance chat w/ Rico. It might be of use to some developers that are curious about these sorts of things...

Q: Hey Rico. How much of a performance difference is there between boxing vs. parsing. For instance:
return (bool)ViewState["myvar"];
vs.
return bool.parse(ViewState["myvar"].ToString());

A: Parsing is a total disaster compared to boxing. ToString will make a string then it will be parsed. Actually in that example there's just unboxing which is really cheap. Very few cases of boxing would ever be more expensive than making a temp string -- it's not *that* bad to box

This was mainly due to an FxCop rule that says that it is bad to box values. Apparently this is one case where boxing is much better than the alternative.

Anti-Spam inputs using random client IDs (from: Brian Scott)

Tourney Logic — Tue, 22 Feb 2005 20:40:00 GMT

Recently I have been thinking about ways to make it harder for spam bots to submit blog comments or any other type of spam. Most likely they are sending out custom POST requests to comment pages where the name or ID of the form fields is well known. It is just a simple matter of supplying values for those field names and posting the request to the appropriate url.

The solution I thought about was giving all the input fields random IDs. The IDs should change for each new request to the page, except on postback. However, I was not sure how this would work with the page lifecycle and postbacks. Would I still be able to easily access the control by the ID I explicitly assigned it. If not, how much work would it be to find a control by the random ID that is generated at runtime for each new non-postback request.

I sat down played with a TextBox on an aspx page for a couple minutes. I discovered it is much simpler than I originally thought it would be. Changing the ID in the Page_Load event didn’t affect my ability to access the TextBox by the original ID I had explicitly assigned it. In order to restore the ID on a postback, I put the generated ID into a session variable identified by the ClientID that ASP.NET generates. On a postback, the TextBox ID is restored to the generated ID. On all new requests, a new random ID is generated.

Next, I sub-classed a TextBox and dropped the code in the OnLoad override. I was happy to see that I could use this control exactly like a regular TextBox with no additional or different programming. The ID on the client changed with each new request, but my code behind did not care.

Here is the code:

[DefaultProperty("Text"),
    ToolboxData("<{0}:AntiSpamTextBox runat=server>")]
public class AntiSpamTextBox : TextBox
{
    public AntiSpamTextBox()
    {}

    protected override void OnLoad(System.EventArgs e)
    {
        HttpContext context = HttpContext.Current;
        if(!Page.IsPostBack)
        {
            string id = Guid.NewGuid().ToString("N");
            context.Session.Add(ClientID, id);
            ID = id;
        }
        else
        {
            ID = context.Session[ClientID].ToString();
        }

        base.OnLoad (e);
    }
}

This may be over simplistic, but it seems like it would help. I tested multiple controls on one page and they all performed as expected, each having a different, random ID. I was also able to correctly access each controls value in the code behind during a postback. As is, the control still needs some code to deal with expired sessions, but I'm still thinking about the best way to persist the ID between requests. Viewstate may work.

I used the ClientID because at that point in the code, the ClientID is still the unique ID generated by ASP.NET. It seemed like a good candidate to distinguish between multiple controls on the same page.

Anyone else think this could be useful? Any thoughts on other ways to do it?

Goodbye Web Forms (from: Blogtastic)

Tourney Logic — Tue, 22 Feb 2005 20:39:00 GMT

Today I committed the final changes to a large chunk of CruiseControl.NET work that I'm rather proud of, namely removing all Web Forms code from the Dashboard Web App.

'What??' you may cry. 'You've stopped using ASP.NET??' No, I've just stopped using Web Forms. Web Forms are those .aspx files you write and their code behinds. They're also the things that use server controls, view state and other such components that make up most of .NET web apps. I'm still using the ASP.NET runtime in the form of an IHttpHandler. This is a much more lightweight way of developing web apps, similar to Java's Servlets.

So why have I done this and thrown away the incredibally rich System.Web.UI namespace? Well for a number of reasons, but chiefly because of testability and simplicity.

Web Forms are hard things to unit test. Basically you can't. This is because of how closely tied all Page implementations are into the ASP.NET framework. To introduce testability you have to keep your code-behinds very thin, but once you've got a few controls on your page this is tricky. Also, any logic that you put in the .aspx file itself is even harder to test, and this includes any templates, grid setup or whatever.

ASP.NET Web Forms also seem to be incredibally complex to me. The Page class alone is a pretty big beast, with all those events going on under the hood. And don't even start me on Data Grids and Data Binding. Easy to setup something up in a prototype, yes, but simple to maintain? I'm not convinced. Fundamentally, web apps should be simple. You have a request with a bunch of parameters and you produce a response which is (to most intents and purposes) a string. Now I know that Web Forms are supposed to introduce a new model above all this stuff, but I don't think the abstraction works particularly well once you get beyond a prototype.

So anyway, I decided to try and get rid of using Web Forms. I've evolved a new web framework, based a little bit on WebWork. It has an ultra simple front-controller and is based on decorated actions. Views are just html strings, but I'm using NVelocity to generate them. I'm using an IHttpHandler to process requests, and at the moment I'm overriding the .aspx extension to be handled by my custom handler, not the Web Forms handler.

Will this be any use outside of CruiseControl.NET? I'm not sure - I might just be going off on one. But that said a good number of my Java-developing colleagues in ThoughtWorks have migrated from using Struts to WebWork, for similar to reasons to why I've moved away from Web Forms. Is any of my code re-usable? I think so, indeed I hope to spin off the web framework as a separate open source project, but the point is it is possible to write perfectly decent web applications in .NET without using Web Forms.

Finally, I'd like to give significant kudos to Joe Walnes. He wrote some of WebWork, and badgered me to think about using it as a basis of a new web framework for .NET. He also introduced to me the ideas of using IHttpHandler's as the entry point for such a custom framework and of overriding .aspx handling to avoid reconfiguring IIS.

Responding to Richard Grimes article on .NET (from: Dan Fernandez)

Tourney Logic — Tue, 22 Feb 2005 20:39:00 GMT

http://blogs.msdn.com/somasegar/archive/2004/06/03/148131.aspxI recently ran across an article written by Richard Grimes in Dr. Dobbs Journal titled Mr. Grimes farewell. I wanted to respond to some of Richard's assertions and points in the article. You should take Richard's article with a grain of salt as he does clearly state that the article is "his opinion". That being said, Richard's article is supposed to be his view of the current state of .NET, but rather then discuss how far we've come and where we're going, he instead argues three points - the .NET Framework is too large blocking adoption, issues with the design of the .NET Framework, and over half the article bashing Visual Basic, and finally that Microsoft is "losing confidence" in the .NET Framework. His quotes, italicized in gray, and my responses are below.

On the size of the .NET Framework blocking adoption

RG:The framework redistributable is 25 MB, which is many times larger than the Java redistributable. One of the lessons of the early versions of Visual Basic was that the shareware and freeware market created the popularity of the language. While there are some shareware apps written in .NET, I often hear people complain about the huge redistributable.

My Response: Maybe I'm being too picky, but the size is 23,698K or 23.7MB. While Java's runtime is smaller, it still weighs in at 15MB. Throughout the article, Richard refers to .NET applications when he's really referring to client or public client (meaning not in the firewall) For example, installing the .NET Framework on a server or within an intranet where you can control the environment certainly isn't an issue. Even for public client machines, there's plenty of commercial shareware from games to RSS readers that require the .NET Framework. I've also talked to plenty of shareware developers and they certainly aren't using Java. Many use C/C++, Visual Basic, or Delphi. As far as adoption "and the state of .NET", which the article is supposed to be about is best summarized by Soma, the Developer Division Vice President in his post on .NET Momentum.

Soma: We have seen over 70 million downloads of the .NET framework from Windows Update and the Microsoft Download center to date. For a simple guy like me, that translates to about 5.5 million downloads a month. Another interesting datapoint is that in 2004, we expect to have about 54 million new PCs shipping with the .NET framework installed/preloaded. We also have over 2.5M developers targeting managed code.

On the Design of the .NET Framework

RG: Almost the first thing I posted on the technical preview newsgroups was a simple console application in Cool, and its equivalent in Java with the rhetoric question to spot the difference.
RG: There are classes that are mere wrappers around Win32, but there are other classes that appear to be ported from other frameworks. Before it released .NET, Microsoft had its own Java framework library called WFC, and it also had a managed library as part of the Visual Basic (classic) runtime. It would be nice to know how many classes from WFC and VB were ported to .NET.

My Response: These two points contradict each other. In the first he implies that the .NET Framework is a replica of Java, but in the next statement he claims that the .NET Framework is simply ported Win32 classes, Windows Foundation Classes (WFC), and VB runtime classes. Which one is it? If his point is that you can write a simple application and that it will look the same in C# and Java or C++, I don't think that really proves much. Below is an example of a for loop.

for (int i = 0; i < x; i++) {...}

Guess what language it's written in? If you said either C, C++, C#, and Java, then you are correct. I don't see what he's trying to prove here. If he tries to build a more robust application then "Hello World" your going to run into framework or library specific features (ATL is not, MFC is not EJB, etc).

On Interface-based Programming and Remoting

RG: Interfaces are elegant but .NET's preference for class-based solutions has marked the death of interfaces. Look at .NET remoting: This has been provided to allow an object to run in the context where it was created, and be accessed from another context. This means that the object state is kept local, and it is the behavior that is remoted. Thus, remoting is an interface-based facility. You can use .NET remoting with interfaces, but reading through the documentation and all of the “how-tos” on the Web, you wouldn't realize this.

Point #1 - Interfaces are dead

My Response: Interfaces are used everywhere in the .NET Framework and are especially valuable given single inheritance in languages like VB and C#. Even the simple string class has IComparable, ICloneable, IConvertible, and IEnumerable interfaces. Going forward, one of the key new features for the .NET Framework 2.0, generics, uses interfaces for constraining data types.

Point #2 - Lack of documentation on using interfaces with .NET Remoting

My Response: I am by no means saying that our documentation is flawless, but here's a link to the .NET Framework SDK Samples on Remoting. Notice the fifth sample down is using Interfaces with remoting. I also outline our guidance on using interfaces for remoting below.
.NET can use interfaces but the preferred way is to use classes.
RG: Instead, Microsoft prefers people to use a class-based approach, which often results in the bizarre situation of people deploying their server assembly to the client so that the client has the metadata of the service objects available, or a soapsuds assembly, which basically was a hack to get around the problems of having class-based remoting.

My Response: We don't "prefer" any mechanism, per se. While we may offer guidance, developers can choose to develop their applications as they see fit. Our Patterns and Practices group does provide guidance and best practices on these and other points and even includes guidelines on how to design a remote interface. I don't see a class-based favoritism over interfaces, in fact, there has been an increasing movement to use messages and service orientation rather then object orientation. I concede his point on deploying server assemblies to the client, but poor design is poor design. People deploying a server assembly to a client just so that the metadata of the service objects is available could have easily used an interface or schema instead. That being said, there are some situations where you do in fact want to have server code in each client, the example being a peer-to-peer chat where each client acts as both a client and a server.

On Microsoft using the .NET Framework for their applications

Microsoft treats .NET as a useful library to extend its products, and to date, it has not shown any more conviction to the framework. There have been a few .NET products written entirely in .NET; one such product is Microsoft CRM....They do not want the expense of rewriting their existing code for .NET, and there is no compulsion to provide all new code in .NET; instead, .NET will be hosted as and when it's needed, particularly to allow extensibility through user-supplied code.

My Response: We should dissect exactly what Richard says here. He says that Microsoft is using .NET to extend existing products and that Microsoft doesn't want the expense of rewriting applications from scratch in .NET. This makes perfect sense to me, why would we re-write perfectly good code? .NET code can interoperate with existing code, and you bet we're going to take advantage of the interoperability layer to add new features that exploit the best managed code has to offer. As I pointed out previously, Microsoft is using .NET in all sorts of software from operating systems, to developer tools, to Office.

Microsoft's current operating systems, XP and Windows 2003, do not depend on .NET; and with XP, .NET is an optional component.

My Response: This is a half-truth at best. While Windows XP Professional does not use the .NET Framework, that's because the .NET Framework was released after Windows XP Professional shipped. Let's look at the operating systems that shipped after the .NET Framework was released:

Windows XP Media Center edition requires the .NET Framework for MCE-specific applications.
Windows XP Professional Tablet PC Edition requires the .NET Framework for handwriting recognition which is a managed application.
Windows Server 2003 requires the .NET Framework to use ASP.NET, UDDI Services, or Sharepoint Team Services.
Windows Small Business Server 2003 requires the .NET Framework for ASP.NET as do SBS specific applications like Remote Web Workplace, and the Backup Snap-in.

On Longhorn and the death of browser applications

RG: My opinion is that Avalon, or more specifically, XAML, will mark the death of ASP. The reason is that Avalon is a client-side technology, but the browser is an important part of the distribution model. XAML is so rich that a browser-contained XAML application will look no different to a process-based Avalon application, and coupled with Web Services or Indigo (as the mechanism to access remote code), an XAML application will make an ASP.NET application look paltry and antiquated. Why would Microsoft want to kill ASP? Well, with installation of ASP.NET Microsoft sells a single copy of Windows 2003 and perhaps a handful of copies of Visual Studio.NET. The clients don't have to be Windows, so there is no extra sale to Microsoft (whether as a product or licence). This is hardly a great revenue generator, and worse, ASP.NET actually makes it easy to write the application so that it can be used by browsers other than IE.

My Reponse: I respectfully disagree. XAML will allow for rich interfaces, but ASP.NET and HTML are not going away. Our value is that we can take the best of both worlds, and provide an optimized experience to XAML browsers while still maintaining compatibility with old computers. It should also be noted that there is a difference between client applications and server applications. The server market itself is *totally different* then the client/consumer market. While people talk about Microsoft's dominance in client operating systems at around 90%, we are nowhere near that number in the server market. We're competing against products and companies like IBM WebSphere, hundreds of middleware products, Oracle in the database market, etc. If we want to win the server market, we need to have the fastest, most reliable, most secure, most productive and affordable solution for creating Web applications. To say that browser applications are a threat to Microsoft is so....1996. The threat is not the Web. If it was, wouldn't Microsoft have "lost" already given that the Web is already incredibly successful and popular. How much more popular does the Web have to be before this is proven untrue? Richard then goes on to say that Microsoft needs to do this because of client revenue. The client operating system market, as stated above ~90% is pretty saturated. The server market is where the opportunity for revenue growth truly lies (PS the server and tool business grew 18% last quarter! - see slide 9). On the question of revenue, a typical server deal is in the thousands of dollars as you're paying for several parts including:

Operating Systems
Transaction Engine
Middleware
Database

Depending on the complexity of the solution, this can range from thousands of dollars to several million dollars. Server products are expensive. If you look at the market for Web content-management solutions, the average price can be around $50,000 for a one-proc enterprise license. My point being that there are plenty of revenue opportunities and competitive threats from the likes of IBM and others in the server market. Do you know how large the market for database software is in terms of revenue? Would you agree that it's billions of dollars? Do you know that Oracle is the #2 software company and their primary revenue is from databases? That's just *one* of the market opportunities for server software. Back to my point - We are totally committed to our server products and to making Windows Server and ASP.NET the best platform for creating Web applications. Period.

On Longhorn

RG: I take the decision to make Avalon available to other versions of Windows as a lack of confidence in the sales of Longhorn.
RG: However, Microsoft's announcement that Avalon will be available for other versions of Windows indicates to me that they are not so confident on the uptake of Longhorn, and developers will not write applications for Avalon if they are not convinced that there will be the clients that will run it.

My Reponse: The decision to make Avalon available to other versions of Windows was driven by one thing, customer demand. Any rudimentary Web search turns up results of customers complaining about not being able to have this functionality on down-level operating systems.

On using the .NET Framework for shipping products

RG: So, with the announcements they have made last year, Microsoft has indicated that Longhorn will not be the great .NET innovation that we were lead to believe it was from PDC 2003. This indicates to me that Microsoft is losing confidence in .NET.

My Reponse: Richard, the key parts of Longhorn you've mentioned in your article, Avalon and Indigo, are written in managed code. How does that indicate we are losing confidence in .NET when we've decided to bet the success of our next operating system on the .NET Framework? You might then make the follow up argument that because the entire operating system isn't managed, that we have "lost confidence". While that's your opinion, I don't think managed code is right for every scenario and Microsoft has never claimed that it is. Microsoft still fully supports C/C++ and we have a very large existing C/C++ code base and C++ customer constiuency. We'll use managed code where it makes sense.

RG: The framework has become Visual Basic—it's intended for users to develop applications, but not for Microsoft to create operating systems or the revenue generating products that they base their profits on.

My Response: I'll avoid responding to the VB bashing as someone is already working on that. There are two points here, one is using the .NET Framework for creating operating systems, the other on Microsoft revenue. On creating operating systems using the .NET Framework, I don't think we've *ever* said that you should be creating an operating system from scratch based solely on managed code. The truth is, gasp, the vast majority of our customers are not creating operating systems. For those customers who are or who need that level of control and performance, we have C/C++ and we absolutely have not abandoned that. On revenue generating profits, I've already listed several revenue generating applications using the .NET Framework. Microsoft is divided into the seven business groups listed below and let's see which ones are using managed code.

Client - Check
Information Worker - Check
Server & Tools - Check
Home and Entertainment - Check
MSN - Check
MBS - Check
Mobile and Embedded Devices - Check

I hope this clears up and FUD, half-truths and any misconceptions on managed code. If something is incorrect here, please let me know!