Question

I am working with Visual Studio Coded UI Tests, and wish to persist tweaks to the generated code.

The code is generated as a partial class in UIMap.cs and UIMap.Designer.cs, and so I know one solution would be to create a method with a slightly different name, such as myMethod_persist in UIMap.cs and use this instead of myMethod in UIMap.Designer.cs, which will be overwritten every time the source is regenerated.

This however seems very messy, and so what I’d prefer, is to instead override myMethod in UIMap.cs. This way the interface is not complicated with lots of gumph, and I don’t have to remember to change every instance of myMethod in calling code to myMethod_persist

Unfortunately when it comes to C# I’m a bit of a noob, and don’t even know if this is possible.

Basically what I want is this:

[UIMap.Designer.cs]
partial class myClass
{
    public override void myMethod( int a ){ somethingHorrible(int a); };
}

[UIMap.cs]
partial class myClass
{
    public sealed override void myMethod( int a ){ somethingNice(int a); };
}

But I know that the sealed and override keywords are usually used with derived subclasses classes, not partial classes. Is this possible? If not then what would be my best alternatives?

Answer 1

If you have no control over the auto-generation itself (ie. a framework or 3rd party generator) your options are somewhat limited. The two approaches that come to mind are to modify the generated code–which as you noted is not practical for changes that are significant and perhaps accumulating over time–and/or to create a derived class and use that instead of using the auto-generated class directly (assuming you control the code which would be using them, which seems likely).

A derived class (inheriting the auto-generated class) would be able to use override or new in the method declarations you want to replace. However, there are a lot of caveats to this approach as well. You can only “override” a method that was delcared as virtual in the base class (or was itself an override of another underlying virtual base, etc). You can also replace a method with a “new” one in the derived class, but the other code in the base class will not know about your “new” version and will not call it (whereas they will call your “override” because they know the method to be virtual). There are also issues of accessiblity; your derived class won’t have access to private members of the base class.

But for some set of things you want to do it could work. In some cases you might have to tweak the auto-generated code slightly such as adding the keyword “virtual” or changing “private” members to “protected” so that you can access them from your derived class.

Added: Of course, you can also add new members to the original generated class in your own permanent file for the same partial class, and this code would have access to the class’s private members. That can be another way to give your derived class access to the private members, such as by creating a protected property to wrap access to a private member field. If you didn’t need to make changes to existing methods you wouldn’t necessarily need to create a derived class, but your example talked about wanting to “override” methods from the auto-generated code, so presumably they already exist there.

Also note that a Designer file–such as for a Form or UserControl–does not usally get completely overwritten, so cautious changes outside the core generated code (eg. not inside the “Windows Form Designer generated code” region) can be made (and are persisted). For example, it is sometimes necessary to add a call to your own custom clean-up method in the Dispose(…) method in the Designer file.