Cómo configurar ProviderManifestToken para el código EF primero

Tengo un proyecto asp.net MVC3 que usa código EF primero. Para las pruebas de mi unidad, he estado usando SQL Server CE 4.0 y SQL Server 2008 Express. Ambos han funcionado perfectamente con EF generando mi base de datos como se esperaba.

Sin embargo, cuando ejecuto mi aplicación fuera de una prueba unitaria y la apunto a mis cadenas de conexión obtengo el error

ProviderIncompatibleException: el proveedor no devolvió una cadena ProviderManifestToken

He leído la documentación de MS sobre esto y parece que este es un token SqlVersion que genera el modelo de EF. El problema es que estoy usando el primer acercamiento de código así que no tengo ningún archivo .edmx ni sé a dónde .edmx mi información de metadatos porque el db no se ha generado aún.

Conozco mis cadenas de conexión en cuanto a que el nombre de db, el nombre de usuario y el pase son correctos, ya que al cambiarlos a valores incorrectos arroja el error esperado. No estoy seguro por dónde comenzar

Gracias.

Aquí está mi cadena de conexión:

    

Si usas EF 6 (recién lanzado) tienes una alternativa.

Resolución de dependencia

Puede usar la nueva función de resolución de dependencia para registrar una implementación de IManifestTokenResolver (descrita en esta documentación de vista previa como IManifestTokenService ).

Este artículo proporciona un poco más de información sobre cómo usar DbConfiguration . La forma más fácil de usarlo es así:

 DbConfigurationType(typeof(EntityFrameworkDbConfiguration))] public class MyContextContext : DbContext { } 

Este ejemplo evita cualquier viaje a la base de datos cuando se crean los metadatos para las conexiones de SQL Server, y automáticamente especifica la compatibilidad de SQL Server 2005.

 using System.Data.Common; using System.Data.Entity; using System.Data.Entity.Infrastructure; using System.Data.Entity.Infrastructure.DependencyResolution; using System.Data.SqlClient; ///  /// A configuration class for SQL Server that specifies SQL 2005 compatability. ///  internal sealed class EntityFrameworkDbConfiguration : DbConfiguration { ///  /// The provider manifest token to use for SQL Server. ///  private const string SqlServerManifestToken = @"2005"; ///  /// Initializes a new instance of the  class. ///  public EntityFrameworkDbConfiguration() { this.AddDependencyResolver(new SingletonDependencyResolver(new ManifestTokenService())); } ///  private sealed class ManifestTokenService : IManifestTokenResolver { ///  /// The default token resolver. ///  private static readonly IManifestTokenResolver DefaultManifestTokenResolver = new DefaultManifestTokenResolver(); ///  public string ResolveManifestToken(DbConnection connection) { if (connection is SqlConnection) { return SqlServerManifestToken; } return DefaultManifestTokenResolver.ResolveManifestToken(connection); } } } 

Después de horas de buscar y tocar el violín, encontré la manera de hacerlo. Resulta que la clase DbModelBuilder toma un DbProviderInfo en su método Build , así que lo uso en lugar de depender de EF para llamar a OnModelCreated :

 // 'Entities' is my DbContext subclass, the "container" in EF terms. public static Entities GetNewContext() { // Get a connection, for example: var connection = new SqlConnection(GetConnectionString()); // Create a DbModelBuilder var modelBuilder = new DbModelBuilder(); // Configure the model builder. // I changed my DbContext subclass - added a public version of OnModelCreated and called it ConfigureModelBuilder Entities.ConfigureModelBuilder(modelBuilder); // Here's where the magic happens. // Build the model and pass the ProviderManifestToken (I use 2005 to avoid a bug in precision of sql datetime columns when using concurrency control) var model = modelBuilder.Build(new System.Data.Entity.Infrastructure.DbProviderInfo("System.Data.SqlClient", "2005")); // Compile the model var compiledModel = model.Compile(); // Create the container (DbContext subclass). Ideally all the previous stuff should be cached. return new Entities(connection, compiledModel, true); } 

Obviamente, esto necesita alguna reorganización (por ejemplo, almacenar en caché el modelo comstackdo para que no tenga que volver a comstackrlo cada vez que se crea un contexto).

Para mí, esto resolvió completamente el problema. ¡Disfrutar!

Acabo de tener este problema exacto, pero lo rastreé hasta que mi servicio SQL Server no se estaba ejecutando. Recién había reiniciado mi computadora y generalmente comienza por sí mismo pero no por alguna razón.

En mi caso, el nombre de mi cadena de conexión debe coincidir con el nombre de la clase de contexto.

Cadena de conexión:

    

Clase de contexto:

 using System.Data.Entity; namespace Nunu.Models { public class NunuContext : DbContext { System.Data.Entity.DropCreateDatabaseIfModelChanges()); public DbSet NunuFirsts { get; set; } public DbSet NunuLasts { get; set; } } } 

Encontré, cuando proporcioné explícitamente “User Id = abcUser; Password = somePwd;” en mi cadena de conexión puedo resolver el mismo error. Anteriormente estaba usando “Trusted_Connection = true;”, lo que me permitió depurar mi proyecto web, pero comenzó a darme el error – {“El proveedor no devolvió una cadena ProviderManifestToken”}} tan pronto como agregué el proyecto azul de Windows y intenté depurar el proyecto de Azure después de agregar mi proyecto web como un rol web debajo de él.

Espero que ayude a alguien que experimenta una situación similar.

Gracias, Vivek Bahl

Cambiando a Fuente de Datos = localhost funcionó para mí también usando MS SQL 2008 R2 Express

Cambiar el origen de datos a localhost en connectionString resolvió mi problema.

Tuve este problema al trabajar con el tutorial de MVC3 en ASP.NET .

Mi solución terminó siendo el uso (localhost) lugar de un origen de datos con nombre. Esto funciona bien en mi caja, para el trabajo de desarrollo local, pero no ayudaría si la base de datos estuviera en un servidor separado.

Esto me ha resultado útil: