7
votes

MEF 'L'exportation n'est pas assignable à l'erreur de type'

Je viens de commencer à utiliser Mef et j'ai frappé sur un problème précoce.

J'ai une interface appelée DataService: p> xxx pré>

Il y a 2 implémentations de cette interface, un pour SQL Server et un pour Oracle. Vous trouverez ci-dessous la mise en œuvre Oracle, la mise en oeuvre SQL Server est exactement la même. P>

    private static CompositionContainer _container;
    private const string ASSEMBLY_PATTERN = "*.dll";
    private AggregateCatalog _catalog; 

    [ImportMany]
    IEnumerable<DataAccess.IDataService> services { get; set; }

    private void button3_Click(object sender, EventArgs e)
    {


        _catalog = new AggregateCatalog(
            new DirectoryCatalog(txtLibPath.Text, ASSEMBLY_PATTERN),
            new AssemblyCatalog(Assembly.GetExecutingAssembly()));
        _container = new CompositionContainer(_catalog);
        _container.ComposeParts(this);
        MessageBox.Show(services.Count().ToString());
    }

c# mef

0 commentaires

4 Réponses :

8
votes

Il ressemble à deux versions différentes de votre assemblage contractuel (celui avec dataaccess.idataservice) sont chargés. L'un est probablement de votre chemin exécutable et de l'autre de votre chemin de plug-in. Je touche un peu sur cette question dans mon poteau de blog sur Comment déboguer et diagnostiquer les défaillances du MEF et la page MSDN sur meilleur Les pratiques de chargement de montage vont dans plus de détails.

2 commentaires

Vous étiez à droite Daniel, j'avais re-compilé Idataservice pour les projets contenant les plugins SQLServer et Oracle, mais faisait référence à une version plus ancienne dans l'application principale. J'ai déplacé l'idataserservice dans un projet de bibliothèque de classe distincte et j'ai référé cela des trois projets et tous les œuvres parfaitement. Merci beaucoup.

C'est un problème assez fastidieux. Il ne suffit pas de vérifier que votre projet EXE, mais également des projets de tous les assemblages satellitaires qu'elle charge. Dans mes projets EXE chargé de plus de 50 autres assemblages satellitaires et j'avais un suivi difficile, lequel provoque cette charge en double. Si ce n'est pas un indice brillant de Daniel, je ne sais pas combien de temps je pourrais passer le résoudre.

0
votes

Pour moi, cela avait une solution très simple.

Voici un lien ! cela explique la cause fondamentale.

Dans mon cas, j'ai verrouillé la version de mon assemblage, mais ma version de fichier voyage. Mon identifiant de package Nuget correspond à ma version de fichier de mon assemblage.

résultat final est que je peux construire en permanence, créer de nouveaux nucides et ne pas avoir ce problème d'intégration du MEF.

0 commentaires

0
votes

Je dois dire que j'ai eu une telle erreur dans un contexte complètement idiot. Accidentellement, j'ai égaré la directive à l'exportation et le mettez-le pas sur la classe, mais sur une fonction à l'intérieur de la classe: xxx

surprenant, le code compilait très bien sans aucun avertissement. Mais alors j'ai passé des heures à essayer de comprendre pourquoi le MEF échoue sur mon mal idiot!

0 commentaires

1
votes

Encore une autre cause:

Code: P>

interface IMyService
{
}

[Export(typeof(IMyService))]
class MyService
{
}

0 commentaires