La classe de base inclut le champ 'X', mais son type (System.Web.UI.ScriptManager) n'est pas compatible avec le type de contrôle (System.Web.UI.ScriptManager).
L'erreur complète est
La classe de base comprend le champ 'ScriptManager1', mais son type (System.Web.UI.ScriptManager) n'est pas compatible avec le type de contrôle (System.Web.UI.ScriptManager).
Quelqu'un d'autre a rencontré cette erreur?
J'ai réussi à résoudre ce problème en ajoutant ceci à 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>
Je crois que cela oblige le runtime .net à utiliser les nouvelles versions de ces assemblys.
J'ai rencontré ce problème lors de la mise à niveau d'une application Web de .NET 2.0 à 3.5.
Vérifiez que votre Web.config est correctement défini pour .NET 3.5. J'ai ajouté/changé ce qui suit:
<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>
L'ajout de la section <runtime> ci-dessus a corrigé le problème sur nos machines de développement et notre serveur de test, mais pas nos serveurs réels.
Il se trouve que si votre fichier web.config contient un attribut xmlns de xmlns="http://schemas.Microsoft.com/.NetConfiguration/v2.0", vous obtiendrez un conflit GAC:
BAD.web.config
<?xml version="1.0"?>
<configuration xmlns="http://schemas.Microsoft.com/.NetConfiguration/v2.0">
etc
mais cette version de la machine devt est correcte:
GOOD.web.config
<?xml version="1.0"?>
<configuration>
etc
Assurez-vous donc que la référence 2.0 est supprimée en haut de votre fichier web.config.
Vous pouvez également résoudre ce problème dans le fichier .vbproj (dans mon cas). Vérifiez ces entrées:
<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>
Cela semble également forcer l'utilisation des DLL de la version 3.5.
Avait un problème similaire mise à jour de 3.5 à 4.0. Dans mon cas, il existe un site Web racine et des répertoires d'applications virtuels IIS sous celui-ci.
Le code a bien fonctionné dans mes domaines de développement et de préparation.
Dès qu'il est entré sur le serveur de production, il s'est écrasé. Même si le code était le même.
Ma solution était de supprimer le répertoire virtuel et de le recréer. S'assurer que le pool d'applications est correct et que la version asp.net est correcte. (Mes serveurs sont Windows Server 2003 avec IIS6).
Autre remarque importante: vous ne pouvez pas exécuter plusieurs versions d’asp.net dans le même pool d’applications.
dans mon cas, je viens de passer du framework de compilation de 2.0 à 3.5.
Pour ce faire, faites un clic droit sur le nom du projet (en haut de la solution Explorer) et sélectionnez "Pages de propriétés". à partir de là, sélectionnez l'option de construction et modifiez le cadre.
Il convient de mettre à jour web.config et toutes les références nécessaires.
HTH
Dave
Nous avons eu un problème très similaire. La plate-forme de développement fonctionnait bien, mais une fois que le site a été déployé sur le site de test, le message était identique à celui de l’affiche originale ci-dessus. Le problème semblait être un contrôle dans le sous-répertoire essayant d'utiliser un contrôle dans le répertoire ci-dessus. Notre premier correctif consistait à cloner le contrôle de niveau supérieur dans le sous-répertoire. Nous avons ensuite eu l’idée de créer un sous-répertoire parallèle pour y placer le contrôle. Cela a résolu le problème sans avoir à recourir à (a) l'aplatissement de la structure de notre répertoire de contrôles ou (b) la duplication du même contrôle dans divers sous-répertoires.
Notre solution consiste donc à ne jamais faire référence à un contrôle d'un répertoire parent à partir d'un contrôle utilisateur situé dans un sous-répertoire.
J'espère que cela aide.
Cela peut également être résolu en modifiant la référence du projet en System.Web.Extensions 1.0.61025 ou une autre version. Assurez-vous que la référence du projet, la configuration Web et le kit d'outils ajax correspondent tous à la même version.
Nous avons eu le même problème lors de la précompilation de notre application à partir de la ligne de commande à l'aide de l'indicateur "L'application est modifiable":
aspnet_compiler.exe -u
supprimer le drapeau -u a résolu ce problème. Ne me demande pas pourquoi!
"La classe de base inclut le champ 'ScriptManager1', mais son type (System.Web.UI.ScriptManager) n'est pas compatible avec le type de contrôle (System.Web.UI.ScriptManager). . "
Quelqu'un d'autre a rencontré cette erreur?
J'ai eu ce genre d'erreur plusieurs fois, mais pas spécifiquement avec Scriptmanager. En gros, cela se produit lorsque vous avez le contrôle d’un type sur la page. Et disons que vous avez été inactif pendant un certain temps. Mais ensuite, vous avez supprimé le contrôle et en avez placé un autre à la place avec le même ID, c'est-à-dire qu'il peut se produire. Je crois qu'il est lié à ou créé par un aspx.designer.cs obsolète.
Pour résoudre le problème. J'ai dû changer le nom de l'ID du contrôle ou reconstruire la solution. Je pense qu'il y a une autre façon aussi. Je pense que si vous avez un fichier aspx.designer.cs du nom du fichier aspx, vous pouvez également le modifier.
Après avoir lu les réponses ici, j’ai pensé que le problème tenait à la manière dont IIS compile les contrôles, en utilisant la mauvaise version. J'ai résolu ce problème en mettant à jour le fichier Web.config de production: Sous <system.web> Ajouter <httpRuntime targetFramework="4.5.1" />
Problème très similaire. "La classe de base inclut le champ 'WebUserControl1', mais son type (common_WebUserControl) est ..." a modifié les fichiers de marquage de CodeFile= à CodeBehind=.