The fifth and final day of the PDC is coming to a close. There's kind of a muted feeling throughout the Convention Center. The music of the live swing band in the main hall earlier in the week has been replaced by recordings of Lean on Me and Me and Mrs. Jones. After week of eating and sleeping poorly and having brand new knowledge crammed into their heads for three straight days, the attendees that remain are all looking kind of glassy eyed and zombie-like.

[imagine background audio - Good Riddance by Green Day

Before I forget, I want to say thank you to everyone who sent emails about the newsletter. It was a lot of work, but I did enjoy doing it, both for the chance to be a little wacky in a high tech environment and also to force myself to review everything that I learned each day. If you kept reading because you laughed occasionally and learned something because you kept reading, then I accomplished everything I set out to do.

[end sappy background audio]

Oh yes, there were still more breakout sessions today and more knowledge to be gained - let's get on with it.

Errata

JR from Washington pointed out that George Shepherd spells his name slightly differently than I did in yesterday's newsletter. My apologies.

Using Transactions and COM+ Services in the .NET Platform

COM+ seemed to be sort of persona non grata this week, so I hoped that this talk would clear this up. It took a while to get to the good stuff, but the speaker finally gave us some details.

The essence of the talk was this - yes, .NET classes do cooperate with COM+ services just fine. They did go into a couple of implementation details.

COM+ settings can be assigned to a class by a developer at compile time. They come in the form of attributes that are then compiled into the assembly so when the object is installed the default settings are correct. All access to the COM+ services, formerly acquired through GetObjectContext, is done through the Microsoft.ComServices namespace. Here is a code snippet that shows an attribute and the .NET based use of the COM+ services-

using System;
using Microsoft.ComServices;
namespace CSharpBank
{

    [TransactionAttribute(TransactionOption.Required)]
    public class Account
    {
        public void Post(int accountNo, int amount)
        {
            try
            {
                // Do some resource operations

                ContextUtil.SetComplete();

            }
            catch()
            {
                ContextUtil.SetAbort();
            }
        }
    }
}
   

When you build, you need to create a Shared Name for the assembly. This is done with the sn command line program and creates a .snk file that is then compiled into the assembly. I am not too clear on what this is used for, I assume it has deployment benefits.

There are three steps involved in deploying the assembly in COM+. First, open up the Component Services manager and create the COM+ application (this you only have to do once). Second, add the assembly to the Global Assembly store (using the al command line tool, I don't know if you need to do this every time or not). Last, register the assembly with the RegSvcs command line program, which takes both the assembly name and the COM+ application name as arguments.

That's pretty much the gist of it. Not a huge amount of information, just confirmation that .NET and COM+ play nice together and a general idea of what's involved to get there.

.NET Framework Common Language Runtime Performance Considerations

Have you noticed that all the sessions this week have really long titles?

This is another issue that seemed to get very little play this week and also looked like session that I could understand without having to concentrate too hard (see earlier reference to glassy eyed attendees). I'm surprised more people weren't in this session, this seemed like a big issue to me. The session started off talking about measuring performance in the .NET world. Since so much functionality has been moved into the OS, stock Performance Counters can now be provided that tell us more about what is going on inside our application. Things like Percent of time doing garbage collection, Managed to Unmanaged transitions, remote calls a second, and more. These can be watched in PerfMon, or are available inside your program through the System.Diagnostics namespace. Hey, I'm starting to like the idea of having the entire world wrapped in these namespaces for easy access.

Then the presenters talked about coding tips to keep from killing performance. Since none of us will be writing production .NET code for several months, I won't go into all the mundane details. One key point to keep in mind during design is that Managed to Unmanaged transitions are pretty costly and involve marshalling arguments.

Then they got to the numbers. The first numbers they showed us were for an ASP+ version of the MSN home page versus ASP. They had test results for machines with 1, 2 and 4 processors. ASP+ was about twice as fast, but the difference dropped slightly as the number of processors increased. Then they showed some general numbers for an undisclosed group of benchmarks. Currently, the managed code is within 30% of the performance of unmanaged code, they expect this to climb to within 20% of unmanaged code by the time they ship. They also claim to have comparable performance to other runtimes.

This says to me that there are still situations where compiling C++ to native code is going to be appropriate. If we had to take a 20% performance hit at SDR, we could not have met specifications.

Case Study: Porting Search.Microsoft.com to the .NET Framework

[Ed. Note - the links in this article are 8 years old and long since dead.

Not too much content good for writing up in this session, but a couple of very cool factoids that you might enjoy. First, the full functionality of Search.Microsoft.com has been ported to .NET and is available at http://beta.search.microsoft.com. I think you will find it noticeably faster than the current production version. Also, they have written some web services that are available on the net to search the Microsoft site - check out http://beta.search.microsoft.com/search/mscomsearchservice.asmx and you will see the web service help screen we talked about in issue 2. If you figure out the meanings of the arguments from watching the http requests, you can even call the service from this page. Add a ?SDL argument to the URL (http://beta.search.microsoft.com/search/mscomsearchservice.asmx?SDL) and you can see the actual SOAP definition language contract appear in your browser. If you can lay your hands on the bits that they passed out Wednesday (find someone in your office who was here) you can write a VB program that calls the service. Finally, lots of behind the scenes information for the implementation for the fourth biggest site on the web can be found at http://www.microsoft.com/backstage. All the information in today's talk should be posted there next week.

Editorial

I know that calling something an editorial in this newsletter is kind of redundant, but what the heck, it's my party. Here is an inside look at the argument that has been waging in my head all week.

Point-

.NET is a big deal, and the biggest parts of that deal are the Common Language Runtime, the effect it has on all languages and the tools that will help developers write applications and web services easily. There are some distractions, like the rich-client WinForms, but these will follow other ActiveX on the client solutions into oblivion. What Microsoft has done is take lots of the work that was formerly done by the developer or the individual language's runtime and have subsumed it as an operating system feature. The troublesome aspect of this is they are also taking back a large hunk of developers' and third parties' power and independence. There is a reason the VB and C++ have coexisted for year - developers could make a conscious decision about how much power they wanted to cede to the 800 pound gorilla. Now, no matter what language you use, you are selling a hunk of your soul to the .NET big brother in the name of productivity. As I was contemplating this concept in one of the sessions this week, one of the presenters did a demo that very appropriately brought up a video clip from 2001: A Space Odyssey. Open the .NET Bay doors, Hal, only Hal is no longer a oblique reference to IBM. .NET is certainly a shiny object with many attractive productivity features, a beautiful siren on the shore. Let us be vigilant, however, against giving up too much of our independence in our quest to rid ourselves of responsibility.

CounterPoint-

Biff, you ignorant slut. .NET is a huge advance that can only serve to ease the programming backlog by empowering more developers to easily write and share code while creating complex applications. What's not to like, VB developers writing code with the sophistication heretofore limited to C++ and Java? An new language bridging the gap between VB and C++? The Open Standards supported and promoted by Web Services and SOAP? Sure C++ is restricted when you write for .NET, but you can still write the same complex, low-level, high performance stuff you used in your beloved SDR - you just have to take a pass on the CLR. Stop being such an old-school, C++ curmudgeon and wake up to the fact that software construction has to become easier and more productive and .NET is a very good first step.

Letters, We Get Letters

MN from MN (I never get tired of that!) writes-

"Hands up all those that think the original Borland Delphi team is now writing VB !!!!!.

The finally construct has been in Delphi since day one and is a long overdue addition to VB as are all the OO constructs etc etc etc.. Compare the languages, eerily similar (Delphi stole VB's IDE and now VB is stealing Delphi's language, some would say the best of both worlds, unless you program in C(++, #) that is ;-) )

3 Cheers for Microsoft (hip hip hooray !!)"

Dear MN,

There are several brands out there that taste just as good without all the caffeine. -Ed

Goodbye,

Biff Gaut
Head Photographer, Biff's PDC Newsletter