Question

I have an aspx page that used a method in a class in the App Code folder, doSomething(int[] x). I changed the function definition to use an IEnumerable instead of an array: doSomething(IEnumerable<int> x). Next, I precompiled the web site, using “allow web site to be updatable”, and published the new App_Code.dll. Now, the precompiled version of the page gives a Server error at runtime: “Method not found”.
If I also publish the DLL generated for the page, “App_Web_[page].aspx.[random].dll”, it works. So it appears the signature of the function is embedded in the compiled page somehow…? Why is this, and is there a way to avoid this problem when changing existing code?
I’d hate updating all my page DLLs whenever I change code in my common classes.

Answer 1

When a page is compiled it looks at all the method signatures and essentially locks them down. If you change the signature of a method being called, then the page will not be able to locate it until it is recompiled.

For example let’s say you have a class like

public class Dog {
  public void Walk(Int32 distance) {
    /// blah blah
  }
}

and you call this in a page code behind:

protected void MyButtonClick(....) {
  Dog d = new Dog();
  d.Walk(3000);
}

When this compiles down the page will expect a walk method with an Int32 signature.

Now, let’s say we change the walk method in the Dog class to:

public void Walk(Int16 distance) {
  // blah blah
}

(yes, stupid change but it highlights the issue).
At this point the page will not be able to locate a Walk method that takes an Int32 parameter and so will blow up as it should.

---

It may seem nice to just deploy the one assembly you think you need, but the fact of the matter is there could be any number of changes that occurred in the code so this is a seriously bad practice.

It is much better to make sure the entire project is consistent. Even larger websites don’t take that long to deploy.

Of course,I think that using web site projects are bad practice in and of themselves anyway. Deploying uncompiled code to the server (really bad), VS searching your drive to update references in the project even when you have explicitly told it which assembly to use (usually unexpected, never good), having all the main code in a common app_code folder (limiting), etc. I could go on and on here…