Esta línea:

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

Es tirar:

‘Del sistema.ArgumentException’ se ha producido en System.Data.dll pero no fue manejado en el código de usuario

Información adicional: la palabra Clave no es compatible: «metadatos».

Mi cadena de conexión es:

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>

No sabe de dónde es que voy mal.

  • has probado a conectar manualmente? se han confirmado las credenciales de esa manera?
InformationsquelleAutor ASPCoder1450 | 2013-11-25

10 Comentarios

  1. 67

    La cadena que se pasa no es una base de datos válida de la cadena de conexión, es una EF cadena de conexión que contiene una cadena de conexión SQL Server en su provider connection string parámetro. WebSecurity.InitializeDatabaseConnection espera una base de datos válida cadena de conexión

    Para evitar el análisis de la cadena de conexión, usted puede utilizar el EntityConnectionStringBuilder clase para analizar la cadena y recuperar la base de datos de la cadena de conexión de su ProviderConnectionString propiedad

    • Lo que yo veo. Así que después he seguido un ejemplo, digamos que desde aquí: msdn.microsoft.com/en-us/library/…. ¿Es necesario mantener la cadena de conexión en el web.archivo de configuración o no me deshago de ella? Gracias!
    • Tal vez por la EF cadena de conexión funciona bien en mi caja, pero no en Azure
    • «No en Azure» no dice mucho. Los tipos de cadenas de conexión no tienen nada que ver con el medio ambiente. Si fallan en diferentes entornos cuando el código es el mismo, es porque se están apuntando a los servidores que no existen en un medio o utilizar las credenciales no son válidas para ese entorno. Publicar una pregunta con tu problema
    • Véase mi respuesta a continuación de una solución para el ‘No en Azure’ problema.
  2. 55

    Cuando me pasó esto fue debido a que la cadena de conexión tenido:

    providerName="System.Data.SqlClient"

    pero debe ser:

    providerName="System.Data.EntityClient"

    porque, como dijo la otra respuesta, es un esfuerzo de la cadena de conexión.

    • Esto puede ser muy difícil de localizar, simple cuando se sabe
    • Wow… esto me salvó de ir loco después de horas buscando la solución!! ¿Por qué en la tierra es este no se actualiza automáticamente cuando se instala EF, aunque?? +1
    • Conscientes de que en Azure me encontré con que el frente de las obras. Cuando he cambiado la cadena de conexión para la EF en Azure-portal del Sistema».De datos.SqlClient» y tipo «Personalizado» en el menú desplegable funcionó.
  3. 21

    Sólo para agregar otra posibilidad (que he encontrado) – que puede ser el caso si usted está en desarrollo/mantenimiento de Azur, WebApp, utilizando una cadena de conexión guardado en Azure de la Configuración de la Aplicación.

    Al lado de cada cadena de conexión en la Configuración de la Aplicación es una lista desplegable para la cadena de conexión tipo – es muy fácil olvidarse de seleccionar la opción «Personalizado» para la Entidad Marco de los valores y la deja en el valor predeterminado de SQL (Base de datos) – que también causa el error anterior.

    • esto también fija mi metadatos de palabras clave problema, pero ahora tengo una palabra Clave que no se admite: ‘servidor’ actualización: había &quot; en la parte frontal del Servidor, conectado a las comillas simples y todo está funcionando ahora. thx
  4. 3

    Voy a tirar otra respuesta, en caso de que alguien lo demás, corre de este a través de la misma extraño escenario, como yo hice.

    Para empezar, como otros han dicho, cadenas de conexión de ADO y EF cadenas de conexión son diferentes.

    Una cadena de conexión ADO contiene un número de punto y coma separa los campos, que pueden variar de un tipo de conexión a otro, pero se suelen ver «data source=xxx», «initial catalog=yyy», etc. Usted no ver «metadatos=zzz».

    Un EF cadena de conexión tiene la misma estructura, pero tiene un «metadatos=zzz» y una «cadena de conexión del proveedor=www», donde «www» es un escapó de la cadena de conexión ADO.

    Así un formato normal para una cadena de conexión ADO:

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

    Mientras que un formato normal para una EF de la cadena de conexión es:

    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 mayoría de la gente que se están ejecutando en este problema parece que han cortado un EF cadena de conexión y pegado en un lugar que necesita una cadena de conexión ADO. En esencia, yo hice lo mismo, pero el proceso no fue tan claro como todo lo que.

    En mi caso, tuve una aplicación web que utiliza EF, por lo que su web.config correctamente los contenidos de EF cadenas de conexión.

    He publicado un paquete de implementación, y el proceso le pide las cadenas de conexión para ser utilizado cuando se vaya a implementar. Estos se almacenan en la implementación del paquete generado SetParameters.xml archivo.

    He cortado y pegado la EF cadenas de conexión en la publicación del cuadro de diálogo campos de entrada.

    He desplegado la aplicación web, trató de acceder a ella, y tiene la «palabra Clave no es compatible: metadatos de error».

    Lo que no se dan cuenta es de que MS de la herramienta de publicación de espera una cadena de conexión ADO, y que, dado que sería la construcción de un EF cadena de conexión.

    El resultado fue que SetParameters.xml y mi web implementados.config había cadenas de conexión que se veía así:

    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 otras palabras, el incrustados cadena de conexión del proveedor fue un esfuerzo de la cadena de conexión y no una cadena de conexión ADO, así que cuando EF intentó utilizar para conectarse a la base de datos, se genera este error.

    En otras palabras, cuando usted está pegando en las cadenas de conexión en la publicación diálogos, tienes que pegar una cadena de conexión ADO, no un EF cadena de conexión, incluso si lo tienes en la web.config que se copia es un EF cadena de conexión.

    Puede extraer una cadena de conexión ADO de la cadena de conexión del proveedor de campo de una EF de la cadena de conexión, y eso es lo que usted necesita, si usted está utilizando la misma conexión en el despliegue, como hizo en el desarrollo local.

    • Tuve que leer esta respuesta un par de veces para que tenga sentido, pero después de horas de dolores de cabeza y la «palabra Clave no se admite» tipo de mensajes, la cadena de conexión ejemplos finalmente solucionado mi problema. Muy bien hecho.
  5. 3

    Aquí está el código que uso, para extraer el nombre de base de datos & nombre del servidor a partir de una cadena de conexión.

    Aviso cómo se comprueba si es una Entidad del Marco de la cadena de conexión, y si es así, los extractos de la «cadena de conexión del proveedor» parte de eso, que luego puede pasar a SqlConnectionStringBuilder:

    Si me no ello, me gustaría conseguir que desagradable «Keyword Not Supported: Metadata de 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"
    • Yo iba a compartir algo de lo que realmente se parece a esto.
  6. 1

    Para Azure Web App, la cadena de Conexión tipo no ha «del Sistema.De datos.EntityClient», Personalizado buenas obras.

    La Palabra Clave No Es Compatible: Metadatos

    • Cuando hago que estoy recibiendo de error diciendo: «La cadena de conexión ‘myConnection’ en la configuración de la aplicación de archivo no contiene los necesarios providerName atributo.»… ¿cómo añadir el nombre del proveedor en el azul de las funciones de configuración? ¿Has hecho algún otro junto a esto?
  7. 1

    Para su uso en Azure Configuración de la Aplicación => Cadenas de Conexión:

    1. Si la cadena de conexión se genera por EF-diseñador asegúrese de reemplazar &qout; con " en la cadena.

    2. Verificación de que el proveedor=Sistema.De datos.SqlClient

    3. Elegir el Tipo Personalizado en la lista desplegable

    4. Si la conexión es de un modelo (Entity Framework) garantizar que la ruta de acceso correcta para su modelo se utiliza
      Ex: Un modelo de  «MyWebRoot/Modelos/MyModel.edmx» está configurado as: metadata=res:///Models.MyModel.csdl|res:///Models.MyModel.ssdl|res://*/Models.MyModel.msl;

  8. 0

    Hola,

    En mi opinión, la cadena de conexión para ADO.NET (en este
    caseSqlConnection) no se puede utilizar metadatos. Estás usando el específico
    para Entity Framework. El ADO.NET uno debe ser algo así como:

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

    Así que, para resumir, usted necesita dos separar las cadenas de conexión, uno para EF
    y uno de ADO.NET.

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

  9. 0

    Comprobar en este lugar

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

    Como usted puede ver que hay un dos de cadena de conexión, uno para ADO y otro para el inicio de Sesión del Sistema, o lo que quieras. En mi caso, ConnectionString para el inicio de Sesión del sistema lo he usado en:-

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

  10. -1

    Un viejo post, pero mi solución,

    Lamentablemente, estos no se resuelve para mí el uso de Azure Funciones hablando con un proyecto independiente (biblioteca de clase) con un EDMX.

    Tuve que editar el Contexto.CS constructor de la clase sustitución de la

    : base ("Entities")

    con

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

    Espero que esto pueda ayudar a alguien en necesidad.

Dejar respuesta

Please enter your comment!
Please enter your name here