-
I was cleaning out some old mail and came across this tip. You can tell it was a long time ago, because it really only matters if you're writing COM objects, something I haven't done in a long, long time.
Some parts of Visual Studio use COM as a layer to handle cross-thread calls and enable cross-machine remoting. One of the downsides of this technology is that a COM exception in a server is caught by COM and converted to an HRESULT. That HRESULT is harder to notice & catch in a debugger than the original exception.
However, there is a registry key that will change this behavior. When this key is set, the exception is passed through normally, and can be detected & debugged through normal mechanisms.
The key is:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole]
"IgnoreServerExceptions"="Y"
(The real reason I'm blogging this is so that I can find it in the future if I ever write COM again. :-))
-
At work I've been playing with
Windows PowerShell. I could try to describe it, but Wikipedia has already done a better job:
It blows my mind how cool it is. Unfortunately it also, uhh, fries my brain because I don't know how to use it. I'm a cmd.exe expert. Seriously, I know way, way too much about writing CMD scripts, to the point where most people can't keep up. I don't want this knowledge, and I see that PowerShell may give me freedom from the burden of the knowledge.
My biggest annoyance is that it's not universally available. I want to be able to sit down at any machine and just start using PowerShell, not having to worry about installing it (and the .Net Framework) first. I want to be able to offer .PS1 scripts for anyone to use, without them having to jump through the same hoops.
Too bad it missed the Vista train. That means it'll be 10 years before it's everywhere. We'll get there.
-
First, go read this article by Joel: Book Review: Beyond Java. He mentions this list, of great advances that have address some accidental difficulties in software:
- Assemblers
- Algebraic languages (including Fortran)
- Structured languages (Algol-60 and C)
- Declarative languages (including SQL)
- Memory-managed languages (including Lisp, VB, and Java)
First, I'm disappointed he didn't list C# next to Java in #5. By no means did Java (or VB) invent automatic memory management (garbage collection). Perhaps you would give those languages credit for bringing managed memory to the masses, but in that case, C# belongs on the list.
I remember a very interesting discussion here a couple years back, about this very topic. Cyrus was saying that at some point we'll expand the domain of the Garbage Collector to non-memory entities, like files, database connections, etc. Sure, figuring out of it's time to dispose of those things is hard, but computers are getting more powerful, and we'll eventually build that in to our programming systems.
So, think of all the times you have written 'using' statments in your code, and consider the possibility of a language that made them unnecessary.
-
I've been engaged in a bunch of discussion about how to keep your personal data safe at home. I hear a lot of people say they want to build a RAID5 array in a server, and put their family photos on it.
I can think of many ways to lose my data:
- Hardware Failure
- Fire, earthquake, or other natural event
- Power surge
- Theft
- Confiscation by police
- Virus, Trojan, or other malware
- Accidentally deleting it
While all of them are potentially real, only #1 & #7 are actually likely to affect my data. In my lifetime, I have lost data to #1 & #7, and never to #2-#6.
RAID5 and the like only protect against #1, and even then a dying controller can nuke your data.
Seriously though, my biggest fear is that *I* will delete my data.
The only way I know to protect against all of them is to have an offsite and offline backup. (Even that may not be enough for #5.)
To that end, I keep an external drive at work, disconnected. I update it periodically. Luckily this is simple enough for anyone to do. (You probably need to be selective about what you back up this way, to keep it all on one drive).
Another strategy that complements this one quite well is to provide mutual data duplication with a friend or relative in another part of the world. The further, the safer. Foldershare makes this doable.
-
From a previous comment:
> A copy of the source tree that exactly matches that test VS.
Why IDE unable to keep track versions of sources for me ?
Why not embed meta-information in PDB's on how and there to retrieve correct source file version ?
Actually, it does. In VS2005, the debugger team added two features along these lines. The first is "source file checksums", described here: http://blogs.msdn.com/andypennell/archive/2004/06/29/169002.aspx
The second is Source Server, described here: http://msdn.microsoft.com/msdnmag/issues/06/08/UseTheSource/default.aspx
However, the problem that I'm dealing with is a little more complex (and much less likely to occur in the wild). On my dev machine, I need a copy of Visual Studio and the sources that built it, so that I can modify the sources, build one component, and try it out. If the sources I start from don't match my copy of VS exactly, then I can't know which changes in behavior are due to my changes. Furthermore, if interfaces have changed, then the product is likely to stop working entirely.
Does that explain things?
-
Quiet here, huh? Been busy, including a 12 week parental leave.
Now that I've been back at work a couple weeks, I can tell you what I've been up to.
I'm no longer on the C# or Debugger teams. I have a new gig.
The neat thing about working on development tools is that we write code for people who write code. It's meta-software-development.
Now I'm doing meta-meta-software-development. The devs that write Visual Studio need tools to make their jobs easier, and that's what I get to do now.
For example, in order to set up a machine to develop VS, you need:
- An instance of VS that is fast (optimized), and stable
- An instance of VS that is current, easy to debug, and probably has a bug that you're about to fix
- A copy of the source tree that exactly matches that test VS.
- A variety of tools, like bug tracking and profiling.
My plan is to make setting up a machine this way foolproof, so the devs don't have to worry about it any more, and focus their attention on making great features.
Good news: I get to write my tools in C#! That means I'll be using what I spent the last few years building.
-
We're at the point in the process for VS2005 where there is basically no work left for devs to do. (The product hasn't shipped yet, but devs are not busy.)
Before starting the next product cycle, there are a few things that we're doing differently. One of them is "transition time", a form of slack. The end of a product cycle is always a lot of hard work, with a lot of pressure. We strive for maximum efficiency, and a lot of other important things get pushed off. The slack time is a chance to restore balance.
The first part is 7 days of self-directed time. These are work days, but there is nothing scheduled. Different people are doing different things:
- Talking to teams that are exploring long-lead ideas about new technology
- experimenting with retrofitting our legacy code for unit tests
- cleaning & rearranging their office
- building applications with VS2005
- reading
I have been reading the new XP book (Extreme Programming Explained: Embrace Change, Second Edition, by Kent Beck). Combined with the first edition, it's very good stuff.
I have moved in to a new, larger office. I'll have to get some pictures to share & gloat.
my side project
I have been working on my side project, which is written in C#. It's not something that would be useful outside of Microsoft, so I won't go in to details about what it does.
I always wrote it in C# 1.0, so I could deploy on the 1.0 CLR. However, I can soon require my users to install the 2.0 CLR without it being draconian. It's really nice to be able to use generics and anonymous methods.
It's a command line app, and I've always struggled with the command line parameter handling. What does a good syntax look like? How should I parse it? I've been rewriting the parser in a more generic way, so it's easy to expand the syntax as the tool grows.
The original implemention has sparse unit test coverage. Of course, retrofitting is hard; your code is no longer well-factored.
However, the new lexer & parser were implemented from scratch, in isolation, and done test-first. I've been using unit testing for TDD, as well as using FIT for acceptance testing. A powerful combination. I just wish I had a pair to make up for all my pesky weaknesses.
The second part is 3 days of comp time (days off), where we get to meet our families, rest, go sailing, etc. Not sure what I'll do with that time... we'll see.
-
After a few years working on the C# IDE, I have moved to a new job. I am now the development lead for the Visual Studio Debugger. This was Andy's job before he left to work on Windows Media stuff.
This sounds like a bigger change than it is. I have the same boss (Steve), I'm still in the C# Product Unit (although the debugger is for all languages), and I'm on the same floor of the same building. When Andy left, I took on two of the debugger devs as their acting manager, so even that stays the same.
For those playing along at home, my reports with blogs are: Gregg, Steve, Raj, and Jim.
The C# IDE team is now led by Mike, who previously was a dev on the C# compiler. Congratulations, Mike! I'm confident he will do a great job with that great team.
-
There was an interesting Ladybug issue suggesting that we release a Beta 3 & slip VS 2005.
This is a politically sensitive issue. It has generated some press, so I want to be careful about what I say here.
I'm very glad that Clint took the time to provide us this feedback, and want to say thanks to everyone who commented and/or voted on the issue. This is excellent feedback.
I do want to comment on a few things.
"many issues get resolved as Postponed." That's concerning to me. It's normal for us to ship a product with many known, unfixed issues. This is mostly because our testers do such great work (finding lots of issues that we can ship with, and still have a great product), not because we're shipping too soon (with issues that will cause lots of customer pain). I have a very high standard for the quality of our software, and I hold my team to that standard. I've seen a lot of non-Microsoft software that was surprisingly bad, and which just tells me that we're doing a good job with reliability here.
That said, I know that we have gotten this wrong, too. We have shipped some broken software in the past, so it's possible (likely!) that we would make the mistake to ship something broken again in the future. We need to admit that we can make mistakes, and do the work to make sure we're making the right choices here.
One of the interesting things that I've learned in my Shiproom role is that most of the perception of poor quality is not due to bugs, per se. It's not about whether we introduced a bad bug late in the product & decided not to fix it, or didn't even notice it. It's about design decisions made early on that cause problems we don't fix. You can see that in the discussion of this Ladybug issue. There's a lot of concern about the project-less model for the Web Developer. This isn't a bug, it's a design decision that we made a long time ago.
Well, I think I'm rambling. Thanks for all your passion about the quality of VS, and for putting in the effort to give us your feedback. We love it all.
-
Today I got to present a bug in Developer Division shiproom. I haven't gotten to present since Beta 2, as ScottNo has being doing it for C# all this time. He's doing a fine job, but I get a real rush out of it. I like the feeling of having all the answers lined up and presenting well.
It comes from a lot of hard work beforehand, of course. I spend a lot of time studying the bug and asking the developer & tester some hard questions:
- If we created this bug, does that mean we made similar mistakes elsewhere?
- Are there more bugs waiting here?
- If we were confused about this before, why do we think we can get it right this time?
- How long has the bug been in the product?
- If test didn't find the issue before now, why do we think we can confidently test the fix?
- If test didn't find the issue before now, how many other bugs have they not yet found in the area?
- If we know there are more issues in the area, will fixing this really improve the customer experience, or will they still think it's junk?
This particular bug had been in the product for 14 months before we found it. It's clear that no one had ever executed this broken line of code - not dev, not test.
One of the hard parts about this decision is that, while the scenario was in the "design time" (it affected debugging), the fix was in a "platform" component (the C# compiler). If we get it wrong, we could potentially break the .Net Redist, every app that you create in C#, cause the CLR to miss its stress-test goals, and cause Whidbey to slip. (I don't think any of this will happen, but it's good reason to choose carefully.)
There were 7 reports of the issue from Beta 2 customers. That was a factor in deciding to take the fix. Thanks for hitting "Send Report" on a hang, folks!
-
For Whdibey Beta 2, I took on a new responsibility, called the "shiproom" role. There's a couple different parts to it:
- Along with reps from QA & PM, we consider every C# PU bug. (PU=Product Unit. The C# Product Unit is responsible for the Visual Studio Debugger, C# Editor, and C# Compiler).
- Help present those fixes to a Developer Division shiproom. (DevDiv = all of Visual Studio & NDP). Only if they approve will we check the fix in to the source tree.
I continue to play that role as we move to ship Whidbey RTM. The PM was previously Shaykat, but is now Scott. The QA was previously Kartik but is now John (neither have blogs, I'm afraid.) As a result, I need to work to provide consistency between releases (Beta to RTM).
Both my new cohorts are different than the previous person in that role (duh) and bring unique value to the process.
It's time consuming, tedious, and often exciting (well, for me). And I know that it's very important to helping us ship a great product.
-
11 August: C# language.
25 August: C# IDE. (This is what my team does)
See the C# chat page for more info.
I probably won't be there, because my hands are full with Shiproom.
-
Kevin was working from his home on Mercer island this afternoon. We were using Microsoft Office Communicator to talk about a bug. This bug was particularly annoying: there were Watson reports indicating that it was getting hit at a lab at Microsoft, presumably while they were running automated tests. But we couldn't figure out what they were doing, or even who they were.
Late last week we managed to track down someone on the team running the tests, and about an hour ago they told us what they were doing when the crash happened.
I was chatting with Kevin about this bug, trying to make some guesses as to what was going on. Then we had the following conversation:
Kevin Pilch-Bisson [6:50 PM]:
Redmond: We have a repro.
Kevin Pilch-Bisson [6:50 PM]:
<repro steps removed, sorry>
Jay Bazuzi [6:51 PM]:
Mercer Island: Say again? You have a repro?
Kevin Pilch-Bisson [6:51 PM]:
We have a repro.
Jay Bazuzi [6:51 PM]:
Mercer Island: Confirmed, you have a repro. Stand by.
Jay Bazuzi [6:51 PM]:
Hmm, I had a beer.
Kevin Pilch-Bisson [6:52 PM]:
Where did you have a beer?
Jay Bazuzi [6:52 PM]:
There was some catering in a conference room.
There's a good reason not to drink at work.
The repro has to do with running 'devenv /build'. We're now able to reproduce the issue reliably. I think it's a pretty bad bug, and I want to see it fixed in Whidbey. That means going to Ask Mode to get permission to make a fix.
-
In a Microsoft internal discussion, someone asked for Set functionality in a collection. I threw this together.
What do you think? Useful or no?
using System.Collections.Generic;
using System.Diagnostics;
class Set<TItem>
{
Dictionary<TItem, bool> _list = new Dictionary<TItem, bool>();
public bool Contains(TItem item) { return _list.ContainsKey(item); }
public void Add(TItem item)
{
if (!Contains(item))
{
this._list.Add(item, false);
}
}
public void Remove(TItem item)
{
if (!Contains(item))
{
// TODO: pick a better exception type
throw new System.Exception();
}
this._list.Remove(item);
}
public int Count { get { return this._list.Count; } }
}
class Test
{
static void Main(string[] args)
{
Set<int> set = new Set<int>();
Debug.Assert(set.Count == 0);
Debug.Assert(set.Contains(1) == false);
set.Add(1);
Debug.Assert(set.Count == 1);
Debug.Assert(set.Contains(1) == true);
Debug.Assert(set.Contains(2) == false);
set.Add(1);
Debug.Assert(set.Count == 1);
Debug.Assert(set.Contains(1) == true);
Debug.Assert(set.Contains(2) == false);
set.Add(2);
Debug.Assert(set.Count == 2);
Debug.Assert(set.Contains(1) == true);
Debug.Assert(set.Contains(2) == true);
set.Remove(1);
Debug.Assert(set.Count == 1);
Debug.Assert(set.Contains(1) == false);
Debug.Assert(set.Contains(2) == true);
}
}
-
We've started a new-to-us practice around here: The weekly P1 ZBB.
Each bug in our bug database gets assigned a priority:
0 - drop everything and fix this, because people are completely blocked because of this.
1 - really important bug that we really need to fix, and preferably soon. crashes/hangs/major functionality broken
2 - important issue in the product. We will fix nearly all of these before we ship
3 - polish issue. We will fix many of these, but certainly not all.
4 - suggestion. We'll fix as time allows.
As we work through the bugs on our way to RTM, we want to make sure we stay focused on fixing the right bugs. Bugs should usually be fixed in priority order.
- P1 bugs usually obscure other less important issues
- When a product has plenty of P1 bugs, you're not likely to bother reporting more minor issues
- Fixing P1 bugs usually has the biggest impact on the value of the product to customer
- P1 bugs interfere productivity - testers can't test, internal users can work, developers on the team have to work around issues.
To help keep the team focused on doing this, we driving to fix all priority 1 (P1) bugs by the end of each week. To stop it from being too randomizing, we only include bugs opened before Wednesday.
