The full error is
The base class includes the field 'ScriptManager1', but its type (System.Web.UI.ScriptManager) is not compatible with the type of control (System.Web.UI.ScriptManager).
Anyone else come across this error?
The full error is
The base class includes the field 'ScriptManager1', but its type (System.Web.UI.ScriptManager) is not compatible with the type of control (System.Web.UI.ScriptManager).
Anyone else come across this error?
Adding the
<runtime>
section above fixed the problem on our dev machines and test server, but not our live servers.It turns out that if your
web.config
file contains an xmlns attribute ofxmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"
then you will get a GAC conflict:but this version from the devt machine is fine:
So make sure that 2.0 reference is removed from the top of your
web.config
file.After reading the answers here, I figured the problem was in how IIS is compiling the controls, using the wrong version. I fixed this problem by updating the production web.config: Under
<system.web>
add<httpRuntime targetFramework="4.5.1" />
I've run into this issue when upgrading a web application from .NET 2.0 to 3.5.
Check your web.config is correctly set for .NET 3.5. I added/changed the following:
I managed to fix it by adding this to web.config:
I believe it forces the .net runtime to use the new versions of those assemblies.
This can also be resolved by changing the project reference to System.Web.Extensions 1.0.61025 or other version, Make sure the project reference, web config and the ajax toolkit all match the same version.
We had a very similar problem. The development platform worked fine but once the site was deployed to the testing site it broke with the same message as the original poster above. We had subdirectories under our controls directory to group user controls together. The problem appeared to be a control in the subdirectory trying to use a control in the directory above it. Our first fix was to clone the toplevel control to the subdirectory. We then hit on the idea of creating a parallel sibling subdirectory and parking the control there. That fixed the problem without having to resort to (a) flattening our controls directory structure or (b) clone the same control in various subdirectories.
So our solution is to never refer to a control in a parent directory from a user control in a subdirectory.
I hope this helps out.