JoeN's Blog : C#

Moving to the XNA team...

JoeN — Sun, 01 Aug 2004 05:05:00 GMT

I wanted to share some news about a fairly major decision I've made. I'm going to be joining the XNA team starting Monday, August 9.

I'm incredibly proud of the C# team and the C# product. During the last five years I’ve held every PM position on the C# team so I know how special every part of this product is and I’ve also had the privilege of repeatedly randomizing many of the people on the team :-). It’s been a fantastic experience to be part of the C# team - it’s not often you get to be part of a team creating a world class programming language and development environment.

One of the benefits that a PM has is meeting lots of customers. Over the last 5 years I have met a LOT of customers and it's always interesting, fun and challenging. C# customers are very smart people and it's a great challenge to build a tool that gets out of their way and allows them to build great software. So thanks for being such great customers!

Obviously this means that I won't be blogging about C# as much but there are lots of great C# blogs to get your C# fix from - http://msdn.microsoft.com/vcsharp/team/blogs/default.aspx.

Oh and Luke and Anson are now looking after the C# Keybindings :-)!

Announcing C# Express!

JoeN — Tue, 29 Jun 2004 17:42:00 GMT

Well it's finally been announced - the Express line of products for Visual Studio!

You can find out more about the products and download it from: http://lab.msdn.microsoft.com/express.
There is also a contest to produce applications using Express http://channel9.msdn.com/ShowPost.aspx?PostID=11656.
An Express blog can be found at: http://blogs.msdn.com/express

Express has been a large part of my life for the last 12 months. I've been working on C# Express and helping drive the overall Express effort inside the Developer Division and it's great to see a lot of people's work now seeing the light of day.

10 Pushups for Life

JoeN — Fri, 25 Jun 2004 00:35:00 GMT

In my first public Microsoft presentation (PDC 2000) I made a bet that I have lived to regret.

At PDC 2000 we had very early bits of .NET and VS so it was a little bit of a minefield to demo. I had at least 4 demos during my 1 hour session but I was pretty confident about them much to the surprise of my fellow presenters. In fact I was so confident that I made a bet with some of them:

If all my demos went well and the product didn't crash then they would fly me back to Seattle business class, BUT
If any of my demos failed I would have to do 10 pushups for every failed demo. Oh and the pushups needed to be done on stage during Q&A!

Luckily everything went well during the session and I did indeed fly back to Seattle in business class (which when flying from Orlando is well worth it). Unfortunately the punishment part of the equation has stuck with me so now whenever I do a public presentation I have the 10 pushups sitting over my head!.

Well it finally happened! I was doing a demo for a client in New York this week and the product crashed on me! At the end of the session I did the 10 pushups while the clients kept count for me!. I suppose I am getting fitter :-)

So why did the C# keybindings change? (Part 2)

JoeN — Sun, 20 Jun 2004 05:33:00 GMT

So who would have thought that keybindings would have been a contentious issue? J Thanks for all the great comments and ideas, I’ll work with our core editing team to see what we can incorporate for VS 2005.

Reading through all the comments and the original blog entry I see that I buried a crucial piece of information:

But while we think the new keybindings are a lot more logical and easier to learn we totally understand that people don’t like gratuitous changes and want to be able to use that muscle memory they have developed. So what we are going to do is make as many of the old keybindings available as well (the new ones will be shown by default but the olds ones will also work).

While we haven’t done the calculations yet I fully expect that 90 to 95% of the keybindings that you use in VS 2002 and 2003 will work as expected in VS 2005 when you choose the C# Profile.

Using the commands from the last blog entry you could access them via two sets of keybindings (VS allows multiple key combinations to be bound to a single command):

Solution Explorer Ctrl+Alt+L Ctrl+W, S
Class View Ctrl+Shift+C Ctrl+W, C
Server Explorer Ctrl+Alt+S Ctrl+W, L
Resource View Ctrl+Shift+E Ctrl+W, E
Properties Window F4 Ctrl+W, P
Object Browser Ctrl-Alt-J Ctrl+W, J
Toolbox Ctrl-Alt+X Ctrl+W, X
Breakpoints Ctrl+Alt+B Ctrl+D, B
Autos Ctrl+Alt+V, A Ctrl+D, A
Call Stack Ctrl+Alt+C Ctrl+D, C
Threads Ctrl+Alt+H Ctrl+D, T

Using multiple keybindings allows:

Existing developers retain their existing keybindings and muscle memory
New and existing developers can learn commands more easily and have an overall more consistent keyboard experience.

I’m not sure whether this changes people’s opinions and I apologize for not making clear that the majority of your existing keybindings will continue to work.

I get the impression that we should just scrap this entire idea and simply keep the old keybindings. For new commands in VS 2005 (e.g. refactoring) we should just attempt our best to find logical keybindings in the available spaces (Although I would hate to lose Ctrl+R, R for Refactor.Rename because that keybinding is already taken by Edit.ToggleWordWrap!).

The consequence of this is that new C# developers will have to learn an apparently random set of key bindings but hey perhaps that’s just “paying their dues”.

Some small notes on the numerous comments from the previous blog entry:

There will be numerous “old” keybindings available in VS 2005: VC2, VC6, VS2002, VS 2003 etc
VS 2005 will allow you to save all your IDE settings into one file which you can then import into an version of VS. Unfortunately there are no current plans to import VS 2002 and VS 2003 settings.
I didn’t just dream these changes up J. I worked with our usability team to work on this problem and through most of our usability studies have had the new keybindings in place.
Don can continue to program for the next 24 years without worrying.

So why did the C# keybindings change?

JoeN — Fri, 11 Jun 2004 04:45:00 GMT

Andy wants my blood but on an internal email thread both Don Box and Chris Sells also want it.

I was responsible for the new C# keybindings (I’ll let you have a moment to stick that pin into the Microsoft PM Voodoo doll you all have J). It all started when I was given the keyboard randomizing dice that the last person used to determine VS keybindings...

Seriously, we actually spent a lot of time thinking about the C# keybindings in VS 2005 before making any changes. To put this issue into perspective you need to know something of the history of keybindings.

In VS 2002 and 2003 we (the C# team, well actually me againJ) didn't really look at the keyboard bindings that closely. If you look at the Start Page in VS 2002/2003 and you select the C# Developer Profile you'll notice that we simply use the “VS Default” keybindings.

So who decided the “VS Default” keybindings? The short answer is individual teams within VS. As teams introduce new commands each team simply hunts for an open key binding, finds one and assigns it. Timing plays a big part in what keys you get and once you have a specific keybinding possession is 9/10’s of the law.

Now the good thing is that teams are usually consistent with the key bindings they have for their commands but with so many teams contributing many commands it can quickly fragment and of course every team believes that their commands are pivotal to the success of Visual StudioJ.

Let’s have a look at some of the VS Default keybindings in VS 2003. With no project opened the View Menu in VS 2003 has the following commands and keybindings:

Solution Explorer Ctrl+Alt+L
Class View Ctrl+Shift+C
Server Explorer Ctrl+Alt+S
Resource View Ctrl+Shift+E
Properties Window F4
Object Browser Ctrl-Alt-J
Toolbox Ctrl-Alt+X

See any connections here? I didn’t think so.

If you start a debugging here's a subset of the commands and their keybindings under the Debug Menu:

Breakpoints Ctrl+Alt+B
Autos Ctrl+Alt+V, A
Call Stack Ctrl+Alt+C
Threads Ctrl+Alt+H

The debugger team appears to have a consistent access method, but why is Threads H? (Answer: Ctrl+Alt+T was taken by View.DocumentOutline). Why does Autos have a two key combination etc?

In VS 2005 we have introduced the idea of profiles which allows each team to create a consistent experience for their developers. This essentially allows teams to actually look at the keybindings from an overall product perspective and decide the logical set of commands for their users and then map appropriate keybindings for them.

When I went about looking at the C# keybindings for VS 2005, the first thing I did was map all the Global and Editor keys from VS Default keybindings into a spreadsheet (oh the glamorous life of a PM). It was interesting to actually go through the process and watch a form of key bingo being played as teams searched for the last slot and the different key modifiers. If you are interested VS uses nearly all the modifier keys and their combinations. On the spreadsheet I mapped the following modifier keys: Ctrl, Ctrl+Shift, Alt, Shift, Shift+Alt, Ctrl+Alt, Ctrl-Alt-Shift.

Here’s how we went about coming up with new keybindings:

1. Create command themes. We wanted to create some command themes that allowed us to gather common commands together. Examples of themes we used were: Design time windows, Debug time windows, Refactoring commands, IntelliSense commands, Bookmarks, Help etc. These themes make the group of commands more understandable as well as easier to learn. For each of these themes we created a two chord key combination, the first one activates the theme and the next one activates the command so:

Ctrl+W, S Window, Solution Explorer
Ctrl+W, C Window, Class View

Ctrl+R, E Refactor, Extract Method
Ctrl+R, R Refactor, Rename

Ctrl+D, A Debug, Autos Window
Ctrl+D, B Debug, Breakpoints Window

2. Prefer common C# commands. There were a number of places where common C# commands either didn’t have the obvious keyboard combination in VS2003, or there were natural conflicts with the commands. In these cases here, we preferred the command we thought would be more common for C# developers to use and if this didn't work then we preferred the old keyboard letter.

3. Push the new commands to the front. Commands in VS can have multiple keybindings. In order to encourage users to use the new keys we have moved the new keys to the front of the list so they get shown on all the menus. The other keybindings are still there, they just don’t get shown.

After applying this philosophy we obviously ended up with some a fair number of changes. Using the commands above this is what they now look like:

Solution Explorer Ctrl+W, S
Class View Ctrl+W, C
Server Explorer Ctrl+W, L (we prefer S for Solution Explorer over Server Explorer)
Resource View Ctrl+W, R (moved this off the main menu to submenu)
Properties Window Ctrl+W, P (F4 is still bound)
Object Browser Ctrl+W, J (preferred O for Output window, so we kept old letter)
Toolbox Ctrl-W, X (preferred T for TaskList, so we kept old letter)

Breakpoints Ctrl+D, B
Autos Ctrl+D, A
Call Stack Ctrl+D, C
Threads Ctrl+D, T

Unfortunately (you knew it was coming) in the Community Previews as well as the upcoming Beta for VS 2005 we haven’t actually put many of the “old” keybindings back into the C# profile (I promise this isn’t a conspiracy theory – we will get this in soon).

I’d be interested in what you think. Should we have:

Left the keys alone . Let you discover the new commands and bind them to keys you think are appropriate.
Left the keys alone and find new keys (no matter how unnatural) for any new commands we introduced
Do what we have currently done.

VS 2005 drives me crazy with all these changes!

JoeN — Fri, 11 Jun 2004 04:22:00 GMT

Yesterday I watched a usability study where the user was a little frustrated about seemingly gratuitous changes we have made in the product. They were using a pre-release version of VS 2005 and quickly asked these questions:

Why is there a MenuStrip in the toolbox but no Menu control?
Why is the Grid turned off on the Windows Form designer?
Why has the C# keyboard bindings changed?

Now I'll take complete responsibility for the 3rd change and I'll talk about in my next blog (both Don Box and Chris Sells are looking for me about the those changes!).

The interesting thing was that when we had to chance to explain why we made the changes, the user was happy with the explanations. So here is the challenge - what's the most effective way to explain the reason for the change so our users will actually see it? I know I don't read the README files for the bulk of the software I install and I always quickly dismiss the “Tip of the Day“ type dialogs that some software uses.

Anyone had a good experience with some software that gave them this context? Any suggestions for what to do here?

Cascading changes from a method rename - what do you think?

JoeN — Wed, 09 Jun 2004 04:31:00 GMT

I'm working on an issue with the C# refactoring and wanted to get your opinion. One of the things we are delivering in VS 2005 is the ability to reliably rename methods, types etc.

We have a current issue where you can be in some code and you want to rename a method. The method is actually part of an interface definition (let's ignore the fact that we currently don't have a way to indicate that the method is part of an interface).

There are several ways to interpret renaming this method. Our current implementation does this:

Changes the name of the method in the class that you are editing (this is where you kicked the rename off)
We detect that the method is part of an interface declaration so we change the interface to match the new name.
We then detect all other implementations of the interface and change the methods in those types to match the new name.

I'm a little concerned that this is a little too “easy” and may cause more changes than a developer was expecting. We have a number of ways to fix this (inform the user that this is happening, come up with a way of selectively choosing which replacements to make via the preview dialog) but I'm inclined to perhaps simply restrict this so that you can only rename an interface methods from the interface itself so it's a much more deliberate action.

We are still tossing this around but I'd love to get your feedback on what you would expect.

User Error and "Disk Read Error" from Virtual PC

JoeN — Wed, 09 Jun 2004 04:10:00 GMT

As I mentioned earlier this month I used VPC for the TechEd demo. Everything worked well but I had a strange problem that I couldn't quite work out. Today I took advantage of working at Microsoft and went and met some QA people from the VPC team and got an answer.

Here was my problem. My Virtual Hard Disk (.vhd) file for my Tech Ed demo worked fine off the external USB drive but whenever I copied the file and attempted to run a new Virtual Machine off the copied vhd file I would get a “Disk Read Error”.

After a little head scratching we (I'm using we in a very liberal sense) found the problem. When I received the USB drive it was preformated FAT32 and ready to go. I created the .vhd, loaded it up and was ready to rock and roll. Over time the .vhd file grew larger than the 4Gb FAT32 limit and VPC quite conveniently created a separate file with the extra information in it (the extension was v01). Now I actually had two files for my VPC:

TechEd.vhd
TechEd.v01

When I went to copy the files to another drive I didn't copy the .v01 file so VPC failed to load it with a very cryptic “Disk Read Error”.

Here's what I learned:

Keep your .vhd files on an NTFS drive
Keep your .vmc files in the same directory as your vhd file (this just makes it easier to move stuff around)

But here's the best part. Paul helped me take my split .vhd files and create a single vhd file. Here's what he did:

He created a new .vhd file and then used Norton's ghost to create an image file of my “split“ vhd file.
He then created a new .vhd file and restored the image we just created to it.

Because we did all this on a NTFS drive we had no more split files!

The more I use VPC the more I'm impressed with it. Lots of different presenters at TechEd used it for their demos, if you haven't used it you should definitely give it a go?

DEV 322 Visual Studio 2005 C# IDE Enhancements - Walkthrough available!

JoeN — Fri, 04 Jun 2004 05:26:00 GMT

I've posted an article containing a walkthrough of my session at TechEd. The article contains links to both the slides and the demos that I used.

All the demos I used at TechEd work on the (clearly named :-)) Visual Studio 2005 Community Technology Preview May 2004 which were the bits handed out at TechEd (MSDN subscribers can also download the bits through MSDN).

If you are interested in the seeing what I presented, or want to recreate the demos on the build then have a look. It's pretty comprehensive but if you have any questions let me know.

My Tech Ed Presentation is over!

JoeN — Thu, 27 May 2004 22:39:00 GMT

Well my presentation at TechEd is over and it all went well. All the demos worked (perhaps a bit slowly at times) but I think people got a feel for the C# IDE enhancements that we are doing. As soon as we can I’ll post the demos and slides to the C# Dev Center and let you know from here.

Thanks to all the people that attended the session. It’s always great to meet customers, show them some stuff and have a great conversation about what we have (and haven’t done) and where we should be headed etc.

TechEd 2004 - Tempting the demo gods!

JoeN — Tue, 25 May 2004 00:49:00 GMT

TechEd has started!

This means that I’ll be nervous until my presentation on Thursday! I’m not nervous about showing off individual features because they are great and I’ve been working on them or with them for a while now, I’m more nervous about being able to do justice to all the features in the time that I have during the presentation.

I’m also tempting the demo gods by using a different hardware/software configuration than normal. Let me explain.

I use Virtual PC (VPC) all the time at work to play with daily builds of Visual Studio and I’ve always wanted to use them for demos but I didn’t feel comfortable with the performance of a VPC running on my laptop (the performance was nearly acceptable but when you are presenting you want every piece of performance you can get!).

This presented a problem for me (and for most PMs). I didn’t want to rebuild my main laptop for the conference and I didn’t have a spare “demo” laptop laying around to install the build.

Just before the conference I stumbled across this article and last week bought an external USB drive to run the VPC image off. The USB drive is a 200Gb drive, 7200 RPM, 8Mb buffer and the VPC performance was much better.

The only problem now is that I need to carry another piece of hardware (which needs its own power cord) but it’s well worth the extra hassle and weight.

As soon as I get back to Redmond I’ll be looking for a smaller form factor for the drive and start to spread the word.

Anyone got any suggestions about drives that work for them?

Back from vacation and ready for TechEd 2004

JoeN — Mon, 10 May 2004 20:56:00 GMT

I'm back from vacation, refreshed and ready for the TechEd 2004! I'm just about to meet with Anson and talk about our presentation “Visual C# 2005: IDE Enhancements for the C# Developer”. We will be demo heavy and if there is a feature you've heard about or want to see in action then let us know and we'll do our best to accomodate it.

Oh and a brief “sign of the times“ from our trip back to Australia. On the way to Australia my son Ethan (nearly 3 years old) was carrying his bunny toy as he walked through the scanners at the airport. The guards stopped him and asked him to put the toy in a container so it could be scanned. When we came back into the States and went through security at LA, Ethan saw us putting our bags through the scanner and went all by himself, grabbed a container and put his bunny into it. It was one of those moments when you realise that his world will be very different from the one that I grew up in!

TechEd 2004 (May 23-28)

JoeN — Tue, 23 Mar 2004 05:43:00 GMT

Anson and I are sharing a session at Tech Ed 2004. We'll be talking about some of the IDE features in Whidbey for C# developers. A number of members of the C# team will be presenting as well, you can search for session information at: http://www.msteched.com/content/breakouts.aspx.

I've done a fair few presentations on C# over the last 5 years and IDE presentations are my favorite. Anson and I are just planning the presentation now and we essentially want to have about 3 slides and dive into the product for the whole hour and show features, explain the rationale behind them and show how they all work together to make C# developers super-productive whether they are:

Trying to understand the code they are looking at (or inheriting),
Modifying their code, or
Writing new code

We want to use the same product build that will be available at the conference so everyone will be able to duplicate the demos we do at the session. Normally we would just prepare a presentation but I'd love to hear what you would like to hear about. Should we:

Prepare more slides and do less demos (I think I know the answer to that one)
Use product builds newer than the ones that we give people at the conference if it shows people more of the final look and feel for the feature?

Essentially I'd love to hear about what you'd like us to do - it's early days for us and we'd like to understand what you'd like to see!

Default Namespace and folders

JoeN — Mon, 15 Mar 2004 21:09:00 GMT

Most of my time is spent on Whidbey and Anson and I have been working on the project templates and the add item templates for Whidbey.

One of the issues we are currently looking at is the need for namespace entries in the code that gets generated when you either create a project or when you add items to a project. I'm sure that everyone has already seen the current behavior in VS 2002/2003:

When you create a project you get asked for the project name. We use this as the “default namespace“ for the project. All the code generated as part of the project creation gets put into this default namespace.
When you Add an Item to the project we generate a namespace for the code using the default namespace stored as part of the project. There's a slight twist to this, if you have added a directory to your project structure we append the directory names to the default namespace.

You can change the default namespace property in the project properties (Common Properties.General page) and you also modify the code that gets generated as part of project creation or add items by modifying the code contained at:

C:\Program Files\Microsoft Visual Studio .NET 2003\VC#\VC#Wizards

Be careful modifying the code or filenames associated with our wizards - there are JScript wizards working in the background (don't ask me why) that don't take kindly to modifications (I know from experience)

So here's the question:

Do you use the default namespace and the VS behavior to generate the right namespace entries or do you simply manually modify them after the code gets generated?

Anson and I were talking about removing the namespace declarations from the templates the other day, how would this affect you?

Turning off Dynamic Help in VS 2002/2003

JoeN — Mon, 15 Mar 2004 20:31:00 GMT

Anssi made a comment on my blog that reflects some general feedback I've had from various users about the Dynamic Help:

Someone on comments already asked this, but i couldn't notice a response. Can you turn dynamic help permanently off (won't come back on when making new solution or project) somewhere? I would like this as i don't find it useful and it seems hog resources a bit when writing code. (guess you can't notice it unless you are low on memory or slow hdd).

In VS 2002 and 2003, there is not way through the IDE to turn off Dynamic Help but where there is a registry there is a way! You can turn it off via the following registry key:

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\Dynamic Help]

"Never Show DH on F1"="YES"

Warning: The Dynamic help window is used to disambiguate when F1 returns multiple results. Adding this registry key will mean that if multiple matches are found when you hit F1 on something only the first topic will be returned.

In Whidbey we don't use the Dynamic help for disambiguation so you can simply close the window and it won't reincarnate itself. We are also not showing the Dynamic help window by default in the default C# settings file.