On Tuesday, I asked a question about whether people keep their form class names and form filenames in sync. I'd like to thank all who responded, and provide a little background on the issue. To do that, I'll have to explain a bit about our internal development a process.

Many of you have probably encountered the problem of "feature creep", where new features keep showing up during development. Feature creep is bad because it throws of your completion estimates, makes it hard for your test team to know what you're planning on building, and generally annoys people. It's especially bad when you have a lot of interdependent teams, and the new feature isn't something you want but rather something somebody else wants, and it gets worse if there are multiple teams depending on you.

One way to deal with this is to say, "No new features", after you reach a certain point in your release cycle. That would work great if planning was perfect, but it's fairly common to find out that a planned architecture has technical problems, or a new customer need comes to light, or somebody has a great idea, or a usability study shows that your current approach flat-out sucks. Not to mention the "we didn't think of that" factor, which we try to minimize but cannot eliminate.

Our approach is to provide a standard process known as a DCR (Development Change Request). In a DCR, the PM who owns the feature gets to produce a document that describes:

  • What the issue is
  • Why it's important that we fix it
  • What the customer scenarios are
  • What options there are to fix it
  • The amount of schedule time (for dev, QA, and PM) that it will take to address
  • How we'll get that time (by cutting other features, or, if it's important enough, slipping the schedule to fit it in)

This usually involves a considerable amount of research by the team, as it's really important to understand the subject deeply, and the research often involves more than one team.

Once the DCR is written up, the PM (and usually other involved parties) meet with the management team of their product (in our case, it's our PUM, our dev manager, our qa manager, and our group program manager) to present the DCR. The management team will either approve the DCR, reject the DCR, or ask for more data.


In this specific situation, the problem that we're trying to address has to do with the build system. If you've looked at the PDC session abstracts, you may have come across mention of something called MSBuild. MSBuild is a new build system that isn't coupled to the VS project system, which means you'll be able to build your Whidbey projects from the command line without loading VS.

If you've gone spelunking in your windows forms files, you may have come across a line that says:

   System.Resources.ResourceManager resources = new System.Resources.ResourceManager (typeof(Form1));

Behind the scenes, the Windows Forms designer has put some form resources in a .RESX file. These resources will get converted to a binary format by resgen.exe, and then put into the assembly as part of compilation. Since there may be multiple forms in one assembly, there needs to be a way to find the right resources for a form. For Windows Forms, the full name of the class was chosen as a key. The project system finds this out by talking to the Code Model, a sort of "mini in-process compiler" that also parses code for intellisense and other IDE features (if you read the PDC session abstracts closely, you'll find a new feature...). The code model tells the project system what the name of the form is, and this is passed to the compiler and used to name the binary resource blob in the assembly.

The resource manager constructor gets that same name from the type passed into the constructor, uses it to find the correct blob, and things are hunky and hopefully, dory as well.

Enter MSBuild. It seems like a good idea to be able to build windows forms projects in MSBuild, but there is a problem.

There is no code model for MSBuild to ask for the form name, and no facility to find that information, so it's DCR time. We've spend the last few weeks talking about different options to solve this, but none of them are great, and we don't have a single candidate that we all like.

One of the front runners has the bad characteristic of requiring a project file checkout whenever the form class name is changed, which could be a problem if the project file is already checked out exclusively.

If our users typically rename the form file when they change the class name, then the issue is largely moot, as that rename would also require a project file checkout, and that's why I asked for your feedback.

Several of the comments talked about the poor state of rename in VS (ie, you can't do a VSS rename from inside VS). I talked with the VSS PM, and he said that they are planning to do rename for Whidbey. Please read that as, "It's likely to show up, but don't get mad at Eric if it doesn't, as it's not his call". I did convey the feedback I got about the quality of the current solution.