válido unable the specified resource referencia recuperar reciente pueden puede pudo proyecto proveedor para mvc metadatos metadataexception mas los información hace framework especificados especificado entitytype encuentra encontrar data configuración cargar asignaciones archivos archivo almacenamiento c# .net entity-framework ado.net

c# - unable - MetadataException: no se puede cargar el recurso de metadatos especificado



no se pueden recuperar metadatos mvc (30)

Acabo de pasar unos felices 30 minutos con esto. Cambié el nombre del objeto de las entidades, cambié el nombre de la entrada en el archivo de configuración, pero hay más ... también tiene que cambiar la referencia a la csdl

muy fácil de perder: si está cambiando el nombre, asegúrese de obtener todo ...

De repente, sigo recibiendo una MetadataException al crear una instancia de mi clase ObjectContext generada. La cadena de conexión en App.Config parece correcta (no ha cambiado desde la última vez que funcionó) y he intentado regenerar un nuevo modelo (archivo edmx) desde la base de datos subyacente sin ningún cambio.

¿Alguien tiene alguna idea?

Más detalles: No he cambiado ninguna propiedad, no he cambiado el nombre de los ensamblajes de salida, no he intentado incrustar el EDMX en el ensamblaje. Simplemente esperé 10 horas desde que salí del trabajo hasta que regresé. Y entonces ya no estaba funcionando.

He intentado recrear el EDMX. He intentado recrear el proyecto. Incluso he intentado recrear la base de datos, desde cero. Sin suerte, en absoluto.


Con el mismo problema volví a crear edmx desde la base de datos. Resuelve mi problema.


Después de horas de buscar en Google y tratar de resolver ninguna de las soluciones sugeridas funcionó. He enumerado varias soluciones aquí. También he notado el que funcionó para mí. (Estaba usando EF versión 6.1.1 y SQL Server 2014, pero una base de datos más antigua)

  1. Reconstruyendo el proyecto y vuelva a intentarlo.
  2. Cerrar y abrir VS - No sé cómo funciona esto
  3. asegúrese de que si ha colocado el archivo .EDMX dentro de un Directorio, asegúrese de incluir los Directorios en su ConnectionString. por ejemplo el mío está dentro de la carpeta DAL. SO se ve así: connectionString="metadata=res://*/DAL.nameModel.csdl|res://*/DAL.nameModel.ssdl|res://*/DAL.nameModel.msl; (estos son para verlos puede alternar Mostrar todos los archivos en el Explorador de soluciones, en el directorio ~ / obj / ..)

... y muchos más que probé [como: revertir la versión EntityFramework a una versión posterior (no estoy seguro)]

lo que funcionó para mí:

De este artículo aquí , me ayudó a resolver mi problema. Acabo de cambiar mi ProviderManifestToken="2012" a ProviderManifestToken="2008" en el archivo EDMX. Para hacer esto:

Explorador de la solución

  1. Haga clic derecho sobre el archivo .edmx
  2. Abrir con..
  3. Editor XML
  4. Cambiar ProviderManifestToken = "XXXX" con 2008

Espero que eso ayude.


En mi caso, este problema estaba relacionado con el cambio de nombre del archivo edmx de mi modelo ... corrigiendo la cadena de conexión app.config para los archivos csdl / ssdl / msl solucionado mi problema.

Si está utilizando el diseñador EF 4.0 para generar su csdl / ssdl / msl, estos 3 "archivos" realmente se almacenarán dentro del archivo edmx principal del modelo. En este caso, el post de Waqas está prácticamente en la marca. Es importante entender que "Model_Name" en su ejemplo deberá cambiarse a cualquiera que sea el nombre actual del archivo .edmx de su modelo (sin el .edmx).

Además, si su archivo edmx no se encuentra en el nivel raíz de su proyecto, debe comenzar con Model_Name con la ruta relativa, por ejemplo

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

especificaría que el xml csdl / ssdl / msl se almacena en el archivo modelo ''WidgetModel.edmx'' que se almacena en una carpeta llamada ''MyModel''.


Estaba teniendo problemas con este mismo mensaje de error. Mi problema se resolvió cerrando y volviendo a abrir Visual Studio 2010.


Este pequeño cambio ayuda con este problema.

Tengo solución con 3 proyectos.

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

cambiar a

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


Esto me sucede cuando no limpio la solución antes de crear un nuevo diseñador .edmx. Entonces, no olvide limpiar la solución antes de crear un nuevo diseñador .edmx. Esto me ayuda a saltar muchos más problemas con este. Debajo de los detalles de navegación proporcionados en caso de que sea nuevo en Visual Studio.

Click-> Build-> Clean Solution

Luego haga clic en-> Construir-> Reconstruir solución

Espero que esto ayude. Gracias a todos


Esto me sucedió cuando accidentalmente cambié la acción de compilación del archivo edmx (aparece en Propiedades en el IDE) de ''EntityDeploy'' a ''None''. EntityDeploy es lo que completa los metadatos para usted: consulte http://msdn.microsoft.com/en-us/library/cc982037.aspx


Esto significa que la aplicación no puede cargar el EDMX. Hay varias cosas que pueden causar esto.

  • Es posible que haya cambiado la propiedad MetadataArtifactProcessing del modelo para Copiar en el Directorio de salida.
  • La cadena de conexión podría estar equivocada. Sé que dices que no lo has cambiado, pero si has cambiado otras cosas (por ejemplo, el nombre de una asamblea), aún podría estar equivocado.
  • Es posible que esté utilizando una tarea posterior a la compilación para incrustar el EDMX en el ensamblaje, que ya no funciona por algún motivo.

En resumen, no hay suficientes detalles en tu pregunta para dar una respuesta precisa, pero esperamos que estas ideas te guíen por el camino correcto.

Actualización: he escrito una entrada de blog con más pasos completos para solucionar problemas .


He escrito esta clase de ayuda para crear instancias de objetos ObjectContext cuando están definidos en un proyecto diferente al proyecto que lo usa. Analizo la cadena de conexión en el archivo de configuración y sustituyo ''*'' por el nombre completo del ensamblado.

No es perfecto porque usa la reflexión para construir el objeto, pero es la forma más genérica de hacerlo que pude encontrar.

Espero que ayude a alguien.

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; } }


La excepción se debe a que el compilador apunta a metadatos no existentes, así que solo copie app.config connectionstring a Web.config ConnectionString


Mi problema y solución, los síntomas eran los mismos "No se puede cargar el recurso de metadatos especificado" pero la causa raíz fue diferente. Tuve 2 proyectos en la solución uno fue el modelo Entity y el otro la solución. De hecho, eliminé y volví a crear el archivo EDMX en EntityModel.

La solución fue que tenía que volver al proyecto de aplicación web y agregar esta línea en el archivo de configuración. El nuevo modelo había cambiado algunos elementos que debían ser duplicados en el archivo Web.Config del "otro" proyecto. La antigua configuración ya no era buena.

<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" />


Mi teoría es que si tiene más de un archivo edmx con el mismo nombre (Model1 por ejemplo), dará esa excepción. Tengo el mismo problema cuando decidí nombrar todos mis archivos edmx (sentados en diferentes proyectos) como Model1 porque pensé que deberían ser independientes.


Otra causa de esta excepción es cuando incluye una tabla relacionada en una ObjectQuery, pero escribe el nombre de propiedad de navegación incorrecto.

Ejemplo:

var query = (from x in myDbObjectContext.Table1.Include("FKTableSpelledWrong") select x);


Para mi caso, se resuelve cambiando las propiedades del archivo edmx.

  1. Abrir el archivo edmx
  2. Haga clic derecho en cualquier lugar del diseñador EDMX
  3. elegir propiedades
  4. Actualizar la propiedad denominada "Procesamiento de artefactos de metadatos" a "Incrustar en el ensamblaje de salida"

Esto resolvió mi problema. El problema es que cuando el contenedor intenta encontrar los metadatos, no puede encontrarlos. así que simplemente hazlo en el mismo ensamblaje. Esta solución no funcionará si tiene sus archivos edmx en otro conjunto


Para todos los usuarios de SelftrackingEntities , si ha seguido el SelftrackingEntities Microsoft y ha separado la clase de contexto Objeto en el proyecto de servicio wcf (al vincularse al contexto .tt), esta respuesta es para usted:

parte de las respuestas mostradas en este post que incluye código como:

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

NO TRABAJARÁ PARA TI !! la razón es que YourObjectContextType.Assembly ahora reside en un Assembley diferente (dentro del ensamblado del proyecto wcf),

Así que deberías reemplazar YourObjectContextType.Assembly.FullName con ->

ClassTypeThatResidesInEdmProject.Assembly.FullName

que te diviertas.


Pasé un día entero en este error.

Si estás trabajando con n-tear architecture

o intentó separate Models generados por EDMX desde DataAccessLayer a DomainModelLayer

tal vez obtendrá este error

  1. El primer paso para solucionar el problema es asegurarse de que la cadena de conexión en webconfig (UILayer) y appconfig (DataAccessLayer) sean las mismas
  2. En segundo lugar, que es muy importante la connection string

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

    cuál es el problema

de donde diablos obtuve el Model o lo que sea .csdl en mi cadena de conexión donde están

Aquí nuestra solución mira la foto.

Espero que te ayude


Pude resolver esto en Visual Studio 2010, VB.net (ASP.NET) 4.0.

Durante el asistente del modelo de entidad, podrá ver la cadena de conexión de la entidad. Desde allí puedes copiar y pegar en tu cadena de conexión.

Lo único que me faltaba era el "Código de aplicación". en la cadena de conexiones.

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


Puede obtener esta excepción cuando Edmx está en un proyecto y lo está usando de otro.

La razón es Res://*/ es un uri que apunta a recursos en el ensamblaje ACTUAL. Si el Edm se define en un ensamblaje diferente del código que lo está utilizando, res: // * / no funcionará porque no se puede encontrar el recurso.

En lugar de especificar ''*'', debe proporcionar el nombre completo del ensamblaje (incluido el token de clave pública). P.ej:

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

Una mejor manera de construir cadenas de conexión es con 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 aún encuentra la excepción, abra el ensamblaje en el reflector y verifique los nombres de archivo de sus archivos .csdl, .ssdl y .msl. Cuando los recursos tienen nombres diferentes a los especificados en el valor de metadatos, no va a funcionar.


Si está utilizando el edmx de un proyecto diferente, entonces en la cadena de conexión, cambie ...

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

...a...

metadata=res://*/DataModel.csdl


Simplemente no había hecho referencia a mi biblioteca de clases que contenía el archivo EDMX.


También tuve el mismo problema y la misma solución que Rick, excepto que estaba importando un .edmx existente a un nuevo proyecto, y aunque el espacio de nombres base no importaba, se importaba a un subdirectorio diferente, así que también tuve que actualizar la conexión cadena dentro de Web.Config en tres lugares, para incluir los diferentes nombres de subdirectorios:


También tuve este problema y fue porque la cadena de conexión en mi web.config era ligeramente diferente a la del app.config del ensamblaje donde se encuentra mi EDMX. No tengo idea de por qué cambió, pero aquí están las dos versiones diferentes.

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" />

Se solucionó simplemente copiando la cadena app.config (note la pequeña diferencia al final, en lugar de " App=EntityFramework " quería " application name=EntityFramework ") en web.config y se resolvió el problema. :)


Tenía el mismo problema porque renombré una asamblea.

También tuve que cambiarle el nombre en los atributos AssemblyTitle y AssemblyProduct en Project Properties / AssemblyInfo.cs, y también eliminar y volver a agregar la referencia al archivo edmx.

Entonces funcionó bien.


Tuve el mismo problema con una solución que contenía proyectos en una carpeta de soluciones, cuando se movieron a la raíz de la solución (para superar un problema sospechoso con el Mvc3AppConverter debido a las ubicaciones del proyecto).

Aunque la solución compilada después de que todas las referencias del proyecto * se volvieron a agregar según fue necesario, se generó el error cuando se activó el sitio web.

El EDMX se encuentra en uno de los proyectos que se movió (el proyecto ''Datos''), pero, por supuesto, la falta de una referencia al proyecto de Datos no causó un error de compilación, solo un error en tiempo de ejecución.

Simplemente agregando la referencia faltante al proyecto principal se resolvió este problema, sin necesidad de editar la conexión en absoluto.

Espero que esto ayude a alguien más.


Tuve un error similar. Había recreado el proyecto (historia larga), y había sacado todo del proyecto anterior. No me había dado cuenta de que mi modelo había estado en un directorio llamado "Modelo" antes, y ahora estaba en un directorio llamado "Modelos". Una vez que cambié la conexión en mi Web.Config de esto:

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

a esto:

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

Todo funcionó ( Model cambiado a Models ). Tenga en cuenta que tuve que cambiar estos tres lugares en esta cadena.


Un archivo pobre de app.config o web.config puede hacer esto ... Copié la cadena de conexión de app.config a mi web.config en mi interfaz de usuario y terminé ingresando:

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


Y una forma rápida de verificar el nombre del modelo sin Reflector ... busque el directorio

... obj / {salida de configuración} / edmxResourcesToEmbed

y verifique que los archivos de recursos .csdl, .msl y .ssdl estén allí. Si están en un subdirectorio, el nombre del subdirectorio debe ir precedido del nombre del modelo.

Por ejemplo, mis tres archivos de recursos están en un subdirectorio de datos , por lo que mi cadena de conexión tenía que estar

metadata = res: // * / Data .MyModel.csdl | res: // * / Data .MyModel.ssdl | res: // * / Data .MyModel.msl;

(versus metadata = res: //*/MyModel.csdl | res: //*/MyModel.ssdl | res: //*/MyModel.msl;).


Yo tuve el mismo problema. Miré en mi dll cumplido con el reflector y he visto que el nombre del recurso no era correcto. Renombré y se ve bien ahora.


La solución definitiva (incluso después de recrear la base de datos en otras dos máquinas, así como el EDMX y otros artículos diversos) fue no usar la primera edición de Entity Framework. Espero poder evaluarlo de nuevo en .NET 4.0.

Después de encontrar el mismo problema nuevamente y buscar una respuesta por todas partes, finalmente encontré a alguien que había tenido el mismo problema. Parece que la cadena de conexión no fue generada correctamente por el asistente de Visual Studio, y al enlace a los recursos de metadatos le faltaba una ruta importante.

v1.0 BUG ?: No se puede cargar el recurso de metadatos especificado. Scripts! = Modelos

Actualización 2013-01-16 : Habiendo hecho la transición a usar casi exclusivamente las prácticas del Código EF First (incluso con las bases de datos existentes), este problema ya no es un problema. Para mí, esa era una solución viable para reducir el desorden del código y la configuración generados automáticamente y aumentar mi propio control sobre el producto.