views:

139

answers:

4

I have created a class that is simply THIS

Class UserControlBase
     Inherits UserControl
End Class

Then I changed the Inherits clause in each of my UserControls designer file to

   Inherits UserControlBase

I know that generally you shouldn't manually mod the designer file. But in cases like this what else can you do? Is this OK? Is there a best practice I don't know about? Is there some other way to accomplish the same end (extending UserControl) ?

+3  A: 

I have not had issue changing the Inherits line, adding Namespacing, or adding Imports/Using statements. If you need to do any of these 3, you won't find many other ways to handle these requirements.

Chris Porter
Chris,Thanks for your answer...you get the answer flag because you specifically mention the the things I am changing..namespaces and imports. Good Answer.Joel also thank you for your answer. The key thing I was looking for was for someone with experience to confirm their experience. In my more limited experience changing namespaces and imports has worked but I was not sure it would stick.Thanks guys.Seth
Seth Spearman
+2  A: 

I change them all the time in my C# projects... often it's the easiest way to duplicate something that you've done once in the designer to a similar form and you want to do the same thing in a different form. Visual Studio is perfectly capable of reading in your changes and incorporating it into the designer. I really don't know why there is a comment saying not to edit it. My advice would be just make sure you use source control, go ahead and edit it, test it well, and if it works, great, if not you can always back out your edits.

JoelFan
+1  A: 

No. It's never a good idea to modify a file that's generated.

John Saunders
That's a fair rule of thumb, but the contents of the Designer file are safe to change--provided that you are doing design-time compatible modifications. Some generated files will throw away your changes (like the generated code files for DataSets) but the designer will preserve your changes (although it will reformat and rearrange them--but the essence of the code stays the same).
STW
That's always been dangerous. The assumptions of the designer are not documented. Do something just a little different and it will wipe out your changes. I've been dealing with this since .NET 1.0, and I strongly recommend against changing these files.
John Saunders
+1  A: 

The Designer files are pretty simple code; the only thing that you'll typically find in there to complicate matters (but only slightly) is BeginInit/EndInit calls at the top and bottom of the file--between those the code is pretty forgiving.

*That said, do not put any code in there that will only execute at Runtime. Any runtime-dependant code will fail at design-time, so trying to open your control in Design view will blow chunks. It used to give you the Red Screen of Darn, but I'm not sure what effect the IDE has notwadays--but if things blow up and the usual tricks fail to remedy them then try removing your customized sections.

Further on that note (not to scare you, but rather to hopefully head off some of the difficulties we had) the means of determining if your code is executing in Runtime or Designtime often fail if your code is not part of the currently built solution/project.

So to bring it all home, simple UI layout/winforms modifications are perfectly fine to do by hand in the designer code. Databinding and external dependencies (with the exception of calling third party control libraries) should be cautiously approached.

STW