Keyword Not Supported: Metadata

Question

This line:

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

Is throwing:

'System.ArgumentException' occurred in System.Data.dll but was not handled in user code

Additional information: Keyword not supported: 'metadata'.

My connection string is:

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>

Not sure where it is im going wrong.

have you tried connecting manually? have you confirmed the credentials that way? — Dave Alperovich, Dec 22 '13 at 03:12

score 82 · Accepted Answer · answered Nov 25 '13 at 12:11

82

The string you passed is not a valid database connection string, it's an EF connection string that contains a SQL Server connection string in its provider connection string parameter. WebSecurity.InitializeDatabaseConnection expects a valid database connection string

To avoid parsing the connection string yourself, you can use the EntityConnectionStringBuilder class to parse the string and retrieve the database connection string from its ProviderConnectionString property

answered Nov 25 '13 at 12:11

Panagiotis Kanavos

120,703
13
188
236

I see. So after I followed an example say from here: http://msdn.microsoft.com/en-us/library/bb738533(v=vs.110).aspx?cs-save-lang=1&cs-lang=csharp#code-snippet-2. Do I need to keep the connection string in the web.config file or do I get rid of it? Thanks! – ASPCoder1450 Nov 25 '13 at 16:30
Perhaps byt the EF connection string works well on my box but not on Azure – Manuel Hernandez Oct 23 '14 at 06:20
1

"Not on Azure" doesn't say much. The types of connection strings have nothing to do with the environment. If they fail on different environments when the code is the same, it's because they are pointing to servers that don't exist on one environment or use invalid credentials for that environment. Post a question with your problem – Panagiotis Kanavos Oct 23 '14 at 06:47
See my answer below for a solution to the 'Not on Azure' issue. – oflahero Nov 06 '18 at 16:42

score 62 · Answer 2 · answered Jul 30 '14 at 16:16

62

When this happened to me it was because the connection string had:

providerName="System.Data.SqlClient"

but it should be:

providerName="System.Data.EntityClient"

because as was said by the other answer, it is an EF connection string.

answered Jul 30 '14 at 16:16

Will Newton

1,583
13
10

6

This can be very hard to track down, simple when you know – jolySoft Jun 30 '15 at 15:30
1

Wow... this saved me from going insane after hours looking for solution!! Why on earth is this not automatically updated when you installed EF though?? +1 – Yom T. Jan 02 '18 at 20:41
2

Aware that in Azure I found that the opposite works. When I changed the connection string for EF in Azure-portal to "System.Data.SqlClient" and used type "Custom" in the dropdown it worked. – Petter Ivarsson Nov 05 '18 at 15:36
1

Thank you that saved to me a while of time – Aymane Lassfar Dec 26 '21 at 12:29

score 25 · Answer 3 · answered Aug 25 '15 at 17:14

25

Just to add another possibility (which I encountered) - which might be the case if you're developing/maintaining an Azure WebApp, using a connection string saved in Azure's Application Settings.

Beside each connection string in the Application Settings is a dropdown for the connection string type - it's very easy to forget to set this to 'Custom' for Entity Framework values and leave it at the default (SQL Database) - which also causes the above error.

answered Aug 25 '15 at 17:14

oflahero

1,268
10
17

1

this also fixed my metadata keyword issue, but now i have a Keyword not supported: 'server' update: had " in front of the Server, switched to single quotes and all is working now. thx – Mr. Kraus Apr 08 '16 at 22:00

score 10 · Answer 4 · answered Jul 11 '17 at 09:44

Here's some code I use, to extract the database name & server name from a connection string.

Notice how it checks if it's an Entity Framework connection string, and if so, it extracts the "provider connection string" part of that, which can then be passed into SqlConnectionStringBuilder:

If I didn't do this, I'd get that nasty "Keyword Not Supported: Metadata" error.

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"

I was going to share something that really looks like this. – Guilherme de Jesus Santos Feb 15 '19 at 13:51 — Guilherme de Jesus Santos, Feb 15 '19 at 13:51

score 4 · Answer 5 · answered Jun 29 '17 at 16:14

I'm going to throw out another answer, just in case someone else runs into this through the same weird scenario as I did.

To start with, as others have said, ADO connection strings and EF connection strings are different.

An ADO connection string contains a number of semicolon-separated fields, which can very from one connection type to another, but you usually see "data source=xxx", "initial catalog=yyy", etc. You will not see "metadata=zzz".

An EF connection string has the same structure, but it has a "metadata=zzz" and a "provider connection string=www", where "www" is an escaped ADO connection string.

So a normal format for an ADO connection string is:

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

While a normal format for an EF connection string is:

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;

Most folks who are running into this problem seem to have cut an EF connection string and pasted it into a place that needed an ADO connection string. In essence, I did the same thing, but the process wasn't as clear as all that.

In my case, I had a web application that used EF, so its web.config properly contained EF connection strings.

I published a deployment package, and the process prompts you for the connection strings to be used when deploying. These are stored in the deployment package's generated SetParameters.xml file.

I cut and pasted the EF connection strings into the publish dialog's entry fields.

I deployed the web application, tried to access it, and got the "Keyword not supported: metadata" error.

What I didn't realize is that MS's publish tool expected an ADO connection string, and that given it it would construct an EF connection string.

The result was that SetParameters.xml and my deployed web.config had connection strings that looked like this:

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 other words, the embedded provider connection string was an EF connection string and not an ADO connection string, so when EF tried to use it to connect to the database, it generated this error.

In other words, when you are pasting the connection strings into the publish dialogues, you need to paste a ADO connection string, not an EF connection string, even if what you have in the web.config you are copying from is an EF connection string.

You can extract an ADO connection string from the provider connection string field of an EF connection string, and that's what you will need, if you're using the same connection in the deploy as you did in local development.

I had to read this reply a few times for it to make sense, but after hours of head-scratching and "Keyword not supported" type messages, your connection string examples finally fixed my problem. Nicely done. — Mike Gledhill, Feb 01 '18 at 13:11

Petter Ivarsson · Answer 6 · 2018-11-08T09:16:29.180

4

For use in Azure Application Settings => Connection Strings:

If the connection string is generated by EF-designer be sure to replace &qout; with " in the string.
Check that provider=System.Data.SqlClient
Choose Type Custom in the dropdown
If the connection is for a model (Entity Framework) ensure that correct path to your model is used Ex: A model "MyWebRoot/Models/MyModel.edmx" is configured as: metadata=res:///Models.MyModel.csdl|res:///Models.MyModel.ssdl|res://*/Models.MyModel.msl;

edited Nov 08 '18 at 09:16

answered Nov 05 '18 at 15:46

Petter Ivarsson

463
6
6

1

Thanks! This answer saved me today in the service management portal. – Bob Marley Mar 03 '20 at 15:58

score 2 · Answer 7 · answered Mar 12 '16 at 08:49

Hi,

In my opinion, the connection string for ADO.NET (in this caseSqlConnection) can't use 'metadata. You're using the one specific for Entity Framework. The ADO.NET one should be something like:
"data source=KAPS-PC\KAPSSERVER;initial catalog=vibrant;integrated security=True"
So, to sum it up, you need two separate connection strings, one for EF and one for ADO.NET.

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

score 2 · Answer 8 · answered Nov 03 '17 at 05:16

2

For Azure Web App, Connection string type has not "System.Data.EntityClient", Custom works good.

answered Nov 03 '17 at 05:16

Song

593
9
21

When I do that I am getting error saying "The connection string 'myConnection' in the application's configuration file does not contain the required providerName attribute."... how do you add the provider name in the azure functions settings? Did you do any other set up beside this? – Emil Jan 08 '18 at 11:17

score 0 · Answer 9 · answered Jun 29 '20 at 08:44

Dry This, Remove metadata Info from your ConnectionString.

Change this.

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

To

<add name="DefaultConnection" connectionString="data source=***********;initial catalog=********;persist security info=True;user id=*********;password=********;MultipleActiveResultSets=True;App=EntityFramework&quot;" providerName="System.Data.SqlClient" /></connectionStrings>

Nice try but it didn't work for me. Exception: ""Format of the initialization string does not conform to specification starting at index 218."" But I'm writing C# and my connection string is coming from an old VB EF application, so perhaps not surprising that it didn't work straight away. Not a big deal in this case, I'll make a new connection string. — Zeek2, Jan 21 '21 at 17:37

score 0 · Answer 10 · answered Mar 18 '21 at 08:20

Before i give My Solution let me explain something , I got this problem too , im using EntityFramework and Ado.net you cant use Entity framework Connection string in ADo and vice versa , so what i did was in the Web.config file i left the EF Connection string(Metadata one) and in the Controller for ADO i Added the connection string which i got from the database(properties). add the ADO string like this : SqlConnection sql = new SqlConnection();

sql.ConnectionString = @"Data Source=.\alienbwr;Initial Catalog=ABTO_POS;Integrated Security=True;Connect Timeout=30;Encrypt=False;TrustServerCertificate=False;ApplicationIntent=ReadWrite;MultiSubnetFailover=False";(dont use my string)

score -1 · Answer 11 · edited Jan 17 '18 at 17:55

-1

An old post but my solution,

Unfortunately these didn't solve it for me using Azure Functions talking to a separate project (class library) with an EDMX.

I had to edit the Context.CS class constructor replacing the

: base ("Entities")

with

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

Hopefully this might help someone else in need.

edited Jan 17 '18 at 17:55

Ele

33,468
7
37
75

answered Jan 17 '18 at 17:24

Jacob

160
1
7

score -1 · Answer 12 · answered Mar 15 '18 at 14:53

Check in this place

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

As you can see there's a two connection string one for ADO and another for the Login System or whatever you want. In my case, ConnectionString is for Login system so I've used that in:-

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

Keyword Not Supported: Metadata

12 Answers12

Linked

Related