2013-11-25 23 views
36

Questa linea:parola chiave non supportate: Metadati

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

sta gettando:

'System.ArgumentException' in system.data.dll ma non è stata gestita nel codice utente

Ulteriori informazioni : Parola chiave non supportata: "metadati".

mia stringa di connessione è:

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> 

Non so dove è im andando storto.

+0

hai provato a collegarti manualmente? hai confermato le credenziali in questo modo? –

risposta

47

La stringa trasmessa non è una stringa di connessione al database valida, è una EF connection string che contiene una stringa di connessione SQL Server nel parametro provider connection string. WebSecurity.InitializeDatabaseConnection si aspetta una stringa di connessione database valido

Per evitare il parsing della stringa di connessione da soli, è possibile utilizzare la classe EntityConnectionStringBuilder per analizzare la stringa e recuperare la stringa di connessione al database dalla sua ProviderConnectionString proprietà

+0

Capisco. Quindi, dopo aver seguito un esempio, dica da qui: http://msdn.microsoft.com/en-us/library/bb738533(v=vs.110).aspx?cs-save-lang=1&cs-lang=csharp#code -snippet-2. Devo mantenere la stringa di connessione nel file web.config o posso liberarmene? Grazie! – ASPCoder1450

+0

Forse la stringa di connessione EF funziona bene sulla mia scatola ma non su Azure –

+1

"Non su Azure" non dice molto. I tipi di stringhe di connessione non hanno nulla a che fare con l'ambiente. Se falliscono in ambienti diversi quando il codice è lo stesso, è perché puntano a server che non esistono in un ambiente o utilizzano credenziali non valide per quell'ambiente. Invia una domanda con il tuo problema –

40

Quando questo è accaduto a me era perché la stringa di connessione ha avuto:

providerName="System.Data.SqlClient" 

ma dovrebbe essere:

providerName="System.Data.EntityClient" 

perché, come detto dall'altra risposta, è una stringa di connessione EF.

+5

Questo può essere molto difficile da rintracciare, semplice quando sai – jolySoft

+1

Wow ... questo mi ha salvato dal diventare pazzo dopo ore alla ricerca di una soluzione !! Perché mai questo non viene automaticamente aggiornato quando hai installato EF?+1 – jom

16

Solo per aggiungere un'altra possibilità (che ho riscontrato) - che potrebbe essere il caso se si sta sviluppando/mantenendo una WebApp di Azure, utilizzando una stringa di connessione salvata nelle Impostazioni dell'applicazione di Azure.

Accanto a ogni stringa di connessione in Impostazioni applicazione è un menu a discesa per il tipo di stringa di connessione - è molto facile dimenticare di impostarlo su "Personalizzato" per i valori di Entity Framework e lasciarlo al valore predefinito (Database SQL) - che anche causa l'errore di cui sopra.

+1

questo ha risolto anche il mio problema con la parola chiave metadata, ma ora ho una parola chiave non supportata: 'server' aggiornamento : aveva " davanti al Server, passava a virgolette singole e tutto funziona ora. thx –

0

Ciao,

A mio parere, la stringa di connessione per ADO.NET (in questo caseSqlConnection) non può utilizzare 'metadati. Stai utilizzando uno specifico per Entity Framework. L'ADO.NET dovrebbe essere qualcosa del tipo:

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

Quindi, per riassumere, avete bisogno di due stringhe di connessione separate, una per EF e uno per ADO.NET.

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

1

ho intenzione di buttare via un'altra risposta, nel caso in cui qualcun altro corre in questo attraverso lo stesso scenario strano come ho fatto io.

Per iniziare, come altri hanno già detto, le stringhe di connessione ADO e le stringhe di connessione EF sono diverse.

Un ADO stringa di connessione contiene una serie di campi separati da virgola, che può molto da un tipo di connessione a un altro, ma di solito si vede "Data Source = xxx", "iniziale Catalogo = yyy", ecc Si farà non vedere "metadata = zzz".

Una stringa di connessione EF ha la stessa struttura, ma ha un "metadata = zzz" e una "provider connection string = www", dove "www" è una stringa di connessione ADO con escape.

Quindi un formato normale per una stringa di connessione ADO è:

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

Mentre un formato normale per una stringa di connessione EF è:

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; 

maggior parte delle persone che sono in esecuzione in questo problema sembrano aver tagliato una stringa di connessione EF e incollata in una posizione che necessitava di una stringa di connessione ADO. In sostanza, ho fatto la stessa cosa, ma il processo non era chiaro come tutto ciò.

Nel mio caso, avevo un'applicazione Web che utilizzava EF, quindi il suo web.config conteneva correttamente stringhe di connessione EF.

Ho pubblicato un pacchetto di distribuzione e il processo richiede all'utente di specificare le stringhe di connessione da utilizzare durante la distribuzione. Questi sono memorizzati nel file SetParameters.xml generato dal pacchetto di distribuzione.

Ho tagliato e incollato le stringhe di connessione EF nei campi di immissione della finestra di dialogo di pubblicazione.

Ho distribuito l'applicazione Web, ho provato ad accedervi e ho ricevuto l'errore "Parola chiave non supportata: metadati".

Quello che non ho capito è che lo strumento di pubblicazione di MS prevedeva una stringa di connessione ADO e che, dato che avrebbe costruito una stringa di connessione EF.

Il risultato è stato che SetParameters.xml e il mio web.config schierato avevano stringhe di connessione che si presentava così:

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

In altre parole, la stringa di connessione fornitore incorporato era una stringa di connessione EF e non un ADO stringa di connessione, quindi quando EF ha provato a utilizzarlo per connettersi al database, ha generato questo errore.

In altre parole, quando si incollano le stringhe di connessione nei dialoghi di pubblicazione, è necessario incollare una stringa di connessione ADO, non una stringa di connessione EF, anche se ciò che si ha nel web.config da cui si sta copiando è una stringa di connessione EF.

È possibile estrarre una stringa di connessione ADO dal campo stringa di connessione del provider di una stringa di connessione EF, ed è ciò che è necessario, se si utilizza la stessa connessione nella distribuzione come si è fatto nello sviluppo locale.

+0

Ho dovuto leggere questa risposta alcune volte per avere un senso, ma dopo ore di grattacapo e messaggi di tipo "Parola chiave non supportata", gli esempi di stringhe di connessione hanno risolto il problema. Ben fatto. –

0

Ecco un codice che uso, per estrarre il nome del database nome & da una stringa di connessione.

Notate come si controlla se si tratta di una stringa di connessione Entity Framework, e in caso affermativo, estrae la parte "fornitore di stringa di connessione" di quella, che possono poi essere passato in SqlConnectionStringBuilder:

Se no fare questo, mi piacerebbe ottenere quel brutto errore "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" 
0

Ho avuto lo stesso errore quando avevo attivato credendo che stavo abilitando ASP.NET Identity 2. Non sono la stessa cosa! Abilitato una vecchia versione di gestione delle identità che utilizza una struttura di tabella diversa per ASP.NET Identity 2 (che non ha bisogno di "abilitazione" tra l'altro - è solo lì).

Se state intenzionalmente utilizzando il vecchio ruolo di manager e ancora ottenere l'errore che potrebbe essere alla ricerca presso il LocalDB predefinito al posto del database, nel qual caso è possibile modificare per puntare a qualsiasi stringa di connessione che si desidera:

<roleManager 
 
     enabled="true" 
 
     cacheRolesInCookie="true" 
 
     defaultProvider="OurSqlRoleProvider" 
 
    > 
 
     <providers> 
 
      <add 
 
      connectionStringName="DefaultConnection" 
 
      applicationName="/" 
 
      name="OurSqlRoleProvider" 
 
      type="System.Web.Security.SqlRoleProvider" /> 
 
     </providers> 
 

 
    </roleManager>

Se siete dopo utilizzando ASP.NET Identità 2, ecco un articolo su di esso: http://johnatten.com/2014/04/20/asp-net-mvc-and-identity-2-0-understanding-the-basics/

0

Per App Web di Azure, il tipo di stringa di connessione non ha "System.Data.EntityClient", Custom funziona correttamente.

enter image description here

+0

In questo caso viene visualizzato un messaggio di errore "La stringa di connessione 'myConnection' nel file di configurazione dell'applicazione non contiene l'attributo providerName richiesto." ... come si aggiunge il nome del provider nelle impostazioni delle funzioni di azzurro? Hai fatto qualche altro set up accanto a questo? – batmaci

-1

Un vecchio post, ma la mia soluzione,

Purtroppo questi non ha risolto per me usando le funzioni Azure parlando con un progetto separato (libreria di classi) con un'EDMX.

ho dovuto modificare il costruttore della classe Context.CS sostituendo il

: base ("Entities")

con

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

Speriamo che questo potrebbe aiutare qualcun altro in difficoltà.