Welcome to MSDN Blogs Sign in | Join | Help

JoeN's Blog

XNA Shaman
Profiles (aka .vssettings)

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 :-)
Posted: Sunday, February 15, 2004 9:36 PM by JoeN
Filed under:

Comments

Ilya Ryzhenkov said:

I don't have Whidbey yet, but I was successfull to transfer devenv.xml and *.vsk files from %PROFILE%\Application Data\Microsoft\VisualStudio\7.1\ folder onto other VS installation. Isn't this enough to copy those files? I noticed no lost settings...
# February 16, 2004 12:51 AM

David Pickett said:

IMHO, YMMV, etc:
Separate project settings, personal settings, and community settings sound fine. It seems like it would be nice if you could mark particular settings as mandatory (i.e., "lower-priority" settings files won't override them) and optional (which only take effect if not overridden by higher-priority settings files, but that's an off-the-cuff comment, so take with a few grains of salt.
I don't think HTTP/FTP access are necessary.
Of all the items you list above, the ability to store VS settings somewhere centralized and be able to access them from anywhere would be the most useful. Hopefully a "settings server" would be fairly low overhead ;).
# February 16, 2004 8:58 AM

Scooblog said:

# February 16, 2004 12:42 PM

Philip Rieck said:

1) Layered settings: Nice. Although I wouldn't put it on my "must have" list, it is a feature I'd use -> having my team all have the same tab-to-space type thing is nice.

2) Settings server -- a must. Hopefully you'll ship wsdl for it / a simple implementation of it so that we can create our own service and run it if we're either boxed in by a firewall (or no access), or we're paranoid about someone messing up our settings on Microsoft's server.
Along with that comes a very easy way to specify where to get the settings, of course. I personally would use one set up by MS if possible.

lastly, here's my own personal ideal -- I open up VS.NET on a machine. I hit import settings on a well-known and easy to find menu. It downloads my meta-profile from MS (asking for my passport), and prompts me with the profiles I've defined and published("demo", "web", "service", "geeky"...) all of them are mine, and all are available to me now. As I close VS.NET, (since the profile I seleced has this setting), the profile is automatically updated and sent to the central service.







# February 16, 2004 6:22 PM

Mark Levison said:

Layered settings would very useful, especially if you going to gives a decent number of formatting settings in th future.

In addition please allow the project settings to be in custom location.

In our projects we put shared files in sourcesafe, it would nice just to point the devenv at a location these files were pulled down-to everyday.
# February 17, 2004 9:47 AM

ShadowChaser said:

Perhaps you could support layered settings via Windows Server policies.

Being both an administrator and a developer, I could see alot of benifit in building an ADM file (policy template) that allows administrators (or developers that are friends with the administrators ;) to create optional or required policies that automatically get syncronized to the desktops during login.

There might be certain settings that a team would want to enforce - such as a default code formatting option. Using the Windows NT/2000/2003 policy system would let you leverage existing technologies and not require reluctant IT staff to install a new server and you guys wouldn't need to program a new custom server that might be forgotten when the next big thing comes out (think Source Safe 6 :)

It's fairly easy to build a nice policy system - I built one for my own project at work in about a day or two.

I would say that WebDav and FTP access is a must, at least when it comes to opening/downloading project files. Working directly off of WebDav or FTP would be very slow, but some sort of "fake" change control provider that did this would be very cool - open a project on WebDav and it would syncronize the files down, and once you "checked them in" using the source control interface it would reupload it to the server. Perhaps its a little extreme though ;)

The passport integration idea is awesome - as long as it would use passport. A new service for users to sign in would be forgotten - besides, wasn't passport (almost) created for this kind of thing?

It sure would be an awesome feature to have passport syncronization to a MS settings server - I could really see this being used in quite a few other products as well. It could just store "baseline" settings and not the fancy ones (like the settings transfer wizard). If that's a little overkill (just imagine the server diskspace!) you could always just store it into Active Directory. If the end user or organization had to set up a settings server, chances are the developer wouldn't be able to use it in other environments (such as home) anyhow.
# May 25, 2004 8:24 PM

ShadowChaser said:

Sorry for posting a comment/response twice, but I really need to suggest a feature - it's been on my mind for ages! (and probably most other developers)...

I'm not sure if this would be insanely difficult or not, but what about some sort of system that automatically determined what a developer's own coding style was?

Sample "Developer A" programs with a lot of white space, like this:

public class MyClass : MyParentClass
{
public MyClass ( int someParameter , bool anotherParameter )
{
}
}

Sample "Developer B" likes his code to be compact so he doesn't need to skim over the excess whitespace as he debugs

public class MyClass: MyParentClass {
public MyClass(int someParameter, bool anotherParameter) {
}
}

Perhaps when you install visual studio, it could default to an "unknown" state. The settings system could monitor the first few saves and determine what the user's style is for each language based on the formatting. Once it had (hopefully) accurately guessed the users style, the system would shut itself off for performance reasons - and all autogenerated code and automatic code formatting after that point would use the determined setting.

If it guessed wrong, the user could always go into the options for the specific language and set it up manually, or reset it back to "auto".
# May 25, 2004 8:33 PM

JoeN's Blog said:

# June 18, 2004 12:45 PM

jsdthcy said:

ShadowChaser,tahnks for your tips!
# July 15, 2004 6:03 AM
Anonymous comments are disabled
Page view tracker