Konfigurieren ProviderManifestToken für EF Code First

Habe ich eine asp.net MVC3-Projekt mit EF code-first. Für meine unit-Tests habe ich mit SQL Server CE 4.0 und SQL Server 2008 Express. Beide haben gearbeitet perfekt mit EF Erzeugung von meiner Datenbank, wie erwartet.

Jedoch, wenn ich meine Anwendung außerhalb der unit test und zeigen Sie es an meiner Verbindung strings bekomme ich die Fehlermeldung

ProviderIncompatibleException: Der Anbieter kam nicht wieder einen ProviderManifestToken string

Habe ich gelesen, das MS-Dokumentation auf dies und es scheint, dies ist eine SqlVersion - token, das das EF-Modell generiert. Das problem ist, dass ich mit den code-first-Ansatz, also habe ich keine .edmx Datei noch weiß ich wo ich meinen Metadaten zu, weil die db noch nicht generiert worden noch.

Ich weiß, dass meine Verbindung Saiten so weit wie db-name, Benutzername und pass sind korrekt, weil Sie Sie ändern, um falsche Werte wirft die zu erwartende Fehler. Nicht sicher, wo zu beginnen.

Dank.

Hier ist mein connection string:

<connectionStrings>
  <add
    name="SqlConnection"
    providerName="System.Data.SqlClient"
    connectionString="Data Source=WORKSTATION\SQLEXPRESS;Initial Catalog=CodeFirst;Integrated Security=False;
    Persist Security Info=False;User ID=CodeFirst_user;Password=password1;Connect Timeout=120;MultipleActiveResultSets=True;"/>
</connectionStrings>

InformationsquelleAutor der Frage trevorc | 2011-01-19

Wenn Sie mit EF 6 (nur freigegeben) Sie haben eine alternative.

Auflösung Von Abhängigkeiten

Können Sie mit der neuen Auflösung von Abhängigkeiten Funktion registriert eine Implementierung von IManifestTokenResolver (beschrieben in diese Vorschau auf die Dokumentation als IManifestTokenService).

Dieser Artikel gibt etwas mehr Informationen zur Verwendung DbConfiguration. Der einfachste Weg, es zu benutzen ist wie folgt:

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

Diesem Beispiel vermeidet eine Reise, um die Datenbank beim erstellen der Metadaten für SQL Server-verbindungen und automatisch gibt der SQL Server 2005-Kompatibilität.

using System.Data.Common;
using System.Data.Entity;
using System.Data.Entity.Infrastructure;
using System.Data.Entity.Infrastructure.DependencyResolution;
using System.Data.SqlClient;

///<summary>
///A configuration class for SQL Server that specifies SQL 2005 compatability.
///</summary>
internal sealed class EntityFrameworkDbConfiguration : DbConfiguration
{
    ///<summary>
    ///The provider manifest token to use for SQL Server.
    ///</summary>
    private const string SqlServerManifestToken = @"2005";

    ///<summary>
    ///Initializes a new instance of the <see cref="EntityFrameworkDbConfiguration"/> class.
    ///</summary>
    public EntityFrameworkDbConfiguration()
    {
        this.AddDependencyResolver(new SingletonDependencyResolver<IManifestTokenResolver>(new ManifestTokenService()));
    }

    ///<inheritdoc />
    private sealed class ManifestTokenService : IManifestTokenResolver
    {
        ///<summary>
        ///The default token resolver.
        ///</summary>
        private static readonly IManifestTokenResolver DefaultManifestTokenResolver = new DefaultManifestTokenResolver();

        ///<inheritdoc />
        public string ResolveManifestToken(DbConnection connection)
        {
            if (connection is SqlConnection)
            {
                return SqlServerManifestToken;
            }

            return DefaultManifestTokenResolver.ResolveManifestToken(connection);
        }
    }
}

InformationsquelleAutor der Antwort Olly

Nach Stunden des Suchens & hantieren, fand ich einen Weg, es zu tun. Stellt sich heraus, das DbModelBuilder Klasse einen DbProviderInfo in seiner Build Methode, so dass ich verwenden, anstatt sich auf EF zu nennen 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);
}

Natürlich braucht dies einige Reorganisation (z.B. die kompilierte cache-Modell, so dass Sie nicht brauchen, um neu zu bauen, ist es jedes mal, wenn ein Kontext geschaffen wird).

Für mich ist das komplett das problem gelöst. Genießen Sie!

InformationsquelleAutor der Antwort sinelaw

6

Ich hatte gerade genau dieses problem, aber ich verfolgte es bis zu meinem SQL Server-Dienst nicht ausgeführt wird. Ich hatte gerade meinen Rechner neu gestartet und in der Regel beginnt auf seine eigene, aber nicht für einige Grund.

InformationsquelleAutor der Antwort Bruce Hubbard

In meinem Fall, mein connection string name muss mit dem Kontext der Klasse name.

Connection String:

<connectionStrings>
  <add name="NunuContext" connectionString="Data Source=|DataDirectory|Nunu.sdf" providerName="System.Data.SqlServerCe.4.0" />
</connectionStrings>

Kontext-Klasse:

using System.Data.Entity;
namespace Nunu.Models
{
    public class NunuContext : DbContext
    {
        System.Data.Entity.DropCreateDatabaseIfModelChanges<Nunu.Models.NunuContext>());

        public DbSet<Nunu.Models.NunuFirst> NunuFirsts { get; set; }

        public DbSet<Nunu.Models.NunuLast> NunuLasts { get; set; }
    }
}

InformationsquelleAutor der Antwort asakura89

1

Fand ich, wenn ich ausdrücklich "User Id=abcUser; Password=somePwd;" in meinem connection-string ich in der Lage bin zu lösen, die gleichen Fehler. Früher wurde ich mit "Trusted_Connection=true;", was mir erlaubt zu Debuggen mein web-Projekt, sondern begann damit mir Fehler - {"Die Anbieter haben nicht wieder einen ProviderManifestToken string."} sobald ich Hinzugefügt die Windows azure-Projekt und versucht das Debuggen des Azure-Projekt nach dem hinzufügen von meinem web-Projekt als web-Rolle unter.

Hoffe, es hilft einigen ein erleben einer ähnlichen situation.

Dank,
Vivek Bahl

InformationsquelleAutor der Antwort Vivek Bahl
1

Wechsel zu Data Source=localhost war für mich auch mit MS SQL 2008 R2 Express

InformationsquelleAutor der Antwort John
1

Ändern der Datenquelle zu localhost im connectionString mein problem gelöst.

InformationsquelleAutor der Antwort Bala
1

Ich hatte dieses problem bei der Arbeit über die MVC3-tutorial auf ASP.NET.

Meine Lösung war die Verwendung (localhost) statt eine benannte Datenquelle. Dies funktioniert gut auf meiner box, die für die lokale dev Arbeit, aber würde nicht helfen, wenn die Datenbank auf einem separaten server.

InformationsquelleAutor der Antwort Cameron Combs

Es hat sich gezeigt, hilfreich für mich:

<connectionString="Data Source=WORKSTATION\SQLEXPRESS;Initial Catalog=CodeFirst;User ID=CodeFirst_user;Password=********"/> 
</connectionStrings>

InformationsquelleAutor der Antwort andrew

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.