Question

I have a .aspx file and would like to add some HTML to it. The problem is that it can’t be modified. If I upgrade the product, this .aspx file will be overwritten and my modifications would have to be done again.

This is an open source product, so I can have a look at the codebehind. Again, I cannot modify it because that would break my upgrade path. Also, I need to add functionality that would never be included in the product, so sending in a patch is useless.

The class that’s referred to is a partial class, so I tried implementing an extra Page_PreRender by creating another partial class of the same name in the same namespace. However, since this is in another assembly, .net says it doesn’t know which is the correct class.

Is there any way I can do this?

Answer 1

So you can neither touch the .aspx of this page, nor the assembly containing its code behind? Sounds like you need to create a PageAdapter.

Say you’re given this page…

<%@ Page AutoEventWireup="true" ContentType="text/plain" Inherits="WebForm1" %>

SomeControl: <asp:Literal runat="server" ID="SomeControl" />

…with this code behind (in an assembly that you can only reference, not modify).

public class WebForm1 : Page {
    protected void Page_Load(object sender, EventArgs e) {
        var SomeControl = (Literal) FindControl("SomeControl");
        SomeControl.Text = "Value set from code-behind.";
    }
}

What you can do is create a PageAdapter like so (in your own assembly):

public class WebForm1Adapter : PageAdapter {
    protected override void OnLoad(EventArgs e) {
        base.OnLoad(e);
        var SomeControl = (Literal) Page.FindControl("SomeControl");
        SomeControl.Text = "Value set from control adapter.";
    }
}

Then finally, you need to register your override by creating a browser definition file:

<browsers>
  <browser refID="Default">
    <controlAdapters>
      <adapter controlType="WebForm1" adapterType="WebForm1Adapter" />
    </controlAdapters>
  </browser>
</browsers>

Check the PageAdapter and ControlAdapter documentation to find out all the ways you can override the normal page behavior.

This should make updating the third party page much less painful. No matter what you do though, merging updates will be inherently brittle. That is, unless the author of the third party page is consciously presenting some form of a stable API.