This post originated from an RSS feed registered with .NET Buzz
by Eric Gunnerson.
Original Post: PM: Renaming Windows Formsh
Feed Title: Eric Gunnerson's C# Compendium
Feed URL: /msdnerror.htm?aspxerrorpath=/ericgu/Rss.aspx
Feed Description: Eric comments on C#, programming and dotnet in general, and the aerodynamic characteristics of the red-nosed flying squirrel of the Lesser Antilles
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.
Previous Topic
