MetadataException: impossible de charger la ressource de métadonnées spécifiée
Soudain, je continue à avoir une MetadataException lors de l'instanciation de ma classe ObjectContext générée. La chaîne de connexion dans App.Config semble correcte - elle 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 modification.
Quelqu'un a des idées?
Détails supplémentaires: je n’ai changé aucune propriété, je n’ai pas changé le nom des assemblys de sortie, je n’ai pas essayé d’incorporer l’EDMX à l’Assemblée. J'ai simplement attendu 10 heures entre mon départ et mon travail. 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 est incapable de charger l'EDMX. Cela peut être causé par plusieurs facteurs.
- Vous avez peut-être modifié la propriété MetadataArtifactProcessing du modèle sur Copier dans le répertoire de sortie.
- La chaîne de connexion 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 quand même être faux.
- Vous utilisez peut-être une tâche de post-compilation pour intégrer EDMX dans l’Assemblée, ce qui ne fonctionne plus pour une raison quelconque.
En bref, votre question ne contient pas suffisamment de détails pour donner une réponse précise, mais nous espérons que ces idées vous permettront de rester 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 la solution avec 3 projet.
connectionString="metadata=res://*/Model.Project.csdl|res://*/Model.Project.ssdl|res://*/Model.Project.msl;
changer à
connectionString="metadata=res://*/;
Vous pouvez obtenir cette exception lorsque Edmx est dans un projet et que vous l'utilisez d'un autre.
La raison en est que Res://*/ est un uri qui pointe vers des ressources de l’assemblage 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 indiquer le nom complet de l’assemblée (y compris le jeton de clé publique). Par exemple:
res://YourDataAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=abcdefabcedf/YourEdmxFileName.csdl|res://...
EntityConnectionStringBuilder est un meilleur moyen de construire des chaînes de connexion:
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’Assemblée dans le réflecteur et vérifiez les noms de fichiers de vos fichiers .csdl, .ssdl et .msl. Lorsque les ressources ont des noms différents de ceux spécifiés dans la valeur de métadonnées, cela ne fonctionnera pas.
J'ai eu une erreur similaire. J'avais recréé le projet (histoire longue) et tout repris de l'ancien projet. Je n'avais pas réalisé que mon modèle se trouvait auparavant dans un répertoire appelé «Modèle», mais maintenant dans un répertoire appelé «Modèles». Une fois que j'ai changé la connexion dans mon Web.Config à partir 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é Model en Models). Notez que je devais 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/{config output}/edmxResourcesToEmbed
et vérifiez que les fichiers de ressources .csdl, .msl et .ssdl sont présents. 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: // * / Données . MonModèle.csdl | res: // * / Données . MonModèle.ssdl | res: // * / Données . MonModèle.msl;
(versus metadata = res: //*/MyModel.csdl | res: //*/MyModel.ssdl | res: //*/MyModel.msl;).
J'ai également eu ce problème et c'est parce que la chaîne de connexion de mon web.config était légèrement différente de celle de l'app.config de l'Assemblée où se trouve mon EDMX. Aucune idée 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="data source=SANDIEGO\sql2008;initial catalog=SCMS;integrated security=True;multipleactiveresultsets=True;application name=EntityFramework"" 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="data source=SANDIEGO\sql2008;initial catalog=SCMS;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework"" providerName="System.Data.EntityClient" />
Ce qui a été résolu, c’était simplement de copier la chaîne app.config (remarquez la petite différence à la fin - au lieu de "App=EntityFramework", il voulait "application name=EntityFramework") dans le fichier web.config et le problème a été résolu. :)
Cela m'est arrivé lorsque j'ai accidentellement commuté l'action de compilation du fichier edmx (apparaissant sous Propriétés dans l'EDI) de 'EntityDeploy' à 'Aucune'. EntityDeploy remplit les métadonnées pour vous: voir http://msdn.Microsoft.com/en-us/library/cc982037.aspx
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 changez le nom, assurez-vous que vous obtenez tout ....
J'ai passé toute une journée sur cette erreur
si vous travaillez avec n-tear architecture
ou vous avez essayé de separate Models généré par EDMX de DataAccessLayer à DomainModelLayer
peut-être aurez-vous cette erreur
- La première étape du dépannage consiste à vérifier que les chaînes de connexion dans
webconfig (UILayer)etappconfig (DataAccessLayer)sont identiques. Deuxième ce qui est très important le
connection stringconnectionString="metadata=res://*/Model.csdl|res://*/Model.ssdl|res://*/Model.msl;provid.....quel est le problème
d'où je suis Modelou quel que soit le .csdl dans ma chaîne de connexion où sont-ils
ici je notre solution regarde la photo
j'espère vous aider
J'ai eu le même problème. J'ai examiné 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 a l'air bien maintenant.
Pour mon cas, le problème est résolu en modifiant les propriétés du fichier edmx.
- Ouvrez le fichier edmx
- Faites un clic droit sur n'importe quel endroit du concepteur EDMX
- choisir des propriétés
- mise à jour de la propriété appelée "Traitement des artefacts de métadonnées" sur "Intégrer dans l'assemblage de sortie"
cela a résolu le problème pour moi ... Le problème est que, lorsque le conteneur tente de trouver les métadonnées, il ne peut pas les trouver. faites-le simplement dans le même assemblage . cette solution ne fonctionnera pas si vous avez vos fichiers edmx dans un autre assemblage
J'ai pu résoudre ce problème dans Visual Studio 2010, VB.net (ASP.NET) 4.0.
Au cours de 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 connexion.
entityBuilder.Metadata = "res://*/App_Code.Model.csdl|res://*/App_Code.Model.ssdl|res://*/App_Code.Model.msl"
La solution ultime (même après avoir recréé la base de données sur deux autres machines, ainsi que sur EDMX et d’autres éléments divers) était de ne pas utiliser la première édition d’Entity Framework. Dans l’attente de l’évaluer à nouveau dans .NET 4.0.
Après avoir rencontré le même problème encore et cherché partout une réponse, j'ai finalement 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 d'un chemin important.
v1.0 BOGUE?: Impossible de charger la ressource de métadonnées spécifiée. Scripts! = Models
Mise à jour 2013-01-16: Après avoir utilisé presque exclusivement les pratiques EF Code First (même avec des 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 dû au code et à la configuration générés automatiquement et pour augmenter mon 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 en solution, l'un était EntityModel et l'autre la solution. J'ai effectivement supprimé et recréé le fichier EDMX dans EntityModel.
La solution était que je devais revenir au projet d'application Web et ajouter cette ligne dans le fichier de configuration. Le nouveau modèle avait modifié quelques éléments à dupliquer dans le fichier Web.Config du "autre" projet. 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="
data source=Q\DEV15;initial catalog=whatever;
user id=myuserid;password=mypassword;
multipleactiveresultsets=True;
application name=EntityFramework""
providerName="System.Data.EntityClient" />
Après des heures passées à googler et à 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 base de données plus ancienne)
- Reconstruisez le projet et réessayez.
- Fermez et ouvrez VS - Je ne sais pas comment cela fonctionne
- assurez-vous que si vous avez placé le fichier .EDMX dans un répertoire, veillez à inclure les répertoires dans votre ConnectionString. Par exemple, le mien se trouve dans le dossier DAL. SO il 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, dans le répertoire ~/obj/..)
... et beaucoup d'autres que j'avais essayés [comme: rétablir la version d'EntityFramework dans une version ultérieure (pas sûr de ça)]
ce qui a fonctionné pour moi:
de cet article ici , cela m'a aidé à résoudre mon problème. Je viens de changer mon ProviderManifestToken="2012" en ProviderManifestToken="2008" dans le fichier EDMX. Pour faire ça:
Explorateur de solution
- Faites un clic droit sur le fichier .edmx
- Ouvrir avec..
- Éditeur XML
- Changer ProviderManifestToken = "XXXX" avec 2008
J'espère que ça aide.
Pour tous les utilisateurs SelftrackingEntities, Si vous avez suivi le guide Microsoft Walk-through et séparé la classe de contexte Object en Le projet de service wcf (en vous connectant au contexte .tt), cette réponse vous convient:
une partie des réponses affichées dans cet article qui inclut un 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.Assembly réside maintenant dans un Assembley différent (à l'intérieur de l'assembly du projet wcf),
Donc, vous devriez remplacer YourObjectContextType.Assembly.FullName par ->
ClassTypeThatResidesInEdmProject.Assembly.FullName
s'amuser.
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 réalité stockés dans le fichier edmx principal du modèle. Dans ce cas, le message de Waqas est plutôt pertinent. Il est important de comprendre que "Model_Name" dans son exemple devra être remplacé par le nom actuel du fichier .edmx de votre modèle (sans le .edmx).
De plus, si votre fichier edmx ne se trouve pas au niveau racine de votre projet, vous devez préfacer Model_Name avec le chemin relatif, par exemple.
res://*/MyModel.WidgetModel.csdl|res://*/MyModel.WidgetModel.ssdl|res://*/MyModel.WidgetModel.msl
spécifierait que le fichier csdl/ssdl/msl xml est stocké dans le fichier de modèle 'WidgetModel.edmx' qui est stocké dans un dossier nommé 'MyModel'.
Cela m’arrive lorsque je ne nettoie pas la solution avant de construire le nouveau concepteur .edmx. Il suffit donc de ne pas oublier de nettoyer la solution avant de créer le nouveau concepteur .edmx. Cela m'aide à éviter beaucoup plus de problèmes avec celui-ci. Ci-dessous les détails de navigation fournis si vous êtes nouveau dans Visual Studio.
Cliquez-> Construire-> Nettoyer la solution
Puis cliquez sur-> Construire-> Reconstruire la solution
J'espère que cela t'aides. Merci tout le monde
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 parce qu'il utilise la réflexion pour construire l'objet, mais c'est la manière la plus générique de le faire que j'ai pu trouver.
J'espère que ça 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;
}
}
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.
Ayant le même problème, j'ai recréé edmx à partir de la base de données . Résout mon problème.
L'exception est due au fait que le compilateur pointe sur des métadonnées non existantes. Copiez donc app.config connectionstring dans Web.config ConnectionString.
J'ai eu le même problème parce que j'ai renommé une assemblée.
Je devais également le renommer dans les attributs AssemblyTitle et AssemblyProduct du projet Properties/AssemblyInfo.cs, ainsi que pour supprimer et rajouter la référence au fichier edmx.
Ensuite, cela a bien fonctionné.
Cela peut se faire avec un fichier app.config ou web.config médiocre. 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>
J'ai eu le même problème avec une solution qui contenait des projets dans un dossier de solutions, quand ils ont été déplacés vers la racine de la solution (afin de surmonter un bogue suspect avec le convertisseur Mvc3App en raison de l'emplacement des projets).
Bien que la solution compilée après que * toutes les références de projet aient été ré-ajoutées au besoin, l'erreur a été générée lorsque le site Web a été lancé.
L'EDMX est dans l'un des projets déplacés (le projet 'Data'), mais bien sûr, l'absence de référence au projet Data n'a pas causé d'erreur de compilation, mais une erreur d'exécution.
Le simple fait d’ajouter la référence manquante au projet principal a résolu ce problème, plus besoin de modifier la connexion.
J'espère que ça aidera quelqu'un d'autre.
Si vous utilisez edmx à partir d'un projet différent, dans la chaîne de connexion, modifiez ...
metadata=res://*/Data.DataModel.csdl
...à...
metadata=res://*/DataModel.csdl
Je n'avais tout simplement pas référencé ma bibliothèque de classes contenant le fichier EDMX.
J’avais également le même problème et la même solution que Rick, sauf que j’importais un .edmx existant dans un nouveau projet et que, même si l’espace de nommage de base était sans importance, il était importé dans un sous-répertoire différent; je devais donc mettre à jour la connexion. Chaîne dans Web.Config à trois endroits, pour inclure les noms de sous-répertoires différents:
Une autre cause de cette exception est lorsque vous incluez une table liée dans un ObjectQuery, mais que vous entrez un nom de propriété de navigation incorrect.
Exemple:
var query = (from x in myDbObjectContext.Table1.Include("FKTableSpelledWrong") select x);
Il suffit de taper chemin comme suit au lieu de {Path.To.The.}: Res: // /{Path.To.The.}YourEdmxFileName.csdl|res:// / {Path.To.The.} YourEdmxFileName.ssdl | res: // */{Path.To.The.} YourEdmxFileName.msl
Utiliser les infos de this blogpost :
Comme d'autres l'ont dit, res: \\ est un pointeur sur vos ressources. Pour vérifier et vous assurer que vos noms de ressources sont corrects, vous pouvez utiliser un décompilateur tel que DotPeek by JetBrains pour ouvrir votre fichier .dll et consulter vos fichiers de ressources.
Vous pouvez également ouvrir la fenêtre de surveillance pendant le débogage et le coller dans ce code pour obtenir un tableau des noms de ressources dans l’Assemblée en cours d’exécution.
System.Reflection.Assembly.GetExecutingAssembly().GetManifestResourceNames()
Cela étant dit, le format de vos chemins de métadonnées devrait ressembler à ceci:
{mon-nom-assembleur}/{éventuellement-un-espace-noms}. {nom-classe}. {csdl ou ssdl ou msl}
Dans mon cas, aucune des réponses énumérées n'a fonctionné et c'est pourquoi je poste ceci.
Dans mon cas, utiliser Visual Studio et l’exécuter avec IIS express a bien fonctionné. Mais lorsque je déployais des scripts Nant en tant que site Web autonome, cela donnait des erreurs. J'ai essayé toutes les suggestions ci-dessus, puis j'ai réalisé que la DLL générée par le script nant était beaucoup plus petite que celle générée par VS. Et puis j'ai réalisé que Nant était incapable de trouver les fichiers .csdl, .msl et .ssdl. Il existe donc deux manières de résoudre ce problème. L’une consiste à copier les fichiers nécessaires une fois que Visual Studio les a générés et à inclure ces fichiers dans le déploiement de la construction. Et ensuite, dans Web.config, spécifiez le chemin comme suit:
"metadata=~/bin/MyDbContext.csdl|~/bin/MyDbContext.ssdl|~/bin/MyDbContext.msl;provider=System.Data.SqlClient;...."
Cela suppose que vous avez copié manuellement les fichiers dans le répertoire bin du site Web que vous exécutez. Si c'est dans un répertoire différent, modifiez le chemin en conséquence . La deuxième méthode consiste à exécuter EdmGen.exe dans le script Nant, à générer les fichiers, puis à les inclure en tant que ressources, comme dans l'exemple ci-dessous: https : //github.com/qwer/budget/blob/master/nant.build
Quant à moi, j'avais séparé la couche d'accès aux données et la couche interface utilisateur .
Avant de modifier ces deux chaînes de connexion séparées pour qu'elles soient identiques, je trouvais toujours cela en dessous de l'erreur.
Unable to load the specified metadata resource
Je crée donc les mêmes chaînes de connexion pour ces deux couches (DAL, UI), cela fonctionne parfaitement.
Ma solution consiste à rendre toutes les chaînes de connexion identiques, peu importe où elles se sont déjà présentées..
Dans mon cas, c'était parce que je construisais la chaîne de connexion à l'aide d'un EntityConnectionStringBuilder. Assurez-vous que votre propriété Metadata utilise le nom du modèle (y compris l'espace de nom).
Parfois, je vois cette erreur dans mon projet. Je résous cela par
1 - Faites un clic droit sur le fichier EDMX
2 - Sélectionnez l'option Run Custom Tool
Lorsque le problème de métadonnées a été résolu, j'ai rencontré un problème de suivi, sous la forme d'une exception d'invocation, incapable de trouver une chaîne de connexion pour XXXEntities dans app.config (mon objectif n'étant pas dépendant de app.config). Par pure chance, j'ai découvert que le référencement de System.Data dans mon projet de test d'unité éliminait ce dernier obstacle. Donc, pour résumer:
- Utilisez nuget pour installer Entity Framework dans votre projet de test unitaire.
- Assurez-vous que System.Data.Entity et System.Data sont référencés.
- Triez votre chaîne de connexion comme décrit très bien ici.
- Transmettez la chaîne de connexion à votre constructeur de classe partielle.
Mes métadonnées se trouvent maintenant dans une bibliothèque de classes pouvant être mises à jour à partir d'une base de données de référence et je peux diriger mon application et les tests unitaires vers n'importe quelle base de données sur n'importe quel serveur au moment de l'exécution.
Addendum: Lorsque j'ai déplacé mon edmx dans un dossier, j'ai à nouveau eu l'erreur. Après quelques recherches, j'ai découvert que vous souhaitiez que votre chaîne de métadonnées ressemble à ceci: métadonnées = res: //EPM.DAL/Models.EPM.csdl, où EPM.DAL est le nom de l'Assemblée et EPM.edmx se trouve le dossier des modèles.
J'ai eu cette erreur lorsque mon fichier edmx a été supprimé par une commande pré-build, tout simplement. Cela m'a pris du temps avant de réaliser que c'était aussi simple que cela.
Je suis également confronté à ce problème, je viens de nettoyer et de reconstruire la solution qui fonctionne bien.
Parfois, l'assemblage contenant le modèle n'est pas chargé:
[TestMethod]
public void TestOpenWithConfigurationAfterExplicit()
{
String dummy = typeof(MallApp).Assembly.FullName;
//force the Assembly loaded.
using (DbContext ctx = new DbContext("name=MyContainer))
{
}
}
Le type MallApp habite dans la même assemblée que le modèle d'entité. Sans le chargement explicite, un System.Data.MetadataException sera lancé.
Ma théorie est que si vous avez plus d'un fichier edmx avec le même nom (Model1 par exemple), vous obtiendrez cette exception… .. J'ai le même problème lorsque j'ai décidé de nommer tous mes fichiers edmx (assis dans différents projets ) comme Model1 parce que je pensais qu'ils devraient être indépendants.
J'ai eu ce problème hier et je regardais mon code dans le débogage et la sortie de SQL Profiler.
Ce que je ne comprenais pas, avant de lire et de comprendre ce message, était la raison pour laquelle EntityFramework renvoyait cette erreur en appelant la base de données. J'examinais 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 ne trouvais rien de plus que l'appel auquel je m'attendais et, pour être honnête, je n'étais pas certain de ce que je cherchais.
Si vous êtes dans cette position, vérifiez la chaîne de connexion. J'imagine qu'avant de créer son code SQL, EntityFramework vérifie 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 aussi loin que la base de données.
Assurez-vous que les noms sont corrects. Une fois que j'ai résolu ce problème, je voyais alors des appels dans SQL Profiler où ApplicationName était 'EntityFramework' avec SQL appelant les tables attendues.
J'ai eu ce problème après avoir déplacé une solution volumineuse d'un dossier dans Source Control Explorer à un autre. Nous ne vérifions pas le dossier de package dans Team Foundation et je pense donc que VS a téléchargé les packages automatiquement. Cela a mis à niveau mon formulaire EF v6.1.2 à v6.1.3.
Le problème a disparu lorsque j'ai rétrogradé à la version v6.1.2 d'origine.
Problème similaire pour moi. Le nom de ma classe était différent de mon nom de fichier. La chaîne de connexion générée contenait le nom de la classe et non le nom du fichier. La solution pour moi consistait simplement à renommer mon fichier pour correspondre au nom de la classe.