The fourth 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 - that "Times of you life" song they played in
the last Seinfeld]
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