2009-03-04 23 views
2

J'ai un problème étrange dans mon projet. J'ai une classe qui hérite d'une classe de base (qui hérite à nouveau d'une autre classe de base) et remplace une fonction. Cependant, lorsque cette fonction est appelée, elle n'appelle jamais la fonction surchargée, mais la fonction de base.Fonction virtuelle ignorée non appelée

Cependant, lorsque je remplace cette fonction dans la classe moyenne, elle est appelée. Mais cela est source de confusion: nous allons expliquer avec un dessin :)

  • lib GuiShared

    • classe BSCREEN
      • fonction virtuelle InitializeRoc
  • lib TigerControlRoot

    • classe bTigerScreen
      • override InitializeRoc < - quand il overriden ici est appelé
  • lib TigerControlRootCommonScreens
    • CheckInRules classe
      • override InitializeRoc < - pas appelé: de

Le constructeur est appelé ... Mais

Voici mon (simplifié) Code:

La base commune classe

namespace Ppb.GuiShared.Screens { 
    public partial class bScreen<T> : Ppb.Controls.pPanel where T : FrameworkMiddleware.Framework.Remoting.Remotable, FrameworkMiddleware.IInitialize, new() { 
     public virtual void Load(bMain<T>.LoadEventArgs args) { 
      log.Trace("InitializeRoc " + this.GetType().FullName); 
      InitializeRoc(args); 
      _hasLoaded = true; 
     } 

     protected virtual void InitializeRoc(bMain<T>.LoadEventArgs args) { } 
    } 
} 

classe de base projet

namespace Tiger.ControlRoot.Screens { 
    public partial class bTigerScreen : Ppb.GuiShared.Screens.bScreen<roc.Tiger> { 
     public bTigerScreen(GuiSettings settings, roc.Tiger tiger) 
      : base(settings, tiger) { 
      InitializeComponent(); 
      InitializeMenu(); 
     } 
    } 
} 

La classe d'échec (ou de toute autre classe de cette lib)

namespace Tiger.ControlRoot.CommonScreens { 
    [ControlRoot.Screens.TigerScreenInfo("Testje", Tiger.ControlRoot.Screens.TigerScreenInfoAttribute.elevel.User, true)] 
    public class CheckInRules : ControlRoot.Screens.bTigerScreen { 

     public CheckInRules(GuiSettings settings, roc.Tiger tiger) 
      : base(settings, tiger) { 

     } 

     protected override void InitializeRoc(Ppb.GuiShared.bMain<TigerMiddleware.TigerRoc.Tiger>.LoadEventArgs args) { 
      base.InitializeRoc(args); 
     } 
    } 
} 

Et si cela ne suffisait pas, quand je tente d'appeler une fonction de la classe de base I recevez une exception TypeLoadException.

GenericArguments[0], 'TigerMiddleware.TigerRoc.Tiger', on 'Ppb.GuiShared.bMain`1+LoadEventArgs[T]' violates the constraint of type parameter 'T'.

Un code similaire avec le même GuiShared lib est utilisé dans un autre projet et il n'y a pas de problèmes.

+0

Veuillez fournir un programme court mais complet (de préférence une application de console) pour démontrer le problème. Les extraits que nous avons en ce moment ne sont pas vraiment clairs (pour moi, de toute façon). –

+0

Pouvez-vous nous montrer la définition de TigerMiddleware.TigerRoc.Tiger? –

Répondre

4

Ok, merci pour toutes les réponses, mais je l'ai corrigé entre-temps.Le problème était le suivant: La classe défaillante est dans une DLL à partir de laquelle son chemin de sortie en mode débogage est défini sur le dossier du plugin de l'exécutable. Aucun problème jusqu'à présent, mais il copie également ses dépendances dans ce dossier.
Toutefois, certaines dépendances sont déjà copiées dans le dossier racine de l'exécutable. L'exécutable lors des démarrages recherche tous les plugins dans le dossier plugin et instancie le plugin. Le problème est alors que le plugin utilise les dépendances de dans le dossier plugins alors que l'exécutable utilise les dépendances du dossier racine qui sont fondamentalement le même fichier dans un répertoire différent, donc en cours d'exécution le clr les voit comme 2 dll différentes et cela confond vraiment le clr :). Ainsi, lorsque les dépendances partagées ne sont pas copiées dans le dossier plugins, tout fonctionne bien car les plugins utilisent les définitions du dossier racine et donc les mêmes DLL.

+0

Vous devriez probablement accepter votre propre réponse, de sorte que cela n'apparaisse plus comme "sans réponse". – oefe

+0

@oefe J'ai essayé, mais j'ai dû attendre 48 heures :) – Stormenet