kevinpilch-bisson's WebLog

I’m speaking at Seattle Code Camp this weekend.

2008-11-14T05:08:07Z

This Saturday from 2:45-4:00 I’ll be giving a talk on “What’s coming up in VS2010 for C# Developers?” at Seattle Code Camp. I’ll mostly be showing off some of the new features we’ve been working on for VS2010, especially those related to the C# editor. I’d love it if you stopped by!

Hotfix for VS2008 SP1 Available

2008-10-31T03:34:35Z

In VS2008 SP1 our team added a significant new feature: live semantic analysis of open files (or “background squiggles” as we called it internally). Unfortunately, soon after release we found a few small issues with the release. They are:

Incorrect errors when you open a solution with breakpoints in .aspx.cs files.
Incorrect errors regarding conversions of constants in rare cases.
An issue importing metadata from some non-C# assemblies.
Some timing issues where errors would appear and then disappear during typing or file/solution opening.

We spent some time analyzing the issues, and we’ve come up with a hotfix to address them. If you’re seeing any issues where you get live semantic errors that you don’t expect, please download this fix and try it out.

Let me know if you find any issues with it!

Thanks!

CodeRush Xpress for C#

2008-10-28T21:13:07Z

Yesterday at the PDC, Dustin announced the availability of CodeRush Xpress for C#. This is a free addin for VS 2008 that provides a whole bunch of fantastic editor productivity features. Download it today and give it a shot!

Removing elements from a Dictionary

2008-10-28T03:42:23Z

The topic of removing elements from a dictionary came up recently on an internal mailing list. Someone was iterating through all the elements of a collection and wanting to remove some of them. The problem with that is that modifying the collection underlying the enumerator throws. He had the following pseudo code:

void RemoveSomeElements(Dictionary<string, int> dict)
{
    foreach (var e in dict)
    {
        if (e.Value < 35)
        {
            // Remove e!
        }
    }
}

Several people replied that he could just create a list of elements to be removed and then iterate that afterwards:

var keysToRemove = new List<string>();
foreach (var e in dict)
{
    if (e.Value < 35)
    {
        keysToRemove.Add(e.Key);
    }
}

foreach (var key in keysToRemove)
{
    dict.Remove(key);
}

That works, but it’s pretty verbose. Someone suggested a more functional way to do it that’s pretty nice:

dict.ToList().Where(pair => pair.Value < 35).ToList().ForEach(pair => dict.Remove(pair.Key));

At this point I decided to show off, and make it more efficient by using an “Apply” extension method instead of the .ForEach method that shipped on List<T> in .Net 2.0. I came up with this:

dict.Where(pair => pair.Value < 35).Apply(pair => dict.Remove(pair.Key)).Apply();

Along with the code to Apply:

public static class ApplyExtensions
{
    public static IEnumerable<T> Apply<T>(this IEnumerable<T> source, Action<T> action)
    {
        Argument.NotNull(source, () => () => source);
        Argument.NotNull(action, () => () => action);
        return ApplyInternal(source, action);
    }

    internal static IEnumerable<T> ApplyInternal<T>(IEnumerable<T> source, Action<T> action)
    {
        foreach (var e in source)
        {
            action(e);
            yield return e;
        }
    }

    public static void Apply<T>(this IEnumerable<T> source)
    {
        foreach (var e in source)
        {
            // do nothing, just make sure the elements are enumerated.
        }
    }

}

Here I thought I was doing right by C# 3.0, and showing people how to use lazily chained iterators. Unfortunately, this code drops us right back to the original problem! Because of lazy iteration, we’re actually still iterating the dictionary when we try to remove the elements, and so we invalidate the first iterator in our chain.

It’s a simple fix, but still a reminder that the semantics of delayed execution can be tricky to reason about sometimes:

dict.Where(pair => pair.Value < 35).ToArray().Apply(pair => dict.Remove(pair.Key)).Apply();

The “ToArray” call finishes the iteration of the dictionary, but uses less space than the original “.ForEach” solution, since we only realize a collection of the elements to be removed, instead of all of the elements in the dictionary.

ArgumentNullException and refactoring

2008-10-27T17:58:51Z

I hate using strings to represent program elements! One of the big problems is that it hinders automated refactoring. Strings don’t have any semantic meaning, so refactoring tools don’t know which references to the string need to be updated.

While playing with expression trees, a while ago I came up with this:

public static class Argument
{
    public static void NotNull(object value, Expression<Func<Func<object>>> arg)
    {
        if (value == null)
        {
            var body1 = (Expression<Func<object>>)arg.Body;
            var body2 = (MemberExpression)body1.Body;
            throw new ArgumentNullException(body2.Member.Name);
        }

    }
}

You can use this for argument validation like this:

static void Main(string[] args)
{
    Argument.NotNull(args, () => () => args);
}

This looks a little strange, but has some interesting properties:

There are no strings, which means that refactoring tools “Just Work” and update all references.
The majority of the reflection code happens only in the exception code, which means that this has significantly better performance than my first attempt (which took just an “Expression<Func<object>>”

On the other hand it has some drawbacks too:

The calling side looks a little strange with “() => () =>'”
Using this approach will lead to a LOT of compiler generated display classes to store the parameter references.

I’m not sure I would use this in production code, but it was an interesting exercise to come up with a way of validating parameters that doesn’t involve strings.

What do you think?

Virtualization Update

2008-10-27T17:38:08Z

Just a quick update. After my previous post, I actually stopped using virtualization for most cases, since I found the performance hit to be too significant. While the automation I mentioned before still doesn’t support HyperV, I hand built a couple of VM’s with it and I have to say that I’m quite impressed.

On my host machine, it takes about 8 minutes to do a clean build of the code I usually work on. With my previous virtual machine, it took about 32 minutes! I think this happened because while my host machine has 4 processors, the VM can only access one of those. I wasn’t willing to pay that price. With HyperV today it takes about 9.5 minutes, and I am willing to pay that price for the added flexibility and the time I can save installing builds.

Getting on the virtualization bandwagon

2008-08-15T17:55:46Z

Lately I've been trying to support work happening in a variety of our development branches, and that's been challenging to the two machine setup I mentioned here. Visual Studio (unfortunately) takes a long time to install and uninstall. Also during our development cycle uninstall is sometimes broken. That means that people often re-image (at least) their test machines whenever they need to install a new build of Visual Studio.

In order to do work in three different branches somewhat simultaneously, I need to have test machines that have those three different branches installed. It wasn't reasonable to re-image and re-install my single test machine every time I needed to switch branches. It's also not very cost effective for me to have 3 test machines where two of them spend the vast majority of their time idle, not to mention that this doesn't scale well if one day I need a 4th branch.

So last week, I jumped on the virtualization bandwagon. I flattened my best machine, installed windows server 2008 64-bit*, and started using virtual machines for my test machines. So far it's been working out very well for me, but I do have to give credit to some other people. A few people in our test group have written some automation around Virtual Server to make life easy for people wanting to use virtual machines. They have some software that manages creating VMs for you. It basically does the following steps:

Pull an image of a selected OS from the network, and cache it locally.
Create a VM
Install the OS
Add it to the corporate network domain
Install the latest set of Windows Updates
Add my domain account to the Administrators group.
Optionally run a custom script to install more software.

For step 7, this group has provided stock scripts for installing various versions of Visual Studio, and one to install the latest build from a selected branch. It's really convenient, since steps 2 to 6 only take about 25 minutes (and step 1 is usually skipped because the image is in the usually in your local cache).

They also have an option to have the VM be destroyed and re-created every night, which means that you can come in to work in the morning and have a fresh test machine with the latest build on it.

So, I started out need to have 3 test machines in 3 different branches, but the system is so easy to use that I've already built up a larger set than that. My current list of virtual machines is:

VS2008 without SP1
VS2008 with SP1.
A debug build of VS from each of the 3 branches I mentioned above.
A release build of VS from the branch I normally work in for performance testing (I don't need absolute numbers, just finding the hotspots).

My only wish is that they update it to take advantage of Hyper-V soon to improve performance of the hosted machines.

* I previously had Vista 32-bit on the machine because at the time I set it up Server 2008 wasn't released yet, and there was a bug in the interim builds of visual studio that made install fail on 64-bit machines.

Where has Kevin been?

2008-02-15T01:55:25Z

I'm still here, I've just been very busy. We're in the thick of planning out what we'd like to do for the next version of Visual Studio. If you have any suggestions, please drop them in the comments section. I'm most interested in the sorts of features that would be Visual Studio features (as opposed to language features), and the ones that apply while you are actually editing C# code.

Also, I've changed roles a bit. I'm now the dev lead for the C# IDE team, instead of an individual contributor on the team, so I'm learning what it's like to be a people manager.

I have a few ideas queued up for future blog posts, but I'm definitely interested in your questions too. What parts of features in the C# editor are you curious about? What about work at MS and our processes, is that a topic of any interest?

Kirill on Named Parameters

2007-12-29T00:33:00Z

My colleague Kirill mentioned a post he had about named parameters, but I thought I would pull it up out of the comments, because I think it's pretty interesting. It's similar to a system I've been using to simplify writing data classes that I'll get up here one of these days.

More on "bools, structs or enums"

2007-12-10T20:16:00Z

There were some points about my previous post that I thought it might be worth bringing up in a new entry. It seems that in general, most people agree that the set of bool parameters are a bad idea. I found this a little surprising, given how often I've seen it. Maybe it's just the code-bases I've inherited :)

Fluent Interfaces

Someone pointed out that an alternative to using object initializers from C# 3.0 is to use Fluent Interfaces. Indeed, this is exactly what I would have done before object initializers were around. Jay and I have been talking about the idea of Fluent Interfaces and how they relate to "builder" classes for data classes for more than a year now.

Here's an example of how a Fluent Interface might be used instead of a collection initializer in the previous blog entry's context

struct DisplayUserOptions
{
    bool email;
    bool phoneNumber;
    public DisplayUserOptions SetEmail(bool yes) { email = yes; return this; }
    public DisplayUserOptions SetPhoneNumber(bool yes) { phoneNumber = yes; return this; }
}

And it can be called inline in a way similar to the object initializer syntax:

DisplayUser(user, Console.Out, new DisplayUserOptions().SetEmail(true).SetPhoneNumber(false));

Extensibility

Numerous people pointed that both the enum and the struct option produce more extensible API's than passing bools. In general I consider myself more of an application writer than a library writer, and so I tend not to worry as much about extensibility. This doesn't mean that I feel like I don't need to think about whether an API is usable or not, but rather that I don't tend to worry about changes that require me to recompile dependent assemblies. However, this does bring up a separate point. When I do code reviews I like them to contain meaningful changes, and so it's nice that with either the the enum or struct option the only places that change are the options type itself, and the callers who care about the new option. Conversely, with the bool option, all callers need to be updated.

Extension methods for enums

I said in my previous post that one of the advantages of using structs is that it gives you a place to group behavior that belongs with the options. Someone pointed out to me that with C# 3.0, you can use extension methods to add functionality to your enums. This is a good point. I'll have to think more in the future about whether I feel comfortable using an enum together with some extension methods, as opposed to a struct or class.

Thanks for the great feedback! Keep it coming.

EDIT: Added an example of a Fluent Interface for this scenario.

EDIT 2: Fix the implementation of the Set methods in the example. Thanks Jay!

EDIT 3: Change section header to be "extension methods for enums", instead of "Extension methods for interfaces". Oops

Coding Styles: bools, structs, or enums?

2007-11-30T20:36:25Z

I often find myself writing or consuming API's which require the caller to specify some sort of options. I've seen numerous ways to specify those options, but I've yet to find one that I really like. Let's work with an example throughout the rest of this post. Imagine we're working on an application which has some notion of a User. We're now about to create a function to output a User to a Stream. We want to provide two options:

Should we include the User's email address?
Should we include the User's phone number?

I can imagine several ways of designing this API. First, we could use a couple of bool parameters, like this:

void DisplayUser(User user, TextWriter stream, bool displayEmail, bool displayPhoneNumber)

Next, we could use a flags enum to represent the options, like this:

[Flags]
enum DisplayUserOptions
{
    Email = 0x1,
    PhoneNumber = 0x2,
    Both = (Email | PhoneNumber),
}
void DisplayUser(User user, TextWriter stream, DisplayUserOptions options)

Finally we could create a struct which contains two bools instead of the enum, like so:

struct DisplayUserOptions
{
    public bool Email;
    public bool PhoneNumber;
}

void DisplayUser(User user, TextWriter stream, DisplayUserOptions options)

I don't like passing the two bools, because I find that reading the callsite of a method designed like this to be difficult, because you don't know what the parameters mean anymore.

DisplayUser(user, Console.Out, true, false);

Does this display the email address or the phone number? I can't remember anymore. I know that parameter help can tell you the names of the parameters, but that doesn't help when I'm doing a code review in windiff, since windiff doesn't have parameter help tool-tips yet.

On my current team, we have a convention that when we call a method like this, we put the parameter name in a comment, so that we can see it, like:

DisplayUser(user, Console.Out, true /*displayEmail*/, false /*displayPhoneNumber*/);

However, in general, I don't like to rely on conventions that force people to put comments in a certain style to make the code readable. If possible, I'd rather design the API in such a way that it has to be readable.

The second option is using enum flags to represent the options.

DisplayUser(user, Console.Out, DisplayUserOptions.Email);

My problem with this approach is that it is hard to get right, both for the caller of the API, and the implementer. This example is sort of trivial, but I can remember a time when I was dealing with a bit-field that contained 31 unique bit values that could be set and unset independently. Getting all of the ~ and | and &'s just right was very hard, and once it was done, it was hard to figure out what it was trying to do. A final reason that I don't like enums is that in practice I often find that there are more behaviors that I want to be able to add to the options which isn't possible with enums. For example, it might be a requirement that two of the options are mutually exclusive. It's difficult to ensure that this is enforced with an enum.

Finally, we have the option of using a struct, which is addresses both of the two concerns above. You can write a call like:

DisplayUserOptions options = new DisplayUserOptions();
options.Email = true;
options.PhoneNumber = false;
DisplayUser(user, Console.Out, options);

Well, that's certainly clear. It also makes it easier to understand control flow that sets or clears the options, and to understand conditions based on them. It also gives a place to add that behavior: I can add methods to the struct, make the fields into properties which have setters that do validation, etc.

The problem with this approach is that in simple cases like the above, it is much more verbose than either of the other two alternatives. However, I recently realized that in C# 3.0, we can take advantage of Object Initializers to make the simple case simple again:

DisplayUser(user, Console.Out, new DisplayUserOptions { Email = true, PhoneNumber = false });

It's almost like having named parameters in C# :)

What do you think? Which alternative do you prefer? Do you have another one that I haven't thought of?

Dogfooding Challenges Part Two: Unit Testing.

2007-11-29T19:38:00Z

Another problem related to using VS in order to develop VS happens in the area of unit testing. The problem here is that my team would like to write tests for the C# language service in C#, unfortunately, this means that our dogfood IDE has the release version of the language service already loaded. Due to the way DLL loading works in windows, you can only have a DLL loaded with a given name, which means that the Unit Test framework is unable to load the debug copy of the language service that we just built. On our team, we work around that by building two versions of all of our assemblies, which are identical except for their names. That way we're able to load a unit-test specific version.

Unfortunately, this has other drawbacks. For example, it makes it impossible to combine code coverage results from unit tests, with the results from integration tests, since they are for different binaries.

Dodfooding Challenges Part One

2007-11-25T03:01:05Z

There are a couple of issues that come up for developers who work on Visual Studio that just aren't issues for most people. The first is that working on components of VS while using VS is hard. It's hard for a couple of reasons.

You want to have a debug build of the product to make it easier to debug, but at the same time, you want to have a release version of the product so that the performance isn't too bad.
If you want to be able to replace a component in the editor, you need to shut-down the editor, replace the component, then restart the editor, since windows holds the file locked.

Before we started working on VS2008 we had a single solution for both of these problems: Side by Side installs of Visual Studio. Back in the day, most developers who worked on Visual Studio didn't actually install Visual Studio through the setup process.

Batch Setup

Instead we had a batch script which would copy the binaries from the daily build machine and then run regsvr32 on a huge list of different dlls in order to getting a "working" version of VS. This had some advantages, but also some very serious drawbacks.

Pros:

Batch Setup allowed us to have two sets of binaries in two different locations. One of these was the "dogfood" or retail build, and the other was the "debug" build.
Batch Setup allowed us to specify alternate registry roots for the two different builds. This didn't work perfectly, as VS has some COM components that are registered in global locations, but it worked well enough that relatively few teams even had to care about what scenarios didn't work.
Batch setup registered the binaries to their "built" locations. The output tree of our build doesn't match where the binaries are installed by setup. This means that if you have a real setup installed, and you build some binaries, you also have to copy them into place in order use them.

Con:

A minor con is the lack of "perfect" registry support for Side by Side.
The major concern should be obvious: Dev's didn't run setup. This meant that if a dev made a change to registration, or to the names or locations of files that need to be installed, they usually forgot to setup to do the right thing. This meant that most of the time, setup didn't actually work!

Because of the second drawback above, the division made a decision at the end of VS2005, that we wouldn't continue to use batch setup for VS2008. Instead, we invested in updating our setup technology to make it easier for developers to build setup, and to understand how the setup gets built, so that it became easier to keep setup working. We also invested in some tools to make using an installed build easier. For example, we wrote a tools called "pupdate" that is able to update installed binaries from the location that they are built to automatically.

However, we never did get to the point where it was possible to install two VS2008 builds side by side to enable the experience above. How did dev's adapt to this? There were 3 different ways:

Some people basically stopped dogfooding. That is, they continued to use VS2005 as their dogfood build, since it was possible to install VS2005 side by side with VS2008.
Some people started doing remote debugging. Most of my team falls into this category. In this solution, we took an old machine and installed the debug build on it, then we would use a dogfood build on our primary machine for doing work and building. When we wanted to test some changes, we would "pupdate" the binaries from the primary machine to the test machine, and then use remote debugging to debug.
Some people created a stripped down installable version of VS that could be installed Side by Side and used that for their dogfood environment. This is basically an express sku that was developed internally for developers to use.

None of these are quite ideal, it'd be really nice to go back to the old days of being able to install 2 builds of VS side by side. We're thinking about investing in that for VS10, but as far as I know, it's still up in the air.

VS Color schemes

2007-11-23T08:59:27Z

A friend sent me a link to Tomas Restrepo's collection of VS Color Schemes today. I think it's a fantastic idea. I like to use a dark background, but there sure a lot of settings that need to be changed in order for it to be usable. Especially if you use C++/C#/XML and XAML, which all have their own colors that need to be set...

I'll definitely be giving some a try when I get back in the office on Wednesday. So far I think Ragnarok Blue looks like it'll be my favorite.

Just call me Clark Griswold!

2007-11-23T08:53:51Z

Today being Thanksgiving here in the US (it's a month late, I know, but what can you do, eh?), my family spent the day making a big turkey dinner. My wife is usually the big cook in our house, but today she's got a bit of cold, so I ended up doing a bunch of the cooking, so that she could go and rest.

We had just gotten dinner ready, got the kids settled down, and I was helping them get their plates ready. I reached for the dish of stuffing, and it slipped out of my hand and shattered all over the table. No stuffing for anyone, but lots of crying from the disappointed kids. I think I'm going to have to make another batch of stuffing in the next few days...

In the end, the rest of the dinner was acceptable, and we all enjoyed it, but I'm really starting to feel like I'm in "Christmas Vacation"

On Sunday or Monday, I'll probably string some christmas lights, but I don't think they'll look anything like Eric's. Hopefully I'll manage to get them to actually turn on though.