I'm sitting in a large conference room watching my manager, Scott Wiltamuth, do a
presentation about the new features in the C# IDE. The highlights are:
I spent a bit of time in the session on the new C++ language syntax, and I saw a similar
presentation a few weeks ago back in Redmond. The current release of VC++ uses an
extension syntax to "add on" the managed (ie clr) concepts onto the existing C++ syntax.
For Whidbey, the C++ team has ingrained the managed concepts deeply into the language
syntax, which should make it easier to write managed code using C++.
Well, I'm here
PDC (and OOPSLA, which also runs this week) had a run-in with mother nature, and mother
nature is ahead. Fires in California shut down the LA regional FAA office. FAA Regional
offices control large amounts of airspace around a region, handling all flights once
they've left the airspace local to the airport.
This meant that nothing was leaving airports on the way to LAX. Our 12PM flight left
at about 4:10, and we were all grateful, since most of the people in our group didn't
make it at all. Anders wasn't able to get down here to present at OOPSLA, though he's
expected to get here sometime today.
The fires have also imparte a slight tinge of woodsmoke in the air, lending a "summer
camp" feeling to the whole city, and noticeably worsening the already viscous LA air.
I'm staying in the Westin 'Bonaventure' (literally, "We are sorry that we can't offer
you the queen size bed we promised you, but we can offer you a room without a minibar"),
with interior architecture designed by the same guy that built the "marble ramp"(link)
toys that I (I mean "my daughter") enjoy so much. The lobby has big supports under
the towers, with spiral ramps around them going up and down. Sounds like a good idea
except a) you can only get to certain levels with the elevators and b) the food court
(good idea in concept) is spread out around the entire perimeter, and you can't actually
see what the other restaurants are like, so you have to walk all the way around to
find out what there is and then continue the walk back to the one you want. Given
the quality of the cuisine, perhaps that's a benefit.
I went in this morning, got my registration stuff, and stopped by the keynote for
a few minutes. I was happy to see that, despite any travel problems, the room was
*packed*. I couldn't stay for very long, as I had to leave for a series of customer
meetings that the C# team was holding.
Specs are online.
Note that there's a language discussion forum devoted to the language there.
If you don't own Word, download the free
I've just finished doing a security review of my MSDN columns, and as part of that,
I needed to add some security to an add-in architecture, so the add-in architecture
won't run antisocial code. The approach taken by .NET security is reminiscent of ACLs,
which means (at least to me) that it's confusing and I need to read the code 5 or
6 times before I understand it. Along the way, I got a chunk of code from somebody
on the .NET security team, which I'll reproduce here:
private NamedPermissionSet FindNamedPermissionSet(string name)
IEnumerator policyEnumerator = SecurityManager.PolicyHierarchy();
PolicyLevel currentLevel = (PolicyLevel)policyEnumerator.Current;
if (currentLevel.Label == "Machine")
IList namedPermissions = currentLevel.NamedPermissionSets;
IEnumerator namedPermission = namedPermissions.GetEnumerator();
if (((NamedPermissionSet)namedPermission.Current).Name == name)
Ugly, isn't it?
The root of the problem is that PolicyHierarchy returns an IEnumerator instead of
an object that supports IENumerable. This means that I can't use foreach on
it, and have to write the traversal myself. This decision also means that, without
a collection returned, there's no place to hang a useful method like "LookupLabel()"
on, so all users are stuck writing the search code themselves (or encapsulating it
off into a separate method).
PolicyLevel.NamedPermissionSets uses a different approach, that of returning an IList,
which is better than an enumerator, as I could use foreach on the IList, but the person
who wrote this sample didn't because they didn't know about foreach. If they had,
they would have done the right thing.
We need to not do this.
The Visual C# Team and PDC
PDC is next week, and a lot of C# team members will be there. This schedule outlines
our main activities during the week.
You’ll know that you’ve found a C# team member by the “C# Team Member” button that
they’re wearing. If you see one of us, feel free to approach us at any time – we’re
there to talk to you.
Visual C# PDC Schedule Overview
2:00PM – 3:15 PM IDE Enhancements
for the C# Developer (515AB)
3:45PM – 5:00 PM Language Enhancements
5:00PM - ?? Discuss
the two C# talks, or other topics (Tools Lounge)
5:15PM – 6:30 PM Advanced Debugging
7:00PM – 9:00 PM Ask the Experts
1:00PM – 2:00PM Book signing, Scott
Wiltamuth & Anders Hejlsberg
hall book store)
3:00PM – 4:00PM C# Developer
Lounge (Tools Lounge)
1:45PM – 2:45PM Panel: Future of .NET
Languages, Anders Hejlsberg
6:00 PM LA
.NET User Group Meeting,
Nalewabau, Shaykat Chaudhuri (not at the convention center)
The Visual C# team will be presenting three talks at PDC, all of which are back to
back on Thursday (note to self – make sure we don’t do this next time).
Visual C# "Whidbey": IDE Enhancements for the C# Developer
Tuesday 2:00 PM – 3:15 PM
Visual C# PUM Scott Wiltamuth (PUM = “manager of the whole Visual C# team”) and IDE
Program Manager Anson Horton will be showing off many of the new IDE features for
the C# programmer, including refactoring and data visualization.
Visual C# "Whidbey": Language Enhancements
Tuesday 3:45PM – 5:00 PM
Anders Hejlsberg, distinguished
engineer and lead architect for the C# compiler, will be presenting on the new
C# language enhancements, including generics, iterators, anonymous delegates, and
Discuss the two C# talks, or other topics
Tuesday 5:00 PM - ?
Room: Tools and Developers Lounge (Level 2 near room 309)
After Anders finishes his talk, the team will be available in the Tools and Developers
Lounge (which I’m told is out in the middle of one of the concourses) to answer questions
about C# or about either of the C# talks. Scott, Anson, and Anders will be available,
as will other C# team members.
Visual Studio "Whidbey": Advanced Debugging Techniques
Tuesday 5:15PM – 6:30 PM
Visual C# Debugger Program Manager Habib Heydarian will show off the new features
of the Whidbey debugger.
Ask the Experts
Tuesday 7:00 – 9:00 PM
Room: Expo Hall? (I think - don’t quote me on that one)
The C# team will be out in force for Ask the Experts, as will the rest of the Microsoft
teams. If you have a hard problem to solve or a tough question to get answered, this
is a great place to spend some time.
1:00PM – 2:00PM Book signing,
Scott Wiltamuth & Anders Hejlsberg
hall book store)
Scott and Anders have recently finished “The
C# Programming Language”, the C# specification in book form.
3:00PM – 4:00PM C# Developer
Lounge (Tools Lounge)
The C# team will be hanging out in the tools lounge for this hour. Please stop by
with questions, or just to chat.
1:45PM – 2:45PM Panel: Future
of .NET Languages, Anders Hejlsberg
A panel discussion on where .NET languages are going.
6:00 PM LA
.NET User Group Meeting,
Nalewabau, Shaykat Chaudhuri
Joe and Shaykat are Program Managers in the Visual C# team.
A while back, I wrote about
having copies of translations of my book that I didn't know what to do with. A few
of you wrote that you would like copies. Here's what I've decided to do:
I'm going to give away the foreign copies to anybody who wants them, with the following
1) It can't be too much hassle on my part. Too much hassle involves lots of trips
to the post office, dealing with customs, or tapdancing on a bar while singing "what
do you do with a drunken sailer".
2) You'll cover any postage necessary
3) If you're coming to PDC, I'll bring it with me. In fact, since doing that will
likely be less of a hassle, I'll give priority to those requests.
4) You'll agree to write me a paragraph telling me what you're doing with C#.
Interested? Send me email at, telling me
what version you're interested in.
On July 20th, 1969, a 5-year-old boy living in Caldwell, Idaho stayed up past his
bedtime to watch a very grainy television transmission of Neil Armstrong's first steps
on the moon, which cemented an interest in space that has lasted over the decades.
Since that time, I've watched coverage of countless space missions, but until I got
access to NASA TV a couple
of years ago, I only got what the networks wanted to show me (not that NASA TV is
particularly good - you would get better production values from a high school AV class.
NASA continues to make a huge mistake in not doing decent programming). Networks often
miss the interesting stuff, and with the exception of a few specials, few people have
seen the the archival footage that lurks in NASA's vaults.
Spacecraft films was founded
to solve that problem. They have spent time going through tons of footage from the
Apollo 11 mission, and have produced Apollo
11: Men on the Moon, a 3 DVD set with over 10 hours of content. I have yet
to watch all the content, but they've taken a very innovative approach. For the launch,
you can watch simultaneous views from 5 different tracking cameras, synchronized with
the audio. For the touchdown, there is the single video taken from the LM, but with
4 different choices for audio. You can listen to CAPCOM talk to the astronauts, or
you can listen to flight director Gene Kranz (author of the excellent Failure
is not an option) as he talks to his flight controllers, as they work through
computer problems during the landing, or you can listen to all of them at once in
a 5.1DD mix (though the multichannel is marred by one very noisy channel). During
Armstrong and Aldrin's moonwalk, they've overlaid the TV video with a one-per-second
16mm film, and the excellent 70mm still camera shots.
If you're a space buff, you need this set.
I enjoy giving presentations - there's something about being up in front of a crowd
that is very powerful, especially when they're laughing.
But I wasn't always like that. In fact, throughout high school and college, I avoided
those sorts of situations as much as possible. When I got out of school and started
working (at Boeing Computer Services, doing engineering graphics), I decided that
being able to speak in public was a skill I wanted to have. Boeing sponsored a Toastmaster's chapter,
but that seemed like an artificial situation (I told myself). To be honest, it
was probably more that deciding to do something like that is a big move,
so I put it off.
One day, a fellow motorcyclist who I had taken a motorcycle safety course
from suggested that I become an instructor for MSF.
That seemed like a great idea - I could learn to speak, teach people to ride better,
and make a little spending money (very little, it turns out). So, I sent in an application
and was accepted to the 1990 instructor class.
Though the format has changed since then, at the time the course ran for 8 days straight.
You started with 6 days of covering the beginning
rider course in excruciating detail. For the classroom sections, you walk
through what you need to present and do short practice sections of presentation. For
the range (ie riding) sections, you learn how to present an exercise, how to demo
an exercise, where to stand, what appropriate coaching is, how to get the students
to do what you want, and how to keep track of time. You'll spend 8 hours a day on
this, plus 4 hours at night studying.
Then, on Friday night, an unsuspecting class of students shows up to be taught by
the instructor candidates, with your chief instructors there only to observe (and
to rescue you if you really screw up).
The result is not pretty.
The classroom sessions go pretty well - the curriculum is very good, and even if you
just read the talking points and show the videos, the students will do well. The range,
however, is another matter.
MSF courses teach skills in progressions - the students learn one skill, and then
the next exercise builds on that skill. A cornerstone of that approach is that students
need to actually *learn* a skill before they go to the next exercise. Unfortunately,
it requires skilled instructors to ensure that, and we were far from skilled. We chose
exercises to lead by lot, and I drew exercise 11, which is titled, "Shifting and turning
on different curves(3) and shifting and making sharp turns". It requires the students
to put together actions smoothly and in the right order on an intimidating course.
It's very, very useful in a well-taught class, but for me, it turned into the exercise
from hell. To get a passing grade as an instructor, the students need to achieve the
point of the exercise, and the combination of them not getting good instruction and
my inability to keep them in the right path of travel meant that it was pretty much
a foregone conclusion that I would not get a passing grade on that exercise. Luckily,
I had passed my first classroom section, and I only had one more range exercise to
teach, "stopping in the shortest distance", which is pretty much impossible to foul
up as an instructor. So, I passed the course, though it was incredibly intense. That's
to make the real courses seem easy.
After a while, I started teaching the classroom section by myself. The courses only
have 12 people in them, so the size isn't that intimidating, but you have to be "on"
the during the whole course. Over time, I got so that I really enjoyed teaching the
courses, though I had to give them up recently because of other time committments.
Onto C# Land. The original C# team was part of the VC++ team, and we had 4 devs, 5
testers, and one PM working on the compiler, plus Anders and a couple of other people
on the design team. After we announced C#, there was a ton of call for talks on the
subject, and limited resources, so I started doing talks (one of the nicethings about
MS is that I was able to do talks even though I was a QA lead, not a PM). In one quarter,
I did 23 talks on C#, and found that I was a bit of a ham when I got up in front of
If there's a point to this story, it's that if you want to get good at something,
you need to just do it. But try not to start in a the "Rock Star"-talk-to-3000-people-at-PDC
I've signed up to do a "C# for the Java Programmer" presentation on campus the week
after PDC. I have some ideas for what I'm going to cover, but I'd like your input.
What topics are the most important in this talk? What was the most non-obvious thing
that surprised you about C#?
This is not the newest manifestation of the "Dress Casual" trend.
at Work (And Other Fears): How to Stay Sane When Your Job Drives You Crazy
Is a book that I've been reading. It's a self help book, but not the "do these things
to make yourself better" vein. More in the "this is why the world seems to be the
way that it is".
I picked this up at the library because I liked the title, and I was happy to find
that it has a fair amount of wisdom in it. For example, just because we think about
ourselves all the time does not mean that other people think about us all the time.
That means if our boss sounds grumpy when he meets us in the hall, it's much more
likely that he's not grumpy about us, but about other, more important things in his
The big surprise for this book - based on my assumption that the title was dreamed
up by the publisher to sell more books - was that it is genuinely funny. Paul Hellman
has a style that is not unlike Dave Barry's, and in my book, that's a pretty good
place to be. Here's an example of an anecdote from the book:
Anecdote #20: Traffic Item in the paper: A union debate whether to block rush
hour traffic to "draw public attention to worker' gripes." Is there a connection between
rush hour traffic and workers' gripes? I think yes! I'm a worker, and one of my main
gripes is -- rush hour traffic. Maybe the union's motto should be, "We're not going
anywhere and neither are you." But I doubt the public would react favorably: "This
traffic is driving me NUTS!!! And yet -- it's also increasing my sympathy for workers'
gripes!" Anyway, it doesn't really matter. You can't block rush hour traffic. It's
already blocked! That's the whole point of rush hour traffic. If the union really
wants public support, they should figure out a way to unblock it.
When we first added XML doc comments to C#, we thought that using them would give
us much more accurate documentation, as the developers would update the docs when
they changed the code. This works pretty well for small libraries, but if you have
a UE group that works on your docs, it's pretty inconvenient for them to have to check
out your source files to work on docs.
So, we added an "include" syntax that lets you keep the docs in a separate file, which
the compiler then reads to get the actual xml to use.
This is all documented here
Bellevue is a hilly place. It's perched (roughly) between two large bodies of fresh
water. Lake Washington, to the west, is something around 10 or 15' above sea level,
and Lake Sammamish, to the east, is about 40' about sea level.
What that means for me is that if I'm going riding, I'm going to be riding up and
down some hills. Some are steep hills, of the "I'd really like to stop now, but if
I do I fear I will merely fall across the road and lie there until some vehicle approaches"
variety. Others are less steep. As I was suffering going up one of these hills, I
thought it might be fun to know exactly how steep it is (cyclists have weird senses
of humor, and love/hate relationships with hills). A few web searches led me to this inclinometer,
but being the techie that I am, it didn't seem cool enough, so I did a bit more research.
Hills are measured in terms of gradient, which is merely the rise of the hill over
the run. If you're going up 2 feet for every 100 feet you travel, you're on a 2% hill.
As an aside, it turns out that humans are great at overestimating the steepness of
hills. It's easy to think that some streets are nearly 45 degrees (100% gradient),
but it turns out that the steepest streets around Seattle (and we have some steep
ones) are a 21% gradient, a mere 11 degrees. Take out a piece of graph paper,
and draw a triangle that's 10 units long and 2 units high. Take a look at that, and
then try to reconcile it with the streets you've been on. Doesn't make much sense.
Anyway, what I was looking for was a way to measure the gradient of the streets I
was on. To do that, I needed a way to set a reference point, move forward, and then
figure out the delta in distance and altitude. If you're thinking GPS, you're right
on the button. This finally gave me an excuse to order a data cable for my Garmin
Etrex, and yesterday afternoon I did a little drive on some hills with the GPS on,
came home, and used a gps utility program to download the data, extracted it to a
text file, imported to excel, it did some graphing.
The result was fairly good, actually, except for the fact that the Etrex only saves
data every once in a while (to save memory space), so in a car, the samples are too
far apart to get a good reading. This wouldn't be a problem climbing on the bike,
but might be when descending. I can get around that by taking the laptop with me
and saving the location every second, which should give me more than enough resolution
to get some good data. GPS isn't great on absolute position, and is even less good
on absolute altitude, but it's quite good on relative measurements of both of those.
I'll have to write a C# utility to run on the laptop, of course, so that I don't have
to do all the ugly massaging and export. I might eventually buy a GPS for my pocket
PC, as there are some small ones that fit in the compact
A nice post
I got an email from a customer today, in which he noted that the C# compiler allows
you to write:
bool b = ...
despite the fact that the spec does not list bool as one of the types
that you can switch on.
Unfortunately, we've shipped the current behavior, and one of our high-order goals
is not to break existing code by changing the compiler. In most cases, that's a really
good goal, as your customers are justifiably upset when the new compiler breaks their
In this case, however, I think we may be going to far in not fixing a bug because
there's a chance somebody might have written code that used it. I'm therefore looking
for your opinion (noting, for the record, that it seems that I could sometimes be
replaced by an auto-blogger question-asking piece of software) on what makes the most
How would you have us trade off language conformance (and perhaps language innovation)
vs language stability?
More specifically, when is it acceptable for the compiler to give an error on code
that used to work?
C++ has deterministic finalization. When you declare a stack-based object, at the
end of the scope, the destructor is called before other work is done.
I just finished writing a response on this topic for a customer, and thought I'd share
my favorite reference on the subject with you:
Comcast is planning
on raising its maximum download speed to 3Mbps.
Hope it happens in my neck of the woods...
I've had a couple of questions recently about how to architecture libraries with respect
to exception handling, specifically related to exception granualarity. Questions like:
The first place to start is the Error
Raising and Handling Guidelines from the Design
Guidelines for Class Libraries. There is lots of useful information in the design
guidelines even if you aren't writing libraries. The guidelines do mention something
like "don't use return codes", but that's about it.
One of the high-value design points when designing exceptions is robustness. The robustness
of the customer's code depends directly on the way you structure your exception hierarchy.
Here's some code that I've seen. Assume that ApplicationException is the actual type
I'm catching, not the base type of a hierarchy:
// code here...
catch (ApplicationException e)
if (e.Message.IndexOf("Database Connection Error"))
// recovery code here
There are at least two problems with the code, one major, and one a bit more subtle.
Do you see them?
I'll start with the more subtle one first. If your exception messages are localized,
it's likely that the string matching will fail. This is a bad bug, because it only
shows up in the localized version in an error case, and your tests aren't very
likely to catch it.
The second bug is a whopper. If the exception that comes in isn't a
database connection error, it is swallowed by the catch block, never to be heard
from again. That's pretty much the worst thing that exception handling code
The problem is that the exception design has forced the user to look inside the
exception to decide what to do. This is bad, whether it be the message text,
a return code, or the type of an inner exception that the user is looking for.
To prevent this, I'd recommend the following guideline:
One way to determine this is to ask yourself, "Self, would a user ever care about
the different cases where ApplicationException is thrown?" In some cases this
is obvious, but in other cases, it's not quite so clear. My recommendation is
that you err on the side of more granularity rather than less granularity.
Apparently, I'm "on the Cluetrain",
though strangely, I don't recall boarding, or even buying a ticket.
There are some interesting points here, and I do think that VS has focused mostly
on the "edit and build" side of software development, without taking a larger view.
Will that change in Whidbey? I think you'll have to wait and see.
On Tuesday, I asked a question about whether people keep their form class names and
form filenames in sync. I'd like to thank all who responded, and provide a little
background on the issue. To do that, I'll have to explain a bit about our internal
development a process.
Many of you have probably encountered the problem of "feature creep", where new features
keep showing up during development. Feature creep is bad because it throws of your
completion estimates, makes it hard for your test team to know what you're planning
on building, and generally annoys people. It's especially bad when you have a lot
of interdependent teams, and the new feature isn't something you want but rather something
somebody else wants, and it gets worse if there are multiple teams depending on you.
One way to deal with this is to say, "No new features", after you reach a certain
point in your release cycle. That would work great if planning was perfect, but it's
fairly common to find out that a planned architecture has technical problems, or a
new customer need comes to light, or somebody has a great idea, or a usability study
shows that your current approach flat-out sucks. Not to mention the "we didn't think
of that" factor, which we try to minimize but cannot eliminate.
Our approach is to provide a standard process known as a DCR (Development Change Request).
In a DCR, the PM who owns the feature gets to produce a document that describes:
This usually involves a considerable amount of research by the team, as it's really
important to understand the subject deeply, and the research often involves more than
Once the DCR is written up, the PM (and usually other involved parties) meet with
the management team of their product (in our case, it's our PUM, our dev manager,
our qa manager, and our group program manager) to present the DCR. The management
team will either approve the DCR, reject the DCR, or ask for more data.
In this specific situation, the problem that we're trying to address has to do with
the build system. If you've looked at the PDC
session abstracts, you may have come across mention of something called MSBuild.
MSBuild is a new build system that isn't coupled to the VS project system, which means
you'll be able to build your Whidbey projects from the command line without loading
If you've gone spelunking in your windows forms files, you may have come across a
line that says:
System.Resources.ResourceManager resources = new System.Resources.ResourceManager
Behind the scenes, the Windows Forms designer has put some form resources in a .RESX
file. These resources will get converted to a binary format by resgen.exe, and then
put into the assembly as part of compilation. Since there may be multiple forms in
one assembly, there needs to be a way to find the right resources for a form. For
Windows Forms, the full name of the class was chosen as a key. The project system
finds this out by talking to the Code Model, a sort of "mini in-process compiler"
that also parses code for intellisense and other IDE features (if you read the
PDC session abstracts closely, you'll find a new feature...). The code model tells
the project system what the name of the form is, and this is passed to the compiler
and used to name the binary resource blob in the assembly.
The resource manager constructor gets that same name from the type passed into the
constructor, uses it to find the correct blob, and things are hunky and hopefully,
dory as well.
Enter MSBuild. It seems like a good idea to be able to build windows forms projects
in MSBuild, but there is a problem.
There is no code model for MSBuild to ask for the form name, and no facility to find
that information, so it's DCR time. We've spend the last few weeks talking about different
options to solve this, but none of them are great, and we don't have a single candidate
that we all like.
One of the front runners has the bad characteristic of requiring a project file checkout
whenever the form class name is changed, which could be a problem if the project file
is already checked out exclusively.
If our users typically rename the form file when they change the class name, then
the issue is largely moot, as that rename would also require a project file checkout,
and that's why I asked for your feedback.
Several of the comments talked about the poor state of rename in VS (ie, you can't
do a VSS rename from inside VS). I talked with the VSS PM, and he said that they are
planning to do rename for Whidbey. Please read that as, "It's likely to show up, but
don't get mad at Eric if it doesn't, as it's not his call". I did convey the feedback
I got about the quality of the current solution.