Exception EF 4.1 "Le fournisseur n'a pas renvoyé de chaîne ProviderManifestToken"
J'essaie de reproduire un exemple trouvé sur MSDN. J'utilise ASP.NET et EF 4.1 (CTP?). J'ai utilisé NuGet pour installer le package EntityFramework.
Je reçois cette erreur: The provider did not return a ProviderManifestToken string ... et la base de données n'est jamais créée.
Voici ma chaîne de connexion:
<add name="HospitalContext"
connectionString=
"data source=.\SQLExpress;initial catalog=NewTestDB;integrated security=True;"
providerName="System.Data.SqlClient"/>
Voici mon code:
var pat = new Patient { Name = "Shane123132524356436435234" };
db.Patients.Add(pat);
var labResult = new LabResult { Result = "bad", Patient = pat };
int recordAffected = db.SaveChanges();
Voici mon contexte:
public class HospitalContext : DbContext
{
static HospitalContext()
{
Database.SetInitializer(new HostpitalContextInitializer());
}
public DbSet<Patient> Patients { get; set; }
public DbSet<LabResult> LabResults { get; set; }
}
public class HostpitalContextInitializer :
DropCreateDatabaseIfModelChanges<HospitalContext>
{
protected override void Seed(HospitalContext context)
{
context.Patients.Add(new Patient { Name = "Fred Peters" });
context.Patients.Add(new Patient { Name = "John Smith" });
context.Patients.Add(new Patient { Name = "Karen Fredricks" });
}
}
Il s'agit d'un système SQL 2008 entièrement corrigé, avec VS 2010 SP1.
Je recevais cette erreur et j'ai essayé quelques-unes des suggestions précédentes. Ensuite, j'ai vérifié l'exception interne et remarqué que j'obtenais un échec de connexion SQL simple pour l'utilisateur. Juste quelque chose d'autre à vérifier.
Cela peut arriver parfois lorsque vous placez la chaîne de connexion dans le fichier app.config du projet incorrect dans Visual Studio.
Par exemple, j'ai eu ce problème dans EF 4.1 (version publiée) projet + projet de service de données WCF et j'ai constaté que je n'avais pas de chaîne de connexion spécifiée dans le projet Data Services, où il était utilisé.
J'avais la même erreur, et en fait c'était un échec de connexion pour le serveur spécifié. J'ai supprimé l'attribut "Sécurité intégrée" de la chaîne de connexion de configuration et cela a fonctionné.
J'ai eu un problème similaire avec l'application MvcMusicStore. J'ai changé une ligne dans le fichier Web.config de "Instance = true" à "Instance = false". Cela fonctionne parfois sans ce tweak mais je ne sais pas ce qui cause la différence. La lecture de cette http://msdn.Microsoft.com/en-us/library/ms254504.aspx n’a pas vraiment aidé.
J'ai eu le même problème, et j'ajoute le code ci-dessous juste après l'instance de mon contexte (onload par exemple)
context.Database.Connection.ConnectionString = @"Data Source=.\SQLExpress;Initial Catalog=Test;Integrated Security=True";
J'ai finalement craqué - après une légère chasse à l'oie sauvage pensant que c'était dû à des autorisations.
Révélation: USE SQL PROFILER
(Remarque: j'ai récemment rétrogradé de EF6 à EF5)
En utilisant SQL Profiler, j'ai rapidement trouvé le dernier SQL exécuté avant l'échec signalé:
SELECT TOP (1)
[Project1].[C1] AS [C1],
[Project1].[MigrationId] AS [MigrationId],
[Project1].[Model] AS [Model]
FROM ( SELECT
[Extent1].[MigrationId] AS [MigrationId],
[Extent1].[Model] AS [Model],
1 AS [C1]
FROM [dbo].[__MigrationHistory] AS [Extent1]
) AS [Project1]
ORDER BY [Project1].[MigrationId] DESC
Eh bien regardez cela - quelque chose à voir avec les migrations. Il recherche dans la table __MigrationHistory - ce que je n'avais même pas réalisé qu'il avait été créé (j'avais déjà supprimé les migrations de mon CSPROJ) et effacé le tout.
Donc, je tire les lignes pour cette table et vois qu'il est lié à une version du produit spécifique (v6).
En fait, je suis passé de EF6 (que je n'avais pas l'intention d'installer en premier lieu) à EF5 (ce qui est plus compatible avec un échafaudage) et ce, dès le début des problèmes.
À mon avis, la colonne Model (<Binary data>) n'est pas compatible avec les versions antérieures, d'où l'erreur The provider did not return a ProviderManifest instance, Car elle n'a pas pu la décoder.
Je n'avais rien à perdre et j'ai tout simplement effacé cette table et lancé Update-Database -Verbose, Puis je suis revenu à la tâche.
Si vous êtes dans un environnement avancé ou déjà en production, alors effacer ce tableau n'est peut-être pas la solution, mais cette façon m'a permis de me remettre au travail.
J'avais juste le même problème ...
La solution qui a fonctionné pour moi était la suivante:
exécuter l'outil de configuration réseau du client (tapez cliconfg dans Exécuter)
et assurez-vous que TCP/IP est activé.
Pour certaines raisons d’autorisation, EF ne peut pas créer de connexion à une base de données. J'avais affronté le même problème toute la journée. Enfin, j'avais essayé de suivre la solution suivante et cela fonctionnait: a/Ouvrir IIS (j'utilise IIS 7) b) Ouvrir les paramètres avancés d'appool quel site Web utilisait (Ex: DefaultAppPool) c/Regardez le groupe de modèles de processus, remplacez la valeur Identité par "Localsystem"
J'espère que cela fonctionne avec vous.
Cette erreur n'est présente que lorsque le fichier .edmx est ouvert et disparaît dès que le fichier est refermé.
Cette citation de CodePlex , cela a fonctionné avec moi (visual studio 2013/MVC 5)
Si vous utilisez EF Code First, vous devez également prendre en compte le fait que, parfois, il ne crée pas automatiquement la base de données de sauvegarde dans votre classe DbContext. La solution consiste à ajouter votre propre chaîne de connexion. Vous pouvez utiliser la chaîne de connexion éventuellement présente pour gérer la base de données d'utilisateurs/d'inscription qui sauvegarde le fournisseur d'appartenances simple, en tant que modèle. Enfin, vous devrez ajouter un constructeur par défaut pour la classe DbContext que vous avez créée:
public ChaletDb():base("ChaletConnection")
{
}
Ici, le nom de la chaîne de connexion telle que vous l'avez entrée dans votre fichier web.config est utilisé pour demander à DbContext de créer la base de données. Très occasionnellement, j'ai dû créer manuellement la base de données (dans SQL Server Management Studio), ce qui l'a incitée à fonctionner.
Lors de l’utilisation de Visual Studio 11 Beta avec EF4.1 et ASP.NET MVC, j’ai presque arraché mes cheveux jusqu’à ce que j’ai trouvé
Pour résoudre mon problème, je suis entré dans Application_Start et j'ai changé
Database.DefaultConnectionFactory = new SqlConnectionFactory ("Source de données = (localdb)\v11.0; Sécurité intégrée = True; MultipleActiveResultSets = True");
à
Database.DefaultConnectionFactory = new SqlConnectionFactory ( @ "Source de données = (localdb)\v11.0; Sécurité intégrée = True; MultipleActiveResultSets = True");
Je viens de fermer toutes les instances de Visual Studio et de rouvrir ma solution.
Je ne sais pas ce qui s'est réellement passé, mais la même solution a été ouverte à partir de deux espaces de travail locaux différents (l'un avec mes modifications locales, l'autre avec le code source du référentiel inchangé). Je travaille avec une base de données Postgres, Entity Framework 6, Visual Studio 2013 et ASP.NET MVC 5.
En effet, la connexion au serveur SQL a échoué.
Assurez-vous que le compte d'utilisateur sous lequel vous exécutez le processus a accès à SQL Server.
Si vous avez généré le DbContext à partir du thread parent (par exemple, en utilisant l'injection de dépendance), puis si vous empruntez l'identité d'un autre utilisateur, cette erreur se produit. La solution serait de générer le DbContext dans le nouveau thread ou le nouveau contexte Impersonation.
J'ai plusieurs projets dans une solution et ajouté EF à chaque projet à des moments différents. Sur certaines machines, il fonctionnait et sur d'autres, il échouait avec l'erreur susmentionnée. Il m'a fallu un certain temps pour constater que l'app.config de mon projet contenait ceci:
<defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
<parameters>
<parameter value="v11.0" />
</parameters>
</defaultConnectionFactory>
Ceci est correct si vous utilisez LocalDb (comme "sql express"), mais complètement faux si vous n'avez pas installé ce serveur spécifique et utilisez un SQL standard.
Solution: supprimez le code ci-dessus.
J'ai eu une erreur pour le cadre d'entité, mais aucune des réponses ci-dessus n'a été intégrée à la solution qui a finalement fonctionné.
Mes modèles EntityFramework Code First et DataContext se trouvaient dans un projet distinct de mon projet principal WebAPI. Mon projet Entity Framework, quelque part sur la ligne de codage, a été défini comme projet de démarrage. Par conséquent, lorsque j'exécutais une migration, je recevais le message "Le fournisseur n'a pas renvoyé de chaîne ProviderManifestToken"….
Il s'avère que puisque la chaîne ConnectionString de la base de données se trouve dans le fichier Web.config du projet principal WebAPI, lors de l’exécution d’une migration, la chaîne de connexion n’était pas extraite. En définissant le projet WebAPI comme projet startProject, j'ai pu me connecter avec succès.