この行:
WebSecurity.InitializeDatabaseConnection(connectionStringName: "DefaultConnection", userTableName: "UserProfile", userIdColumn: "UserID", userNameColumn: "UserName", autoCreateTables: true);
投げています:
System.Data.dllで「System.ArgumentException」が発生しましたが、ユーザーコードでは処理されませんでした
追加情報:サポートされていないキーワード: 'metadata'。
私の接続文字列は次のとおりです。
add name="DefaultConnection" connectionString="metadata=res://*/TalyllynModel.csdl|res://*/TalyllynModel.ssdl|res://*/TalyllynModel.msl;provider=System.Data.SqlClient;provider connection string="data source=***********;initial catalog=********;persist security info=True;user id=*********;password=********;MultipleActiveResultSets=True;App=EntityFramework"" providerName="System.Data.SqlClient" /></connectionStrings>
どこが間違っているのかわかりません。
渡された文字列は有効なデータベース接続文字列ではありません。 EF接続文字列 で、provider connection string
パラメータにSQL Server接続文字列が含まれています。 WebSecurity.InitializeDatabaseConnectionは、有効なデータベース接続文字列を予期しています
接続文字列を自分で解析しないようにするには、 EntityConnectionStringBuilder クラスを使用して文字列を解析し、その ProviderConnectionString プロパティからデータベース接続文字列を取得します
これが私に起こったのは、接続文字列に次が含まれていたためです:
providerName="System.Data.SqlClient"
ただし、次のようにする必要があります。
providerName="System.Data.EntityClient"
他の答えで言われたように、それはEF接続文字列だからです。
別の可能性を追加するために(私が遭遇しました)-Azureのアプリケーション設定に保存された接続文字列を使用して、Azure WebAppを開発/保守している場合に該当する可能性があります。
アプリケーション設定の各接続文字列の横には、接続文字列タイプのドロップダウンがあります-これをEntity Framework値の「カスタム」に設定し、デフォルトのままにするのを忘れるのは非常に簡単です(SQLデータベース)-上記のエラーも発生します。
他の誰かが私と同じ奇妙なシナリオでこれに遭遇した場合に備えて、別の答えを投げます。
はじめに、他の人が言ったように、ADO接続文字列とEF接続文字列は異なります。
ADO接続文字列にはいくつかのセミコロンで区切られたフィールドが含まれます。これらのフィールドは接続タイプごとに異なりますが、通常「data source = xxx」、「initial catalog = yyy」、など。not「metadata = zzz」を参照してください。
EF接続文字列の構造は同じですが、「metadata = zzz」と「provider connection string = www」があります。「www」はエスケープされたADO接続文字列です。
したがって、ADO接続文字列の通常の形式は次のとおりです。
data source=myserver;
initial catalog=mydatabase;
Persist Security Info=True;
User ID=myusername;
Password=mypassword;
MultipleActiveResultSets=True
EF接続文字列の通常の形式は次のとおりです。
metadata=res://*/MyDbContext.csdl|
res://*/MyDbContext.ssdl|
res://*/MyDbContext.msl;
provider=System.Data.SqlClient;
provider connection string="
data source=myserver;
initial catalog=mydatabase;
Persist Security Info=True;
User ID=myusername;
Password=mypassword;
MultipleActiveResultSets=True;
application name=EntityFramework
"
この問題に直面しているほとんどの人は、EF接続文字列を切り取り、ADO接続文字列を必要とする場所に貼り付けたようです。本質的に、私は同じことをしましたが、プロセスそれほど明確ではありませんでした。
私の場合、EFを使用するWebアプリケーションがあったため、web.configにはEF接続文字列が適切に含まれていました。
展開パッケージを公開しましたが、展開時に使用する接続文字列の入力を求めるメッセージが表示されます。これらは、展開パッケージの生成されたSetParameters.xmlファイルに保存されます。
EF接続文字列をカットして、公開ダイアログの入力フィールドに貼り付けました。
Webアプリケーションをデプロイし、アクセスしようとすると、「サポートされていないキーワード:メタデータ」エラーが発生しました。
私が気付いていなかったのは、MSのパブリッシュツールがADO接続文字列を想定しており、EF接続文字列を作成すると仮定したことです。
その結果、SetParameters.xmlとデプロイされたweb.configには次のような接続文字列が含まれていました。
metadata=res://*/MyDbContext.csdl|
res://*/MyDbContext.ssdl|
res://*/MyDbContext.msl;
provider=System.Data.SqlClient;
provider connection string="
metadata=res://*/XxDbContext.csdl|
res://*/XxDbContext.ssdl|
res://*/XxDbContext.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;
""
つまり、埋め込みプロバイダー接続文字列はADO接続文字列ではなくEF接続文字列であったため、EFがそれを使用してデータベースに接続しようとすると、このエラーが生成されました。
つまり、公開ダイアログに接続文字列を貼り付けるときは、web.configにあるものであっても、EF接続文字列ではなく、ADO接続文字列を貼り付ける必要がありますコピー元はEF接続文字列です。
EF接続文字列のプロバイダー接続文字列フィールドからADO接続文字列を抽出できます。これは、デプロイで使用したのと同じ接続を使用している場合に必要です。ローカル開発。
以下は、接続文字列からデータベース名とサーバー名を抽出するために使用するコードです。
Entity Framework接続文字列であるかどうかを確認する方法に注意してください。そうであれば、その「プロバイダー接続文字列」部分を抽出し、SqlConnectionStringBuilder
に渡すことができます。
私がなかったこれを行うと、その厄介な "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"
Azure Application Settings => Connection Stringsで使用する場合:
接続文字列がEFデザイナーによって生成された場合は、必ず&qout;
with "
の文字列。
Provider = System.Data.SqlClientであることを確認してください
ドロップダウンで「カスタム」を選択します
接続がモデル(Entity Framework)の場合、モデルへの正しいパスが使用されていることを確認します例:モデル "MyWebRoot/Models/MyModel.edmx"は、metadata = res:// /Models.MyModel.csdl | res:///Models.MyModel.ssdl|res://*/Models.MyModel.msl;
こんにちは、
私の意見では、ADO.NETの接続文字列(この場合はSqlConnection)は「メタデータ」を使用できません。 Entity Frameworkに固有のものを使用しています。 ADO.NETは次のようになります。
"data source=KAPS-PC\KAPSSERVER;initial catalog=vibrant;integrated security=True"
要約すると、EF用とADO.NET用の2つの接続文字列が必要です。
こちらでチェックイン
<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" />
ご覧のとおり、ADO用とログインシステム用またはその他何でも)の2つの接続文字列があります。私の場合、ConnectionStringはログインシステム用です。
SqlConnection con = new SqlConnection(ConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString);
SqlCommand cmd = null;
SqlDataReader dr = null;
protected void Page_Load(object sender, EventArgs e)