Erreurs du compilateur sur la page maître

Question

Quelqu'un a-t-il des conseils pour déplacer une page maître d'une solution/application à une autre?

J'ai copié une page maître à partir d'une solution existante à une nouvelle.

La solution d'origine se construit et fonctionne bien.

Dans la nouvelle solution, les causes des erreurs de page

Ceux-ci sont principalement « variables » non déclarés.

J'ai commenté tout le code du serveur pour la page, à l'exception de 2 déclarations très simples.

déclaration 1 référence à un contrôle qui est dans le balisage de la page originale

pgLoginView.EnableViewState = True 

Statement 2 fait référence à un contrôle qui a été récemment ajouté à des fins de test

lblFrogs.Text = "sdfgsd" 

Il est comme si le compilateur ne connaît pas des membres de la classe qui devraient être générés à partir du balisage. J'ai vérifié les fichiers de balisage L'attribut 'Inherits' est correctement défini. Lorsque j'invoque intellisense dans l'éditeur de code, les deux objets (lblFrogs et pgLoginView) sont répertoriés et listent leurs propriétés et méthodes correctement après avoir appuyé sur '.'

Toute aide ou idées relatives à ce problème seront grandement appréciés. Je suis à bout de nerfs - c'était un court voyage.

Answer 1

J'ai enfin trouvé la source de mon malheur avec l'objet Profile.

Premièrement, la fonctionnalité de profil est uniquement disponible dans le projet de type site Web. Cependant, comme le projet a déjà été converti en type de site Web pour résoudre le premier problème en référençant des éléments de page, pourquoi l'objet de profil n'est-il pas devenu disponible?

La réponse est que la conversion ne modifie pas le balisage de page. L'emplacement du code derrière doit être spécifié avec "CodeFile", et l'attribut Inherits doit avoir les informations d'espace de nom de premier plan tronquées. Exemple:

Answer 2

Vous devriez vérifier le code de concepteur généré pour votre page maître - bien que la page .aspx/.master soit utilisée à l'exécution pour créer des instances de tous les contrôles sur votre page, à la compilation toutes les informations sur les contrôles présent sur le balisage est contenu dans la classe partielle dans le fichier .designer.master:

public partial class Site1 
{ 
    /// <summary> 
    /// ContentPlaceHolder1 control. 
    /// </summary> 
    /// <remarks> Auto-generated field.</remarks> 
    protected global::System.Web.UI.WebControls.ContentPlaceHolder ContentPlaceHolder1; 

    // Etc... 
} 

Si cette page ne contient pas contenir le code généré correctement alors je suis sûr que pas vraiment quoi penser autre que le jeu avec ou si vous êtes vraiment bloqué déclarer les contrôles vous-même - j'ai déjà eu ce problème, mais je ne sais pas grand-chose sur la façon dont le code du concepteur est généré.

Si c'est pas le porblem êtes vous sûr que hasnt studio visuel a décidé de renommer l'un des contrôles?

Answer 3

christian-hayter Semblait être sur la bonne voie. J'ai converti le projet à un projet de site Web et le problème est parti.

Il semblerait que la cause profonde puisse rester un mystère.

Answer 4

Quelque chose est certainement devenu fou furieux avec la compilation de cette page.

Je ne parviens pas à faire référence à la propriété Profile. Ce article from Dino Esposito dit que l'objet de profil est ajouté à la page dans le cadre du processus de compilation comme ceci:

Profil ProfileCommon protégé {get { retour ((ProfileCommon) (Contexte.Profil)); }}

Quand je fais une découverte dans les fichiers pour ProfileCommon dans un projet de travail, je reçois beaucoup de résultats des fichiers temporaires de asp.net. Dans le projet cassé, ProfileCommon ne se trouve dans aucun des fichiers.