MetadataException: impossible de charger la ressource de métadonnées spécifiée

Tout d'un coup, je continue MetadataExceptionà instancier ma ObjectContextclasse générée . La chaîne de connexion dans App.Config semble correcte - n'a pas changé depuis le dernier fonctionnement - et j'ai essayé de régénérer un nouveau modèle (fichier edmx) à partir de la base de données sous-jacente sans changement.

Quelqu'un a des idées?

Plus de détails: je n'ai changé aucune propriété, je n'ai changé le nom d'aucun assemblage de sortie, je n'ai pas essayé d'incorporer l'EDMX dans l'assemblage. J'ai simplement attendu 10 heures avant de quitter le travail jusqu'à mon retour. Et puis ça ne marchait plus.

J'ai essayé de recréer l'EDMX. J'ai essayé de recréer le projet. J'ai même essayé de recréer la base de données à partir de zéro. Pas de chance que ce soit.

Cela signifie que l'application n'est pas en mesure de charger l'EDMX. Il y a plusieurs choses qui peuvent provoquer cela.

• Vous avez peut-être changé la propriété MetadataArtifactProcessing du modèle en Copier dans le répertoire de sortie.
• La chaîne de connexion est peut-être incorrecte. Je sais que vous dites que vous ne l'avez pas changé, mais si vous avez changé d'autres choses (par exemple, le nom d'une assemblée), cela pourrait toujours être faux.
• Vous utilisez peut-être une tâche de post-compilation pour incorporer l'EDMX dans l'assembly, qui ne fonctionne plus pour une raison quelconque.

En bref, il n'y a pas vraiment assez de détails dans votre question pour donner une réponse précise, mais j'espère que ces idées devraient vous mettre sur la bonne voie.

Mise à jour: j'ai écrit un article de blog avec des étapes plus complètes pour le dépannage .

Ce petit changement aide à résoudre ce problème.

J'ai Solution avec 3 projets.

connectionString="metadata=res://*/Model.Project.csdl|res://*/Model.Project.ssdl|res://*/Model.Project.msl;

changer pour

connectionString="metadata=res://*/;

Vous pouvez obtenir cette exception lorsque l'Edmx se trouve dans un projet et que vous l'utilisez dans un autre.

La raison est Res://*/ un uri qui pointe vers des ressources dans l'assembly CURRENT. Si l'Edm est défini dans un assembly différent du code qui l'utilise, res: // * / ne fonctionnera pas car la ressource est introuvable.

Au lieu de spécifier '*', vous devez fournir le nom complet de l'assembly à la place (y compris le jeton de clé publique). Par exemple:

res://YourDataAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=abcdefabcedf/YourEdmxFileName.csdl|res://...

Une meilleure façon de construire des chaînes de connexion est avec EntityConnectionStringBuilder:

public static string GetSqlCeConnectionString(string fileName)
{
    var csBuilder = new EntityConnectionStringBuilder();

    csBuilder.Provider = "System.Data.SqlServerCe.3.5";
    csBuilder.ProviderConnectionString = string.Format("Data Source={0};", fileName);

    csBuilder.Metadata = string.Format("res://{0}/YourEdmxFileName.csdl|res://{0}/YourEdmxFileName.ssdl|res://{0}/YourEdmxFileName.msl", 
        typeof(YourObjectContextType).Assembly.FullName);

    return csBuilder.ToString();
}

public static string GetSqlConnectionString(string serverName, string databaseName)
{
    SqlConnectionStringBuilder providerCs = new SqlConnectionStringBuilder();

    providerCs.DataSource = serverName;
    providerCs.InitialCatalog = databaseName;
    providerCs.IntegratedSecurity = true;

    var csBuilder = new EntityConnectionStringBuilder();

    csBuilder.Provider = "System.Data.SqlClient";
    csBuilder.ProviderConnectionString = providerCs.ToString();

    csBuilder.Metadata = string.Format("res://{0}/YourEdmxFileName.csdl|res://{0}/YourEdmxFileName.ssdl|res://{0}/YourEdmxFileName.msl",
        typeof(YourObjectContextType).Assembly.FullName);

    return csBuilder.ToString();
}

Si vous rencontrez toujours l'exception, ouvrez l'assembly dans le réflecteur et vérifiez les noms de fichiers pour vos fichiers .csdl, .ssdl et .msl. Lorsque les ressources ont des noms différents de ceux spécifiés dans la valeur des métadonnées, cela ne fonctionnera pas.

J'ai eu une erreur similaire. J'avais recréé le projet (longue histoire) et retiré tout de l'ancien projet. Je ne m'étais pas rendu compte que mon modèle se trouvait auparavant dans un répertoire appelé «Model» et se trouvait maintenant dans un répertoire appelé «Models». Une fois que j'ai changé la connexion dans mon Web.Config de ceci:

<add name="RecipeManagerEntities" connectionString="metadata=res://*/Model.Recipe.csdl 

pour ça:

<add name="RecipeManagerEntities" connectionString="metadata=res://*/Models.Recipe.csdl

Tout a fonctionné (changé Modelen Models). Notez que j'ai dû changer ces trois endroits dans cette chaîne.

Et un moyen rapide de vérifier le nom du modèle sans réflecteur .... recherchez le répertoire

... obj / {sortie de configuration} / edmxResourcesToEmbed

et vérifiez que les fichiers de ressources .csdl, .msl et .ssdl sont là. S'ils se trouvent dans un sous-répertoire, le nom du sous-répertoire doit être ajouté au nom du modèle.

Par exemple, mes trois fichiers de ressources sont dans un sous-répertoire Data , donc ma chaîne de connexion devait être

métadonnées = res: // * / Data .MyModel.csdl | res: // * / Data .MyModel.ssdl | res: // * / Data .MyModel.msl;

(par rapport aux métadonnées = res: //*/MyModel.csdl | res: //*/MyModel.ssdl | res: //*/MyModel.msl;).

J'ai également eu ce problème et c'était parce que la chaîne de connexion dans mon web.config était légèrement différente de celle dans l'app.config de l'assembly où se trouve mon EDMX. Je ne sais pas pourquoi cela a changé, mais voici les deux versions différentes.

App.config:

<add name="SCMSEntities" connectionString="metadata=res://*/Model.SMCSModel.csdl|res://*/Model.SMCSModel.ssdl|res://*/Model.SMCSModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=SANDIEGO\sql2008;initial catalog=SCMS;integrated security=True;multipleactiveresultsets=True;application name=EntityFramework&quot;" providerName="System.Data.EntityClient" />

Web.config:

<add name="SCMSEntities" connectionString="metadata=res://*/Model.SCMSModel.csdl|res://*/Model.SCMSModel.ssdl|res://*/Model.SCMSModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=SANDIEGO\sql2008;initial catalog=SCMS;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework&quot;" providerName="System.Data.EntityClient" />

Ce qui l'a corrigé était simplement de copier la chaîne app.config (notez la petite différence à la fin - au lieu de " App=EntityFramework" il voulait " application name=EntityFramework") dans le web.config et le problème a été résolu. :)

Cela m'est arrivé lorsque j'ai basculé accidentellement l'action de génération du fichier edmx (qui apparaît sous Propriétés dans l'EDI) de «EntityDeploy» à «None». EntityDeploy est ce qui remplit les métadonnées pour vous: voir http://msdn.microsoft.com/en-us/library/cc982037.aspx

Cela m'arrive lorsque je ne nettoie pas la solution avant de créer un nouveau concepteur .edmx. N'oubliez donc pas de nettoyer la solution avant de créer un nouveau concepteur .edmx. Cela m'aide à ignorer beaucoup plus de problèmes avec celui-ci. Ci-dessous les détails de navigation fournis dans le cas où vous êtes nouveau dans Visual Studio.

Cliquez sur-> Build-> Clean Solution

Cliquez ensuite sur-> Build-> Rebuild Solution

J'espère que cela t'aides. Merci tout le monde

Je viens de passer 30 bonnes minutes avec ça. J'avais renommé l'objet entités, renommé l'entrée dans le fichier de configuration, mais il y a plus ... vous devez également changer la référence au csdl

très facile à manquer - si vous renommez, assurez-vous que vous obtenez tout ....

J'ai eu le même problème. J'ai regardé ma dll conforme avec réflecteur et j'ai vu que le nom de la ressource n'était pas correct. J'ai renommé et ça va bien maintenant.

Pour mon cas, il est résolu en modifiant les propriétés du fichier edmx.

1. Ouvrez le fichier edmx
2. Faites un clic droit sur n'importe quel endroit du concepteur EDMX
3. choisir les propriétés
4. Mettre à jour la propriété appelée "Traitement des artefacts de métadonnées" en "Incorporer dans l'assemblage de sortie"

Cela a résolu le problème pour moi. Le problème est que lorsque le conteneur essaie de trouver les métadonnées, il ne peut pas les trouver. alors faites-le simplement dans le même assemblage. cette solution ne fonctionnera pas si vous avez vos fichiers edmx dans un autre assembly

J'ai passé une journée entière sur cette erreur

si vous travaillez avec n-tear architecture

ou vous avez essayé de separate Modelsgénérer par le EDMXformulaire DataAccessLayer pourDomainModelLayer

vous obtiendrez peut-être cette erreur

1. Étape de dépannage est d' abord de vous assurer que la chaîne de connexion dans webconfig (UILayer)et appconfig (DataAccessLayer)sont les mêmes

2. Deuxièmement, ce qui est très important, le connection string

   connectionString="metadata=res://*/Model.csdl|res://*/Model.ssdl|res://*/Model.msl;provid.....

   quel est le problème

d'où je viens Modelou quoi que ce soit .csdl dans ma chaîne de connexion où sont-ils

ici, je notre solution regarde l'image

j'espère que l'aide vous

J'ai pu résoudre ce problème dans Visual Studio 2010, VB.net (ASP.NET) 4.0.

Pendant l'assistant de modèle d'entité, vous pourrez voir la chaîne de connexion d'entité. De là, vous pouvez copier et coller dans votre chaîne de connexion.

La seule chose qui me manquait était le "App_Code". dans la chaîne de connexions.

entityBuilder.Metadata = "res://*/App_Code.Model.csdl|res://*/App_Code.Model.ssdl|res://*/App_Code.Model.msl"

Après des heures de recherche sur Google et d'essayer de résoudre aucune des solutions suggérées n'a fonctionné. J'ai énuméré plusieurs solutions ici. J'ai également noté celui qui a fonctionné pour moi. (J'utilisais EF version 6.1.1 et SQL Server 2014 - mais une ancienne base de données)

1. Reconstruisez le projet et réessayez.
2. Fermez et ouvrez VS - Je ne sais pas comment cela fonctionne
3. assurez-vous que si vous avez placé le fichier .EDMX dans un répertoire, assurez-vous d'inclure les répertoires dans votre ConnectionString. par exemple, le mien se trouve dans le dossier DAL. SO cela ressemble à ceci: connectionString="metadata=res://*/DAL.nameModel.csdl|res://*/DAL.nameModel.ssdl|res://*/DAL.nameModel.msl;(ce sont des fichiers. Pour les voir, vous pouvez basculer Afficher tous les fichiers dans l'explorateur de solutions, sous le répertoire ~ / obj / ..)

... et bien d'autres que j'avais essayés [comme: rétablir la version EntityFramework à une version ultérieure (je n'en suis pas sûr)]

ce qui a fonctionné pour moi:

de cet article ici , il m'a aidé à résoudre mon problème. Je viens de changer mon ProviderManifestToken="2012"pour ProviderManifestToken="2008"dans le fichier EDMX. Pour faire ça:

Explorateur de solution

1. Faites un clic droit sur le fichier .edmx
2. Ouvrir avec..
3. Editeur XML
4. Modifier ProviderManifestToken = "XXXX" avec 2008

J'espère que ça aide.

Si vous utilisez l'edmx d'un autre projet, dans la chaîne de connexion, changez ...

metadata=res://*/Data.DataModel.csdl

...à...

metadata=res://*/DataModel.csdl

La solution ultime (même après avoir recréé la base de données sur deux autres machines, ainsi que l'EDMX et d'autres articles) était de ne pas utiliser la première édition d'Entity Framework. Au plaisir de l'évaluer à nouveau dans .NET 4.0.

Après avoir exécuté le même problème à nouveau et la recherche dans toute une réponse, j'ai enfin trouvé quelqu'un qui avait eu le même problème. Il semble que la chaîne de connexion n'ait pas été correctement générée par l'assistant de Visual Studio et que le lien vers les ressources de métadonnées manquait un chemin important.

v1.0 BUG?: impossible de charger la ressource de métadonnées spécifiée. Scripts! = Modèles

Mise à jour 2013-01-16 : Ayant effectué une transition vers l'utilisation presque exclusive des pratiques EF Code First (même avec les bases de données existantes), ce problème n'est plus un problème. Pour moi, c'était une solution viable pour réduire l'encombrement du code et de la configuration générés automatiquement et augmenter mon propre contrôle sur le produit.

Mon problème et ma solution, les symptômes étaient les mêmes "Impossible de charger la ressource de métadonnées spécifiée" mais la cause première était différente. J'avais 2 projets dans la solution, l'un était l'EntityModel et l'autre la solution. J'ai en fait supprimé et recréé le fichier EDMX dans EntityModel.

La solution était que je devais retourner au projet d'application Web et ajouter cette ligne dans le fichier de configuration. Le nouveau modèle avait modifié quelques éléments qui devaient être dupliqués dans le fichier Web.Config du projet «autre». L'ancienne configuration n'était plus bonne.

     <add name="MyEntities"
     connectionString="metadata=res://*/Model1.csdl|res://*/Model1.ssdl|res://*/Model1.msl;
                    provider=System.Data.SqlClient;
                    provider connection string=&quot;
                    data source=Q\DEV15;initial catalog=whatever;
                    user id=myuserid;password=mypassword;
                    multipleactiveresultsets=True;
                    application name=EntityFramework&quot;"
     providerName="System.Data.EntityClient" />

Parfois, je vois cette erreur dans mon projet. Je résous ça en

1 - Clic droit sur le fichier EDMX

2 - Sélectionnez une Run Custom Tooloption

3 - Projet de reconstruction

Dans mon cas, ce problème était lié au changement de nom du fichier edmx de mon modèle ... la correction de la chaîne de connexion app.config pour les fichiers csdl / ssdl / msl a résolu mon problème.

Si vous utilisez le concepteur EF 4.0 pour générer votre csdl / ssdl / msl, ces 3 "fichiers" seront en fait stockés dans le fichier edmx principal du modèle. Dans ce cas, le message de Waqas est à peu près au rendez-vous. Il est important de comprendre que "Model_Name" dans son exemple devra être changé en quelque soit le nom actuel du fichier .edmx de votre modèle (sans le .edmx).

De plus, si votre fichier edmx n'est pas au niveau racine de votre projet, vous devez faire précéder Model_Name du chemin relatif, par exemple

res://*/MyModel.WidgetModel.csdl|res://*/MyModel.WidgetModel.ssdl|res://*/MyModel.WidgetModel.msl

spécifierait que le xml csdl / ssdl / msl est stocké dans le fichier modèle 'WidgetModel.edmx' qui est stocké dans un dossier nommé 'MyModel'.

J'ai écrit cette classe d'assistance pour créer des instances d'objets ObjectContext lorsqu'ils sont définis dans un projet différent de celui qui l'utilise. J'analyse la chaîne de connexion dans le fichier de configuration et remplace «*» par le nom complet de l'assembly.

Ce n'est pas parfait car il utilise la réflexion pour construire l'objet, mais c'est la façon la plus générique de le faire que j'ai pu trouver.

J'espère que cela aide quelqu'un.

public static class EntityHelper<T> where T : ObjectContext
{
    public static T CreateInstance()
    {
        // get the connection string from config file
        string connectionString = ConfigurationManager.ConnectionStrings[typeof(T).Name].ConnectionString;

        // parse the connection string
        var csBuilder = new EntityConnectionStringBuilder(connectionString);

        // replace * by the full name of the containing assembly
        csBuilder.Metadata = csBuilder.Metadata.Replace(
            "res://*/",
            string.Format("res://{0}/", typeof(T).Assembly.FullName));

        // return the object
        return Activator.CreateInstance(typeof(T), csBuilder.ToString()) as T;
    }
}

Pour vous tous SelftrackingEntities , si vous avez suivi la procédure pas à pas de Microsoft et séparé la classe de contexte Object dans le projet de service wcf (en créant un lien vers le contexte .tt), cette réponse est donc pour vous:

une partie des réponses affichées dans ce post qui comprend du code comme:

... = string.Format("res://{0}/YourEdmxFileName.csdl|res://{0}/YourEdmxFileName.ssdl|res://{0}/YourEdmxFileName.msl", 
        typeof(YourObjectContextType).Assembly.FullName); 

NE FONCTIONNERA PAS POUR VOUS !! la raison en est que YourObjectContextType.Assemblyréside désormais dans un assemblage différent (à l'intérieur de l'assembly du projet wcf),

Vous devez donc remplacer YourObjectContextType.Assembly.FullName par ->

ClassTypeThatResidesInEdmProject.Assembly.FullName 

s'amuser.

J'avais des problèmes avec ce même message d'erreur. Mon problème a été résolu en fermant et en rouvrant Visual Studio 2010.

J'ai eu le même problème car j'ai renommé une assemblée.

J'ai également dû le renommer dans les attributs AssemblyTitle et AssemblyProduct dans le projet Properties / AssemblyInfo.cs, et également supprimer et rajouter la référence au fichier edmx.

Ensuite, cela a très bien fonctionné.

Avec le même problème, j'ai recréé edmx à partir de la base de données. Résout mon problème.

L'exception est parce que le compilateur pointe vers des métadonnées inexistantes, il suffit donc de copier la chaîne de app.config connexion vers Web.configConnectionString

J'ai également eu le même problème et la même solution que pour Rick, sauf que j'importais un .edmx existant dans un nouveau projet, et bien que l'espace de noms de base n'ait pas d'importance, il a été importé dans un sous-répertoire différent, j'ai donc également dû mettre à jour la connexion chaîne à l'intérieur de Web.Config à trois endroits, pour inclure les différents noms de sous-répertoire:

J'ai eu le même problème avec une solution qui contenait des projets dans un dossier de solutions, lorsqu'ils ont été déplacés vers la racine de la solution (afin de surmonter un bogue suspect avec le Mvc3AppConverter en raison de l'emplacement des projets).

Bien que la solution ait été compilée après que toutes les références de projet * aient été ajoutées au besoin, l'erreur a été levée lorsque le site Web a été démarré.

L'EDMX est dans l'un des projets qui a été déplacé (le projet 'Data'), mais bien sûr, l'absence de référence au projet Data n'a pas provoqué d'erreur de compilation, juste une erreur d'exécution.

L'ajout de la référence manquante au projet principal a résolu ce problème, pas besoin de modifier la connexion.

J'espère que ça aidera quelqu'un d'autre.

Quant à moi, j'avais séparé la couche d'accès aux données et la couche d'interface utilisateur. J'ai donc une chaîne de connexion d'entité pour chaque couche.

Avant de modifier ces deux chaînes de connexion séparées pour qu'elles soient identiques, j'ai toujours trouvé l'erreur ci-dessous.

Unable to load the specified metadata resource

Je fais donc pour être les mêmes chaînes de connexion pour ces deux couches (DAL, UI), cela fonctionne parfaitement.

Ma solution est de faire en sorte que toutes les chaînes de connexion soient identiques, peu importe où elles ont déjà été présentées .

J'ai eu ce problème hier et regardais mon code dans le débogage et la sortie de SQL Profiler.

Ce que je ne pouvais pas comprendre, avant d'avoir lu et compris ce post, était la raison pour laquelle EntityFramework lançait cette erreur lors de l'appel de la base de données. Je regardais des centaines de lignes dans SQL Profiler pour essayer de comprendre ce qui n'allait pas avec le modèle de base de données. Je n'ai rien trouvé de semblable à l'appel auquel je m'attendais et, pour être honnête, je ne savais pas exactement ce que je cherchais.

Si vous êtes dans cette position, vérifiez la chaîne de connexion. Je suppose qu'avant qu'EntityFramework crée son SQL, il vérifiera le modèle, spécifié dans la partie métadonnées de la chaîne de connexion. Dans mon cas, c'était faux. EntityFramework ne se rendait même pas jusqu'à la base de données.

Assurez-vous que les noms sont corrects. Une fois que j'ai obtenu ce tri, je voyais alors des appels dans SQL Profiler où ApplicationName était 'EntityFramework' avec SQL appelant les tables attendues.

Un fichier app.config ou web.config médiocre peut le faire. J'avais copié la chaîne de connexion app.config dans mon web.config dans mon interface utilisateur et j'ai fini par entrer:

<connectionStrings>
    <connectionStrings>
          <add name="name" connectionString="normalDetails"/>
    </connectionStrings>
</connectionStrings>