Mot-Clé Non Pris En Charge: Les Métadonnées

Cette ligne:

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

Est à jeter:

'Système.ArgumentException' s'est produite dans System.Data.dll mais n'a pas été traitée dans le code utilisateur

Informations supplémentaires: le 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>

Vous ne savez pas où il est im ne va pas.

avez-vous essayé de connecter manuellement? avez-vous vérifié les informations d'identification de cette façon?

InformationsquelleAutor ASPCoder1450 | 2013-11-25

asp.net-mvc c#entity-framework sql-server

61

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

Pour éviter l'analyse de la chaîne de connexion, vous pouvez utiliser le EntityConnectionStringBuilder classe pour analyser la chaîne et de récupérer la base de données de la chaîne de connexion à partir de son ProviderConnectionString propriété
- Je vois. Donc après j'ai suivi un exemple de dire à partir d'ici: msdn.microsoft.com/en-us/library/.... Dois-je garder la chaîne de connexion dans le web.fichier de configuration ou puis-je me débarrasser de lui? Merci!
- Peut-être par le EF de la chaîne de connexion fonctionne bien sur ma box mais pas sur Azure
- "Pas sur Azure" ne veut pas dire grand-chose. Les types de chaînes de connexion n'ont rien à voir avec l'environnement. Si ils échouent sur les différents environnements lorsque le code est le même, c'est parce qu'ils pointent vers les serveurs qui n'existent pas sur un environnement ou d'utiliser des informations d'identification non valides pour l'environnement. Poser une question à votre problème
- Voir ma réponse ci-dessous pour une solution à la " Pas sur Azure question.
InformationsquelleAutor Panagiotis Kanavos
52

Lorsque cela s'est produit pour moi, c'était parce que la chaîne de connexion a:
```
providerName="System.Data.SqlClient"
```
mais il devrait être:
```
providerName="System.Data.EntityClient"
```
parce que comme l'a dit l'autre réponse, c'est un EF chaîne de connexion.
- Ceci peut être très difficile à suivre, simple quand vous savez
- Wow... ce qui m'a sauvé de devenir fou après des heures à la recherche de solution!! Pourquoi sur la terre, n'est-ce pas automatiquement mis à jour lorsque vous avez installé EF si?? +1
- Conscient que, dans Azure j'ai trouvé que l'inverse fonctionne. Quand j'ai changé la chaîne de connexion pour EF dans Azure-portail de "Système.Les données.SqlClient" et de type "Custom" dans la liste déroulante, il a travaillé.
InformationsquelleAutor Will Newton
20

Juste pour ajouter une autre possibilité (que j'ai rencontrés) - qui peut être le cas si vous êtes en développement/maintien d'Azur, WebApp, à l'aide d'une chaîne de connexion enregistrées dans Azure Paramètres de l'Application.

À côté de chaque chaîne de connexion dans les Paramètres de l'Application est une liste déroulante pour la chaîne de connexion de type il est très facile d'oublier de la mettre à la "Coutume" pour l'Entité Cadre de valeurs et de laisser la valeur par défaut de SQL (Base de données) - ce qui provoque aussi l'erreur ci-dessus.
- ceci est également fixé mon métadonnées mot clé de problème, mais maintenant j'ai un mot-Clé non pris en charge: 'serveur' de mise à jour: a " à l'avant du Serveur, sont passés à des guillemets simples et tout fonctionne maintenant. thx
InformationsquelleAutor oflahero
3

Je vais jeter une autre réponse, juste au cas où quelqu'un d'autre s'exécute en cela par le biais de la même bizarre scénario, comme je l'ai fait.

Pour commencer avec, comme d'autres l'ont dit, ADO chaînes de connexion et EF chaînes de connexion sont différents.

Une chaîne de connexion ADO contient un certain nombre de points-virgules, des champs séparés, ce qui peut très d'un type de connexion à l'autre, mais vous avez l'habitude de voir "data source=xxx", "initial catalog=yyy", etc. Vous pas voir "metadata=zzz".

Un EF chaîne de connexion a la même structure, mais il a un "metadata=zzz" et un "fournisseur de la chaîne de connexion=www", où "www" est un échappé de la chaîne de connexion 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
```
Tout en un format normal pour un EF chaîne de connexion 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 gens qui sont en cours d'exécution dans ce problème semble avoir coupé un EF chaîne de connexion et collé dans un endroit qui avait besoin d'une chaîne de connexion ADO. En fait, j'ai fait la même chose, mais le processus n'était pas aussi clair que ça.

Dans mon cas, j'ai eu une application web utilisée EF, de sorte que son site web.config correctement contenues EF chaînes de connexion.

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

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

J'ai déployé l'application web, essayé d'y accéder, et a obtenu le "mot-Clé non pris en charge: les métadonnées d'erreur".

Ce que je ne savais pas, c'est que MS l'outil de publication prévu une chaîne de connexion ADO, et qu'étant donné qu'il allait construire un EF chaîne de connexion.

Le résultat a été que SetParameters.xml et mon web déployée.config avait chaînes de connexion qui ressemblait à 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, l'intégré de fournisseur de la chaîne de connexion est un EF chaîne de connexion et pas une chaîne de connexion ADO, donc quand EF essayé de l'utiliser pour se connecter à la base de données, il a généré cette erreur.

En d'autres mots, lorsque vous collez les chaînes de connexion dans la publication des dialogues, vous avez besoin de coller une chaîne de connexion ADO, pas un EF chaîne de connexion, même si ce que vous avez dans le web.config vous copiez est un EF chaîne de connexion.

Vous pouvez extraire une chaîne de connexion ADO de la chaîne de connexion fournisseur de champ d'un objectif EF chaîne de connexion, et c'est ce que vous aurez besoin, si vous êtes en utilisant la même connexion à la déployer comme vous l'avez fait dans le développement local.
- J'ai eu à lire cette réponse un peu de temps pour qu'elle ait un sens, mais après des heures de casse-tête et un "mot Clé non pris en charge" type de messages, vos exemples de chaînes de connexion résolu mon problème. C'est joliment fait.
InformationsquelleAutor Jeff Dege

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

Remarquez comment il vérifie si c'est une Entité Cadre de la chaîne de connexion, et si oui, il extrait le "fournisseur" chaîne de connexion de la partie de qui, qui peut ensuite être passé dans SqlConnectionStringBuilder:

Si je n'a pas ce faire, j'aimerais obtenir que méchant "Keyword Not Supported: Metadata" erreur.

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"

Je vais partager quelque chose qui ressemble vraiment à cela.

InformationsquelleAutor Mike Gledhill

1

Pour Azure Web App, la chaîne de Connexion type n'a pas "du Système.Les données.EntityClient", Personnalisé les bonnes œuvres.
- Lorsque je fais cela, je suis d'erreur disant: "La chaîne de connexion 'maconnexion" dans la configuration de l'application fichier ne contient pas l'providerName attribut."... comment pouvez-vous ajouter le nom du fournisseur dans l'azur de configuration des fonctions? Avez-vous d'autres à côté de cela?
InformationsquelleAutor Song
1

Pour une utilisation dans Azure Paramètres de l'Application => Chaînes de Connexion:
1. Si la chaîne de connexion est généré par EF-concepteur, assurez-vous de remplacer &qout; avec " dans la chaîne.
2. Vérifier que le fournisseur=Système.Les données.SqlClient
3. Choisir le Type Personnalisé dans la liste déroulante
4. Si la connexion est pour un modèle (Entity Framework) de s'assurer que le chemin d'accès correct à votre modèle est utilisé
  Ex: Un modèle "MyWebRoot/Modèles/Monmodèle.edmx" est configuré as: metadata=res:///Models.MyModel.csdl|res:///Models.MyModel.ssdl|res://*/Models.MyModel.msl;
InformationsquelleAutor Petter Ivarsson
0
Salut,

À mon avis, la chaîne de connexion pour ADO.NET (dans ce
caseSqlConnection) ne peut pas utiliser les métadonnées. Vous êtes à l'aide de l'une des
pour Entity Framework. L'ADO.NET on 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, un pour EF
et un pour ADO.NET.

Source: http://forums.iis.net/post/2097280.aspx
InformationsquelleAutor Muhammad Rehan Qadri

Vérifier dans ce lieu

<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 voir, il y a deux chaîne de connexion pour un ADO et un autre pour le Système de Connexion ou ce que vous voulez. Dans mon cas, ConnectionString est pour le système de Connexion j'ai donc utilisé que dans:-

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

InformationsquelleAutor Rabi Shrestha

-1

Un vieux post, mais ma solution,

Malheureusement, elles n'ont pas le résoudre pour moi, en utilisant Azure Fonctions de parler à un projet distinct (bibliothèque de classe) avec un EDMX.

J'ai dû modifier le Contexte.CS constructeur de la classe de remplacement de la

: base ("Entities")

avec

: base (ConfigurationManager.ConnectionStrings["Entities"].ConnectionString)

J'espère que cela peut aider quelqu'un d'autre dans le besoin.

InformationsquelleAutor Jacob

Vous devez vous connecter pour publier un commentaire.