Seuls les contrôles de contenu sont autorisés directement dans une page de contenu qui contient des contrôles de contenu dans ASP.NET
J'ai une application qui a une page maître et des pages enfants. Mon application fonctionne bien sur l'hôte local (sur mon intranet). Mais dès que je le mets sur un serveur qui est sur Internet, je reçois l'erreur indiquée ci-dessous après avoir cliqué sur n'importe quel menu.
Seuls les contrôles de contenu sont autorisés directement dans une page de contenu qui contient des contrôles de contenu.
Double et triple vérifier vos balises de contenu d'ouverture et de fermeture dans vos pages enfants.
Confirmez qu'ils
- existent
- sont orthographiés correctement
- avoir une pièce d'identité
- avoir runat = "serveur"
- avoir le ContentPlaceHolderID correct
J'avais exactement le même problème. Le problème était que j'avais quelques espaces après la balise de contenu de fin:
</asp:Content>
Supprimez tous les espaces, les sauts de ligne après la dernière balise de fermeture.
J'étais confronté à un problème similaire. Entourez-vous votre code de la balise "content"?
<asp:Content>Add your HTML here</asp:Content>
Et disposez de balises de contenu distinctes pour vos sections. Un contenu de tête pour la déclaration d'en-tête et un contenu de corps pour la déclaration de corps.
Une autre possibilité est la fin de ligne. J'ai copié une ancienne version de code à partir du contrôle de code source qui appliquait les fins de ligne de style Unix. Comme il ne s'agissait pas d'une extraction, il n'a pas converti automatiquement les fins de ligne au style DOS/Windows. Le message d'erreur était l'erreur "Seuls les contrôles de contenu sont autorisés directement ..." même si la page était correctement mise en page. Il semble que l'absence de sauts de ligne de style Windows ait provoqué l'échec de l'analyseur ASPX.
J'ai pu le corriger en collant le code dans un éditeur agnostique de fin de ligne (ce qui a normalisé les fins de ligne dans le style Windows), en le recopiant dans le presse-papiers et en le collant dans Visual Studio, après quoi la page traité sans erreur.
Dans le cas présenté par Tripati Subudhi dans la question, il est tout à fait possible que quelque chose au sujet du processus de déploiement utilise des terminaisons de ligne converties par inadvertance au style Unix, conduisant à l'erreur.
Un autre problème possible est les commentaires HTML, je les avais entourant un contrôle de contenu - je crois qu'ASP.NET les convertit en contrôles littéraux dans les coulisses - d'où l'erreur i
une autre cause potentielle de cette erreur: les balises avec le mauvais cas.
en changeant <asp:content>... à <asp:Content>... a résolu le problème dans mon cas.
la raison du cas défectueux était la fonction intégrée format document dans Visual Studio 2012 (et 2013) avec les paramètres par défaut. le paramètre pour cela peut être modifié dans Outils-> Options-> Éditeur de texte-> HTML (formulaires Web) -> Formatage: définissez la capitalisation des balises sur 'tel que saisi' et le studio ne détruira plus vos fichiers.
Pour moi, ça n'aimait pas que j'aie une Assemblée et une directive Page commentait:
<%--<%@ Assembly Name="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" %>--%>
<%--<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="MyPage.aspx.cs" Inherits="MyClass.MyPage" MasterPageFile="~/_layouts/MyProject/MasterPages/MasterPage.master" %>-->
Même si j'avais une directive Page valide après cela, et que je n'utilisais System.Core pour rien. Après les avoir simplement retirés, il s'est bien chargé.
Pour moi, c'était deux contrôles de contenu qui avaient le même ID - le fichier avait été modifié en dehors de Visual Studio, donc le renommage automatique de l'ID en double ne s'est pas produit. Cette erreur trompeuse mettait en évidence la première image à l'intérieur du deuxième contrôle de contenu avec le même ID que la première - quelle chasse à l'oie sauvage!
Copier la page entière et la republier sur elle-même l'a résolue, car VS à ce moment-là a ensuite renommé l'ID de contrôle en double.
Vérifiez votre document pour les caractères non imprimables
Ma page principale contenait deux BOM UTF-8 juste au début du fichier parce que j'ai collé le <%@ Master %> directive d'une autre page. J'ai pu le faire fonctionner en les reculant.
Dans mon cas, j'ai oublié d'ajouter la référence d'assemblage d'AjaxControlToolkit.dll.
Lorsque j'ajoute la référence, l'erreur a disparu.
J'ai eu une erreur de syntaxe idiote que je continuais à négliger. Il y avait un < Supplémentaire au début de ma balise MasterType que je ne pouvais pas voir pendant toute ma vie ???? ♂️.
<%@ Page Language="vb" AutoEventWireup="true" MasterPageFile="~/Site1.Master" CodeBehind="Default.aspx.vb" Inherits="SomeApp.Web._Default" %>
<<%@ MasterType VirtualPath="~/Site1.Master" %>
dans SharePoint, cela s'est produit car une mise en page n'a pas été publiée.