it-swarm.com.de

Nicht unterstütztes Schlüsselwort: Metadaten

Diese Linie:

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

Wirft:

'System.ArgumentException' trat in System.Data.dll auf, wurde jedoch nicht im Benutzercode behandelt

Zusätzliche Informationen: Schlüsselwort nicht unterstützt: 'Metadaten'.

Meine Verbindungszeichenfolge lautet:

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>

Nicht sicher, wo es schief geht.

43
ASPCoder1450

Die übergebene Zeichenfolge ist keine gültige Datenbankverbindungszeichenfolge, sondern eine EF-Verbindungszeichenfolge , die eine SQL Server-Verbindungszeichenfolge in ihrem provider connection string-Parameter enthält. WebSecurity.InitializeDatabaseConnection erwartet eine gültige Datenbankverbindungszeichenfolge

Um zu vermeiden, dass die Verbindungszeichenfolge selbst analysiert wird, können Sie die Klasse EntityConnectionStringBuilder verwenden, um die Zeichenfolge zu parsen und die Datenbankverbindungszeichenfolge aus der Eigenschaft ProviderConnectionString abzurufen

57

Als mir dies passierte, war es, weil die Verbindungszeichenfolge Folgendes hatte:

providerName="System.Data.SqlClient"

aber es sollte sein:

providerName="System.Data.EntityClient"

wie von der anderen Antwort gesagt, handelt es sich um eine EF-Verbindungszeichenfolge.

47
Will Newton

Fügen Sie einfach eine weitere Möglichkeit hinzu (die mir begegnet ist). Dies kann der Fall sein, wenn Sie eine Azure-Webanwendung mit einer in den Anwendungseinstellungen von Azure gespeicherten Verbindungszeichenfolge entwickeln/verwalten.

Neben jeder Verbindungszeichenfolge in den Anwendungseinstellungen befindet sich eine Dropdown-Liste für den Verbindungszeichenfolgentyp. Es ist sehr leicht zu vergessen, diese Option auf "Benutzerdefiniert" für Entity Framework-Werte festzulegen und den Standardwert (SQL-Datenbank) zu belassen .

20
oflahero

Ich werde noch eine Antwort werfen, nur für den Fall, dass jemand anderes durch dasselbe seltsame Szenario wie ich in diese Situation gerät.

Wie andere bereits erwähnt haben, unterscheiden sich ADO - Verbindungszeichenfolgen und EF-Verbindungszeichenfolgen.

Eine ADO - Verbindungszeichenfolge enthält eine Reihe von durch Semikolons getrennten Feldern, die von einem Verbindungstyp zu einem anderen sehr unterschiedlich sein können. In der Regel werden jedoch "Datenquelle = xxx", "Anfangskatalog = JJJ" usw. angezeigt. Sie werden nicht siehe "Metadaten = zzz".

Eine EF-Verbindungszeichenfolge hat dieselbe Struktur, jedoch eine "Metadata = zzz" und eine "Provider-Verbindungszeichenfolge = www", wobei "www" eine Escape-Verbindungszeichenfolge ADO ist.

Ein normales Format für eine ADO - Verbindungszeichenfolge lautet also:

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

Ein normales Format für eine EF-Verbindungszeichenfolge lautet:

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;

Die meisten Leute, die mit diesem Problem konfrontiert sind, scheinen eine EF-Verbindungszeichenfolge geschnitten und an einer Stelle eingefügt zu haben, an der eine Verbindungszeichenfolge ADO erforderlich war. Im Wesentlichen tat ich dasselbe, aber der Prozess war nicht so klar.

In meinem Fall hatte ich eine Webanwendung, die EF verwendete, so dass die web.config ordnungsgemäß EF-Verbindungszeichenfolgen enthielt.

Ich habe ein Bereitstellungspaket veröffentlicht, und der Prozess fordert Sie auf, die Verbindungszeichenfolgen anzugeben, die bei der Bereitstellung verwendet werden sollen. Diese werden in der generierten SetParameters.xml-Datei des Implementierungspakets gespeichert.

Ich habe die EF-Verbindungszeichenfolgen ausgeschnitten und in die Eingabefelder des Veröffentlichungsdialogfelds eingefügt.

Ich stellte die Webanwendung bereit, versuchte, darauf zuzugreifen, und erhielt den Fehler "Keyword nicht unterstützt: Metadaten".

Was ich nicht wusste, ist, dass das Veröffentlichungstool von MS eine ADO - Verbindungszeichenfolge erwartet hat und dass es bei dessen Erstellung eine EF-Verbindungszeichenfolge erstellt.

Das Ergebnis war, dass SetParameters.xml und meine implementierte web.config Verbindungszeichenfolgen hatten, die wie folgt aussahen:

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;"

Mit anderen Worten, die Verbindungszeichenfolge des eingebetteten Providers war eine EF-Verbindungszeichenfolge und keine ADO -Verbindungszeichenfolge. Wenn EF also versuchte, eine Verbindung zur Datenbank herzustellen, wurde dieser Fehler generiert.

Wenn Sie also die Verbindungszeichenfolgen in die Veröffentlichungsdialogfelder einfügen, müssen Sie eine ADO - Verbindungszeichenfolge und keine EF-Verbindungszeichenfolge einfügen, auch wenn Sie in der web.config, aus der Sie kopieren, vorhanden sind eine EF-Verbindungszeichenfolge.

Sie können eine ADO - Verbindungszeichenfolge aus dem Provider-Verbindungszeichenfolge-Feld einer EF-Verbindungszeichenfolge extrahieren. Dies ist erforderlich, wenn Sie in der Bereitstellung dieselbe Verbindung verwenden wie in der lokalen Entwicklung.

3
Jeff Dege

Hier ist ein Code, den ich verwende, um den Datenbanknamen und den Servernamen aus einer Verbindungszeichenfolge zu extrahieren.

Beachten Sie, wie geprüft wird, ob es sich um eine Entity Framework-Verbindungszeichenfolge handelt. Wenn ja, wird der Teil "Provider-Verbindungszeichenfolge" extrahiert, der dann an SqlConnectionStringBuilder übergeben werden kann:

Wenn ich nicht mache, würde ich diesen bösen "Keyword Not Supported: Metadata" -Fehler bekommen.

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

Zur Verwendung in Azure-Anwendungseinstellungen => Verbindungszeichenfolgen: 

  1. Wenn die Verbindungszeichenfolge von EF-Designer generiert wird, müssen Sie unbedingt &qout; durch " in der Zeichenfolge ersetzen. 

  2. Überprüfen Sie den Provider = System.Data.SqlClient

  3. Wählen Sie Type Custom in der Dropdown-Liste

  4. Wenn die Verbindung für ein Modell (Entity Framework) besteht, stellen Sie sicher, dass der richtige Pfad zu Ihrem Modell verwendet wird Beispiel: Ein Modell "MyWebRoot/Models/MyModel.edmx" ist folgendermaßen konfiguriert: metadata = res: ///models .MyModel.csdl | res: // / Models.MyModel.ssdl | res: //*/Models.MyModel.msl;

1
Petter Ivarsson

Für Azure Web App hat der Typ der Verbindungszeichenfolge nicht "System.Data.EntityClient", Custom funktioniert einwandfrei.

 enter image description here

1
Song

Hallo,

Meiner Meinung nach kann die Verbindungszeichenfolge für ADO.NET (in dieser CaseSqlConnection) keine Metadaten verwenden. Sie verwenden eine bestimmte für Entity Framework. Das ADO.NET sollte ungefähr so ​​aussehen:

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

Um es zusammenzufassen, benötigen Sie zwei separate Verbindungszeichenfolgen, eine für EF und eine für ADO.NET.

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

Überprüfen Sie an dieser Stelle

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

Wie Sie sehen, gibt es einen Verbindungsstring für ADO und einen für das Anmeldesystem oder was immer Sie möchten. In meinem Fall ist ConnectionString für das Anmeldesystem, also habe ich Folgendes verwendet: - 

    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