web-dev-qa-db-fra.com

Mot clé non pris en charge: métadonnées

Cette ligne:

WebSecurity.InitializeDatabaseConnection(connectionStringName: "DefaultConnection", userTableName: "UserProfile", userIdColumn: "UserID", userNameColumn: "UserName", autoCreateTables: true);

Jette:

'System.ArgumentException' s'est produit dans System.Data.dll mais n'a pas été traité dans le code utilisateur

Informations complémentaires: mot-clé non pris en charge: "métadonnées".

Ma chaîne de connexion est:

add name="DefaultConnection" connectionString="metadata=res://*/TalyllynModel.csdl|res://*/TalyllynModel.ssdl|res://*/TalyllynModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=***********;initial catalog=********;persist security info=True;user id=*********;password=********;MultipleActiveResultSets=True;App=EntityFramework&quot;" providerName="System.Data.SqlClient" /></connectionStrings>

Je ne sais pas où ça va mal.

c#sql-serverasp.net-mvcentity-framework
43
ASPCoder1450

La chaîne que vous avez transmise n'est pas une chaîne de connexion à la base de données valide, c'est une chaîne de connexion EF qui contient une chaîne de connexion SQL Server dans son paramètre provider connection string. WebSecurity.InitializeDatabaseConnection attend une chaîne de connexion à la base de données valide

Pour éviter d'analyser vous-même la chaîne de connexion, vous pouvez utiliser la classe EntityConnectionStringBuilder pour analyser la chaîne et extraire la chaîne de connexion à la base de données à partir de sa propriété ProviderConnectionString .

57
Panagiotis Kanavos

Lorsque cela m'est arrivé, c'était parce que la chaîne de connexion avait:

providerName="System.Data.SqlClient"

mais cela devrait être:

providerName="System.Data.EntityClient"

car, comme l’a dit l’autre réponse, il s’agit d’une chaîne de connexion EF.

47
Will Newton

Juste pour ajouter une autre possibilité (que j'ai rencontrée) - ce qui pourrait être le cas si vous développez/gérez une application Web Azure, à l'aide d'une chaîne de connexion enregistrée dans les paramètres d'application d'Azure.

A côté de chaque chaîne de connexion dans les paramètres de l'application se trouve un menu déroulant pour le type de chaîne de connexion. Il est très facile d'oublier de le définir sur 'Personnalisé' pour les valeurs de Entity Framework et de le conserver à la valeur par défaut (base de données SQL), ce qui provoque également l'erreur ci-dessus. .

20
oflahero

Je vais donner une autre réponse, juste au cas où quelqu'un d'autre se retrouverait dans le même scénario étrange que moi.

Comme d’autres l’ont déjà dit, les chaînes de connexion ADO et les chaînes de connexion EF sont différentes.

Une chaîne de connexion ADO contient un certain nombre de champs séparés par des points-virgules, pouvant aller d'un type de connexion à un autre, mais vous voyez généralement "source de données = xxx", "catalogue initial = yyy", etc.not see "metadata = zzz".

Une chaîne de connexion EF a la même structure, mais elle a une "métadonnée = zzz" et une "chaîne de connexion fournisseur = www", où "www" est une chaîne de connexion échappée ADO.

Donc, un format normal pour une chaîne de connexion ADO est:

data source=myserver;
initial catalog=mydatabase;
Persist Security Info=True;
User ID=myusername;
Password=mypassword;
MultipleActiveResultSets=True

Alors qu'un format normal pour une chaîne de connexion EF est:

metadata=res://*/MyDbContext.csdl|
    res://*/MyDbContext.ssdl|
    res://*/MyDbContext.msl;
provider=System.Data.SqlClient;
provider connection string=&quot;
    data source=myserver;
    initial catalog=mydatabase;
    Persist Security Info=True;
    User ID=myusername;
    Password=mypassword;
    MultipleActiveResultSets=True;
    application name=EntityFramework
    &quot;

La plupart des personnes confrontées à ce problème semblent avoir coupé une chaîne de connexion EF et l'avoir collée dans un emplacement nécessitant une chaîne de connexion ADO. En substance, j'ai fait la même chose, mais le processus n'était pas aussi clair que cela.

Dans mon cas, j'avais une application Web qui utilisait EF, son fichier web.config contenait donc correctement les chaînes de connexion EF.

J'ai publié un package de déploiement et le processus vous invite à utiliser les chaînes de connexion lors du déploiement. Ceux-ci sont stockés dans le fichier SetParameters.xml généré par le package de déploiement.

J'ai coupé et collé les chaînes de connexion EF dans les champs de saisie du dialogue de publication.

J'ai déployé l'application Web, essayé d'y accéder et j'ai l'erreur "Mot clé non pris en charge: métadonnées".

Ce que je n'avais pas compris, c'est que l'outil de publication de MS attendait une chaîne de connexion ADO, et que, dans ce cas, il construirait une chaîne de connexion EF.

Le résultat a été que SetParameters.xml et mon web.config déployé avaient des chaînes de connexion qui ressemblaient à ceci:

metadata=res://*/MyDbContext.csdl|
    res://*/MyDbContext.ssdl|
    res://*/MyDbContext.msl;
provider=System.Data.SqlClient;
provider connection string=&quot;
    metadata=res://*/XxDbContext.csdl|
        res://*/XxDbContext.ssdl|
        res://*/XxDbContext.msl;
    provider=System.Data.SqlClient;
    provider connection string=&amp;quot;
        data source=myserver;
        initial catalog=mydatabase;
        Persist Security Info=True;
        User ID=myusername;
        Password=mypassword;
        MultipleActiveResultSets=True;
        application name=EntityFramework
        &amp;quot;
    &quot;"

En d'autres termes, la chaîne de connexion du fournisseur incorporé était une chaîne de connexion EF et non une chaîne de connexion ADO. Par conséquent, lorsque EF essayait de l'utiliser pour se connecter à la base de données, il générait cette erreur.

En d'autres termes, lorsque vous collez les chaînes de connexion dans les dialogues de publication, vous devez coller une chaîne de connexion ADO, et non une chaîne de connexion EF, même si ce que vous avez dans le fichier web.config à partir duquel vous copiez est une chaîne de connexion EF.

Vous pouvez extraire une chaîne de connexion ADO du champ de chaîne de connexion fournisseur d'une chaîne de connexion EF, et c'est ce dont vous aurez besoin si vous utilisez la même connexion dans le déploiement que dans le développement local.

3
Jeff Dege

Voici le code que j'utilise pour extraire le nom de la base de données et le nom du serveur d'une chaîne de connexion.

Notez comment il vérifie s’il s’agit d’une chaîne de connexion Entity Framework et, si tel est le cas, il en extrait la partie "chaîne de connexion du fournisseur", qui peut ensuite être transmise à SqlConnectionStringBuilder:

Si je n'ai pas fais cela, j'aurais cette mauvaise erreur "Keyword Not Supported: Metadata".

if (connectionString.ToLower().StartsWith("metadata="))
{
    System.Data.Entity.Core.EntityClient.EntityConnectionStringBuilder efBuilder = new System.Data.Entity.Core.EntityClient.EntityConnectionStringBuilder(connectionString);
    connectionString = efBuilder.ProviderConnectionString;
}

SqlConnectionStringBuilder builder = new SqlConnectionStringBuilder(connectionString);
DatabaseServer = builder.DataSource;             //  eg "MikesServer"
DatabaseName = builder.InitialCatalog;           //  eg "Northwind"
2
Mike Gledhill

À utiliser dans les paramètres de l’application Azure => Chaînes de connexion: 

  1. Si la chaîne de connexion est générée par EF-designer, veillez à remplacer &qout; par " dans la chaîne. 

  2. Vérifiez ce fournisseur = System.Data.SqlClient

  3. Choisissez Type personnalisé dans la liste déroulante

  4. Si la connexion concerne un modèle (Entity Framework), assurez-vous que le chemin correct vers votre modèle est utilisé Ex: un modèle "MyWebRoot/Models/MyModel.edmx" est configuré comme suit: metadata = res: // / Models .MyModel.csdl | res: // /Models.MyModel.ssdl|res://*/Models.MyModel.msl;

1
Petter Ivarsson

Pour Azure Web App, le type de chaîne de connexion n'a pas "System.Data.EntityClient", Custom fonctionne bien.

 enter image description here

1
Song

Salut,

À mon avis, la chaîne de connexion pour ADO.NET (dans cette CaseSqlConnection) ne peut pas utiliser les métadonnées Vous utilisez le spécifique pour Entity Framework. Le ADO.NET devrait être quelque chose comme:

"data source=KAPS-PC\KAPSSERVER;initial catalog=vibrant;integrated security=True"

Donc, pour résumer, vous avez besoin de deux chaînes de connexion distinctes, une pour EF et un pour ADO.NET.

Source: http://forums.iis.net/post/2097280.aspx

0
Muhammad Rehan Qadri

Vérifiez à cet endroit 

<add name="ConnectionString" connectionString="Data Source=SMITH;Initial Catalog=db_ISMT;Persist Security Info=True;User ID=sa;Password=@darksoul45;MultipleActiveResultSets=True;Application Name=EntityFramework"
  providerName="System.Data.SqlClient" />

Comme vous pouvez le constater, il existe deux chaînes de connexion, l'une pour ADO et l'autre pour le système de connexion ou ce que vous voulez. Dans mon cas, ConnectionString est pour le système de connexion, donc je l'ai utilisé dans: - 

    SqlConnection con = new SqlConnection(ConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString);
    SqlCommand cmd = null;
    SqlDataReader dr = null;
    protected void Page_Load(object sender, EventArgs e)

0
Rabi Shrestha