El error completo esClase base incluye el campo 'X', pero su tipo (System.Web.UI.ScriptManager) no es compatible con el tipo de control (System.Web.UI.ScriptManager)
La clase base incluye el campo 'ScriptManager1', pero su tipo (System.Web.UI.ScriptManager) no es compatible con el tipo de control (System.Web.UI.ScriptManager).
¿Alguien más ha encontrado este error?
me las arreglé para solucionarlo añadiendo esto a web.config:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Web.Extensions" publicKeyToken="31bf3856ad364e35"/>
<bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="3.5.0.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Web.Extensions.Design" publicKeyToken="31bf3856ad364e35"/>
<bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="3.5.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
Creo que obliga al tiempo de ejecución de .NET para utilizar las nuevas versiones de esas asambleas.
Me he encontrado con este problema al actualizar una aplicación web de .NET 2.0 a 3.5.
Compruebe que su web.config esté configurado correctamente para .NET 3.5. Añadí/modifican los siguientes:
<configSections>
<sectionGroup name="system.web.extensions" type="System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
<sectionGroup name="scripting" type="System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
<section name="scriptResourceHandler" type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication"/>
<sectionGroup name="webServices" type="System.Web.Configuration.ScriptingWebServicesSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
<section name="jsonSerialization" type="System.Web.Configuration.ScriptingJsonSerializationSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="Everywhere"/>
<section name="profileService" type="System.Web.Configuration.ScriptingProfileServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication"/>
<section name="authenticationService" type="System.Web.Configuration.ScriptingAuthenticationServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication"/>
<section name="roleService" type="System.Web.Configuration.ScriptingRoleServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication"/>
</sectionGroup>
</sectionGroup>
</sectionGroup>
</configSections>
<assemblies>
<!--<add assembly="System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>-->
<add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Data.DataSetExtensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
</assemblies>
<httpHandlers>
<remove verb="*" path="*.asmx"/>
<add verb="*" path="*.asmx" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" validate="false"/>
<add verb="*" path="*_AppService.axd" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" validate="false"/>
<httpHandlers>
<pages enableSessionState="true" validateRequest="true">
<controls>
<add tagPrefix="asp" namespace="System.Web.UI" assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add tagPrefix="asp" namespace="System.Web.UI.WebControls" assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
</controls>
</pages>
<httpModules>
<add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
</httpModules>
Tuvimos un problema muy similar. La plataforma de desarrollo funcionó bien, pero una vez que el sitio se implementó en el sitio de prueba se rompió con el mismo mensaje que el póster original anterior. Teníamos subdirectorios en nuestro directorio de controles para agrupar controles de usuario. El problema parecía ser un control en el subdirectorio que intentaba usar un control en el directorio de arriba. Nuestra primera solución fue clonar el control toplevel en el subdirectorio. A continuación, nos topamos con la idea de crear un subdirectorio hermano paralelo y estacionar el control allí. Eso solucionó el problema sin tener que recurrir a (a) aplanamiento de nuestra estructura de directorio de controles o (b) clonar el mismo control en varios subdirectorios.
Así que nuestra solución es no referirnos nunca a un control en un directorio padre desde un control de usuario en un subdirectorio.
Espero que esto ayude.
Esto también se puede resolver cambiando la referencia del proyecto a System.Web.Extensions 1.0.61025 u otra versión, asegúrese de que la referencia del proyecto, la configuración web y el toolkit ajax coincidan con la misma versión.
Al agregar la sección anterior <runtime> solucionó el problema en nuestras máquinas de desarrollo y servidor de prueba, pero no en nuestros servidores activos.
Resulta que si el archivo web.config contiene un atributo xmlns de xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0" por lo que recibirá un conflicto GAC:
BAD.web.config
<?xml version="1.0"?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
etc
pero esta versión de la máquina DEVT está bien:
GOOD.web.config
<?xml version="1.0"?>
<configuration>
etc
Así que asegúrese de que la referencia 2.0 se elimine de la parte superior de su archivo web.config.
Hemos tenido este mismo problema al precompilar nuestra aplicación desde la línea de comandos usando la "Solicitud es actualizable" bandera:
aspnet_compiler.exe -u
retirar la bandera -u resuelto este problema. No me preguntes por qué!
También puede resolver este problema en el archivo .vbproj (en mi caso). Compruebe estas entradas:
<Reference Include="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<RequiredTargetFramework>3.5</RequiredTargetFramework>
</Reference>
<Reference Include="System.Web.Extensions.Design, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<RequiredTargetFramework>3.5</RequiredTargetFramework>
</Reference>
Esto también parece forzar el uso de las DLL de versión 3.5.
Problema muy similar. "La clase base incluye el campo 'WebUserControl1', pero su tipo (common_WebUserControl) es ..." archivos de marcado modificados de CodeFile= a CodeBehind=
en mi caso, simplemente cambié el marco de compilación de 2.0 a 3.5.
Esto se hace haciendo clic derecho en el nombre del proyecto (parte superior del explorador de soluciones) y seleccionar "Páginas de propiedades". a partir de ahí, seleccione la opción de compilación y cambie el marco.
Debe actualizar web.config y todas las referencias necesarias.
HTH
de Dave
tenido una actualización de problemas similares entre 3,5 y 4,0. En mi caso, hay un sitio web raíz y directorios de aplicaciones IIS virtuales debajo de esto.
El código funcionó bien en mis áreas de desarrollo y puesta en escena.
Tan pronto como entró en el servidor de producción, se bloqueó. Aunque el código era el mismo.
Mi solución fue eliminar el directorio virtual y volver a crearlo. Asegurándose de que el grupo de aplicaciones sea correcto y que la versión de asp.net sea correcta. (mis servidores son Windows Server 2003 con IIS6).
Otra nota importante: no puede ejecutar múltiples versiones de asp.net en el mismo grupo de aplicaciones.
"La clase base incluye el campo 'ScriptManager1', pero su tipo (System.Web.UI.ScriptManager) no es compatible con el tipo de control (System.Web.UI.ScriptManager)."
¿Alguien más ha encontrado este error?
He tenido ese tipo de error varias veces, aunque no específicamente con scriptmanager. Básicamente sucede cuando tienes un control de un tipo en la página. Y digamos que estuvo inactivo por algún tiempo. Pero luego eliminó el control y puso otro en su lugar con la misma ID, es decir, cuando puede ocurrir. Creo que está relacionado o creado por un aspx.designer.cs fuera de fecha.
Para solucionar el problema. O tuve que cambiar el nombre de la ID del control o reconstruir la solución. Creo que hay otra manera también. Creo que si tiene un archivo aspx.designer.cs del nombre del archivo aspx, puede cambiarlo allí también.
Parece ser un duplicado. Refiérase a la respuesta de Mitchell aquí: http://stackoverflow.com/questions/582492/working-with-vs2008-3-5-asp-ajax-site-on-a-2-0sp1-ajax-extesnion-1-0-server –