One of the things that I'm working on at the moment is the C# profile for Whidbey. Anson (another C# PM) and I are trying to complete the first cut of this this week and it's not an easy task.

So whats a profile (and how does this relate to the Tools.Options issues I have been talking about)?

Profiles are essentially a new (and long overdue) feature for VS that allows users to save their settings into a single file so they can be transported and then replicated on another machine, new VS installation on an existing machine etc.

In a nutshell the things that can be captured in a profile include:

  • All Tools.Options settings
  • Window Layouts
  • Keyboard Bindings
  • Menu and command bars settings

It's not hard to imagine what actually happens here, we have some functionality in VS that gathers the selected settings and stores it in one file. Users can then transport the file to another machine and then get VS to import the settings. The system also supports importing/exporting subsets of information (unfortunately the granularity in Whidbey is fairly coarse in some areas e.g. you have to import/export all the keyboard bindings, not just some specific keys).

This is a huge step forward from VS 2002 and 2003 where we had a very primitive version of profiles on the Start Page. In these versions of the VS choosing a profile on the Start Page simply selects a specific set of Keyboard bindings, Window Layouts, and a Help Filter.

If you have the PDC 2002 version of Whidbey VS you can see this functionality from the “Tools.Import/Export Settings”.

This is really just the start of this functionality - in Whidbey we expect to add some support for “team” settings. Before you jump to any conclusions about what this means it's simply a settings file that you can instruct VS to track. The canonical example of when this would be useful for C# is setting some team source code formatting conventions. A team lead could create a settings file that held the formatting options for the team, put it on a share accessible by everyone on the team, and then direct team members to set VS up to track the file. Every time VS starts up it checks to see whether the file has changed and if it has it then imports the settings from the team file into their VS installation. It's not fool proof and we debated adding all sorts of controls in terms of making sure that some settings could be locked etc but we decided to keep it simple in this version.

So Anson and I are working on defining the default C# Profile that a users will be able to select when they use Whidbey Visual Studio. This is fraught with danger because we are guaranteed to choose settings that someone won't like (or at least are a little unexpected) but at least now users will be able to reset the option and have a system of making sure that they don't have to keep changing them every time they install a new version of VS.

A lot of the settings that we are using are based on our persona for a C# developer. RickSp C# usability engineer discusses this persona here. We are basically trying to make sure that we have a consistent environment for C# developers and try and optimize the environment for their development style (I'll admit it now so you can start the stages of grief - we are changing the keyboard bindings again :-( I promise there is some method behind the madness!).

We've deliberately kept this functionality simple for Whidbey but we had lots of different discussions about other things we could do:

  • Should we support layered settings (personal settings, project settings, team settings, corporate settings, “community” settings)? In this system we support an arbitrary number of settings files and layer them on top of each other. I'm particularly interested in the idea of project settings (settings specific to a project, do people work on multiple projects with different formatting options for example) and community settings (settings common to a development community - MSDN, AngryCoder etc).
  • What sort of access methods should we support for settings? We support files and file shares, should we support HTTP and FTP access?
  • Should we support some sort of server system that serves up VS settings (among other things). We have talked about having some sort of central repository and having some sort of Passport type access so you could use Visual Studio from any machine and magically have your options served up to you?

Let me know what you think:

  • Have you tried the Import/Export Settings functionality?
  • What do you think of the additional functionality I've talked about, is it interesting or is it over-engineered :-)