views:

270

answers:

2

Visual Studio is kind enough to generate a lot of code for us when we create and design Windows.Forms controls. It also surrounds most of it with a #region statement. In newer versions it also uses a partial class to separate generated from manually created code. Developers are supposed to edit code only in certain areas.

But nothing prevents us from violating this in whatever way we please. I'm fine with manual edits that could just as well have been made from the designer, or manual edits in areas the designer doesn't touch. But I'd like to flag any other kind of edit.

Does anyone know a utility that can do this? StyleCop rules perhaps? I mostly need it for the combination of C#, Windows.Forms, and Visual Studio 2003, 2005, and 2008.

+1  A: 

These days, designer code should end up in a .Designer.cs file. It should be very rare that developers need to touch that. Unfortunately, I don't know any way of verifying that the code was genuinely generated by the designer. It would be handy if it included some sort of hash, but it doesn't as far as I'm aware...

Given how easy it is now to just say "don't edit designer files" do you really need another system though? It's not like you need to stay away from specific regions - it's the whole file which is out of bounds.

Jon Skeet
Except for the Dispose method, which you may need to add code to to dispose non-UI objects in your class
thecoop
thecoop: No don't add code. You will loose it. Move the Dispose() to the main cs first. But yes, it is a special case.
Henk Holterman
You don't seem to understand the question. The point of the system is not to provide an *alternative* to telling develoeprs not to touch the Designer.cs file, it is to verify whether they *listen*.
reinierpost
@reinierpost: My point was that things have moved on beyond the days of regions, where it was easy to do stuff accidentally. If you have developers who deliberately disobey easy-to-follow instructions, you've got bigger problems than designer files.
Jon Skeet
@Henk: not in mu experience. Only the code within the designer #region gets rewritten, the dispose method stays as-is
thecoop
@Jon Skeet: I see your point, but when people consult me to point out any problems with a code base they depend on (and didn't write), that is not the kind of answer I want to provide.
reinierpost
@reinierpost: If you don't like my advice, you're welcome to a full refund :) If you'd rather I didn't answer any of your future questions, that's fine too. I still think you've got a cultural issue more than a technical one if people won't agree to things like this.
Jon Skeet
@Jon Skeet: I do like your advice, it's just that given the context in which I was asking, I can't accept this particular advice as *the* answer to this particular question.
reinierpost
A: 

Why should developers not be allowed to change this code? If they are able to write code that works, they should be allowed to do it. If they are not able to write code that works, lets say they should be trained or fired.

You just have to extend the meaning of "it works" to "it works at runtime as well as in the designer". So what's wrong about that?

Todays gui designers are not very restrictive and are doing a good job in "understanding" code that had been written by a human.


There is also real generated code around, for instance code generated by some xml specification, resources etc. This code is generated when building, so when it had been changed, these changes are undone whenever the application is built.

Designers are not real code generators of this kind. They are a kind of "coding helpers", helping the developer to write code faster then by typing it in. But it should actually be possible to write the same kind of code manually although limiting one self to the designers capabilities is a reasonable maintainability decision.

Stefan Steinegger
Yes, and I want to verify whether that decision is being respected.
reinierpost