none
Unable to determine the provider name for connection of type 'System.Data.SqlClient.SqlConnection'. RRS feed

  • Question

  • We have two clients having issues running our solution running  .NET 4.0, EntityFramework 5 (the 4.0 version).  It is occurring on 2 different OS’s and it is not able to be reproduce locally.

    Client 1: Windows Server 2008 R2 – Pointing to SQL 2005 SP4 database.  Can connect to the DB with ADO.NET and the server responds to pings.

    Client 2: Windows 7 – Database server unknow.  Can connect to the DB with ADO.NET and the server responds to pings.

    There stack trace for the error:

    2012-11-16 13:08:27                        True: [E][TimeSummit.PreLoader.Application_ThreadException]              Unable to determine the provider name for connection of type 'System.Data.SqlClient.SqlConnection'.

       at System.Data.Entity.ModelConfiguration.Utilities.DbConnectionExtensions.GetProviderInvariantName(DbConnection connection)

       at System.Data.Entity.Internal.InternalConnection.get_ProviderName()

       at System.Data.Entity.Internal.LazyInternalContext.InitializeContext()

       at System.Data.Entity.Internal.InternalContext.GetEntitySetAndBaseTypeForType(Type entityType)

       at System.Data.Entity.Internal.Linq.InternalSet`1.Initialize()

       at System.Data.Entity.Internal.Linq.InternalSet`1.get_InternalContext()

       at System.Data.Entity.Infrastructure.DbQuery`1.System.Linq.IQueryable.get_Provider()

       at System.Linq.Queryable.Where[TSource](IQueryable`1 source, Expression`1 predicate)

       at dotTime.EntityFramework.QueryRepository.GenericQueryRepository.GetAll[TEntity](Expression`1 whereClause, Boolean QueryLocal)

       at dotTime.UI.SecurityUI.SecurityRoleMembers.LoadData(SecurityRoleHolder srh, SecurityRoleRow role)

       at dotTime.UI.SecurityUI.SecurityPanel.uiSecurityRoles_SecurityRoleSelectionChanged(Object sender, SecurityRoleChangedEventArgs e)

       at dotTime.UI.SecurityUI.SecurityRolesUI.uilstSecurityRole_SelectedIndexChanged(Object sender, EventArgs e)

       at dotTime.UI.SecurityUI.SecurityRolesUI.cboApplications_SelectedIndexChanged(Object sender, EventArgs e)

       at dotTime.UI.SecurityUI.SecurityRolesUI.Load()

       at dotTime.UI.SecurityUI.SecurityPanel.SetDataBinding()

       at dotTime.UI.SecurityUI.SecurityUI.SetView(PropertyView View)

       at dotTime.UI.SecurityUI.SecurityUI..ctor(PropertyView View)

       at TimeSummit.Main.ProcessMenu(String tag)

       at System.Windows.Forms.ToolStripItemClickedEventHandler.Invoke(Object sender, ToolStripItemClickedEventArgs e)

       at System.Windows.Forms.ToolStripDropDown.OnItemClicked(ToolStripItemClickedEventArgs e)

       at System.Windows.Forms.ToolStrip.HandleItemClick(ToolStripItem dismissingItem)

       at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)

       at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)

       at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)

       at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)

       at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)

       at System.Windows.Forms.Control.WndProc(Message& m)

       at System.Windows.Forms.ToolStrip.WndProc(Message& m)

       at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)

       at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


    Wayne

    Monday, November 19, 2012 9:27 PM

Answers

  • The problem was buried down in the .NET Framework.

    In the Machine.Config file under the <system.data> section there were two <DbProviderFactories> sections.  The true exception was:

    "'DbProviderFactories' section can only appear once per config file error'"

    This exception was being caught and ignored causing entity framework to think it couldn't find any suitable provider.

    Out of several test environments and clients using our software with Entity Framework only these 2 computers have had this problem.

    To Resolve:

    Edit the Machine.Config file in the appropriate Framework version folder. (On the 64bit client this situation existed in both 64 and 32bit configurations.) Remove the extra "DbProviderFactories" section.

     <system.data>       <DbProviderFactories>

                      <!-- There may or may not be entries in this section. -->

             </DbProviderFactories> <!-- This is the line to remove - empty element --><DbProviderFactories/>        </system.data>

     

    Thanks to bbcompent1 on the ASP forums for directing me to the solution once I had the correct exception.

    Adam

    • Marked as answer by wisew Wednesday, December 12, 2012 8:38 PM
    Wednesday, December 12, 2012 8:35 PM

All replies

  • The problem was buried down in the .NET Framework.

    In the Machine.Config file under the <system.data> section there were two <DbProviderFactories> sections.  The true exception was:

    "'DbProviderFactories' section can only appear once per config file error'"

    This exception was being caught and ignored causing entity framework to think it couldn't find any suitable provider.

    Out of several test environments and clients using our software with Entity Framework only these 2 computers have had this problem.

    To Resolve:

    Edit the Machine.Config file in the appropriate Framework version folder. (On the 64bit client this situation existed in both 64 and 32bit configurations.) Remove the extra "DbProviderFactories" section.

     <system.data>       <DbProviderFactories>

                      <!-- There may or may not be entries in this section. -->

             </DbProviderFactories> <!-- This is the line to remove - empty element --><DbProviderFactories/>        </system.data>

     

    Thanks to bbcompent1 on the ASP forums for directing me to the solution once I had the correct exception.

    Adam

    • Marked as answer by wisew Wednesday, December 12, 2012 8:38 PM
    Wednesday, December 12, 2012 8:35 PM
  • This should have broken pretty much any .net web app that uses the asp.net config file hierarchy with or without Entity Framework.  Duplicate sections in the config hierarchy have been the source of many yellow screens of death.  For example, we usually install ELMAH in the GAC on all of our machines so that any .net web app will log unhandled exceptions.  This works great until you install ELMAH via NuGet into a new project.  The NuGet install inserts some ELMAH stuff into the application level web.config most of which have to be removed.

    "The Key, The Whole Key, and nothing but The Key... So help me Codd"

    Monday, December 17, 2012 7:40 PM
  • Thanks for the info Adam.

    We were running .NET 4.0 on a 64bit OS and thought that the machine config being used was in

    C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config

    This didn't have the duplicate entry...

    However after running this code:

    System.Runtime.InteropServices.RuntimeEnvironment.SystemConfigurationFile

    We determined that our app was using this machine config:

    C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config

    And indeed there was a duplicate <DbProviderFactories> element.

    After removing it the app ran!

    It would have been much easier to troubleshoot if the exception had mentioned that the machine.config file was corrupt instead of the error message as described by OP.

    Anyway, thanks for the info, you saved our sanity!



    • Edited by Freshbru Friday, May 9, 2014 2:47 PM
    Friday, May 9, 2014 2:46 PM