Entity Framework

...now browsing by category

 

The bad (might be good to some) attribute introduced in MVC4 – [InitializeSimpleMembership]

Thursday, August 21st, 2014

Yesterday I deployed a MVC4 app to Winhost and got this error below when I clicked on “Log In” or “Register”, which I didn’t when deployed to local IIS.

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)

I had seen such error before; mostly the error was due to some misspelled SQL server name or firewall blocking remote access, etc. I checked my SQL server connection strings for both SqlClient and Entities Framework model and were able to connect to the remote SQL db hosted at Winhost. When I submitted a support ticket to Winhost tech team, their server side log showed that my app tried to connect to a SQL Express instance which they don’t support. How strange was that? I do not use SQL Express and my database which contains the ASP.Net Membership objects resides on a full version local SQL Server, not Express. There is no place in my web.config that has anything to do with SQL Express instance. So I examined the Controller codes where the Log In link is clicked; here it was, the new “InitializeSimpleMembership” attribute on the AccountController class which was created automatically by my selecting the “Internet Application” MVC4 project template. This was something new introduced by MVC4 team at Microsoft, where a bunch of genius are always trying to come up with some dummy robot codes to ┬ámake everything so automatic – by “simply” looking for a SQL Express db to initiate the Membership provider for Web.Security; this “InitializeSimpleMembership” attribute, as it turns out, was the only culprit for all these non-simple headaches when you deploy your site to hosting server that usually do not support SQL Express. And there was no warning or error when I used the Publishing wizard from VS2012 to deploy the site to Winhost.

The fix? Simply commented out the attribute, as shown below,and re-deployed to Winhost; then everything works!

[Authorize]

  //[InitializeSimpleMembership]
    public class AccountController : Controller
    {
        //
        // GET: /Account/Login

        [AllowAnonymous]
        public ActionResult Login(string returnUrl)
        {
            ViewBag.ReturnUrl = returnUrl;
            return View();

Adding the specified count to the semaphore would cause it to exceed its maximum count.

Wednesday, June 27th, 2012

This was a scary error message I got it today while I tried to switch my EF project to connect to a live database. The way I did the switch was have a pair of Entity Framework connection strings in my web.config, with one pointing to development and one to production database, and when the switch turned to production, the system will automatically pick up the live connection string; and that’s it. Test had been going well in development environment and the production database was exact copy, in terms of schema, of the developmental one, so I felt confident to make the switch and expected the codes should run as expected.

But then came this ugly and convoluted error message from the bottom of Entity framework, “Adding the specified count to the semaphore would cause it to exceed its maximum count.”; what on the earth was this? Google search for the phrase returned quite a few answers, some suggesting it might be sql queries had error, other pointing to Microsoft internal bug in db connection pooling. I found this one clicked – disabling pooling; I always favor simple than complex; this was simplest to do, just added an entry to my connection string, which by default was enabling connection pooling. Amazingly, that did it and the error went away! So here was the EF connection string before I made the change,┬áconnectionString=”metadata=res://*/MyModel.csdl|res://*/MyModel.ssdl|res://*/MyModel.msl;provider=System.Data.SqlClient;provider connection string="data source=sqlSvr1;initial catalog=sqlDb1;integrated security=false;user id=user1;password=password1234!;multipleactiveresultsets=True;App=EntityFramework"”

and here is the connection string that cleared the semaphore error, ┬áconnectionString=”metadata=res://*/MyModel.csdl|res://*/MyModel.ssdl|res://*/MyModel.msl;provider=System.Data.SqlClient;provider connection string="data source=sqlSvr1;initial catalog=sqlDb1;integrated security=false;user id=user1;password=password1234!;pooling=false;multipleactiveresultsets=True;App=EntityFramework"”

More interestingly, after the error went away, I took out the pooling=false, and ran the app again, things just flied without anymore problem; I also switched back to development database, with pooling option enabled, and still didn’t see the semaphore error as I expected that I would. So, if I could regenerate the error at some point, I suspect if I just simply clean the solution and rebuild the entire solution, I might achieve the same outcome – no more this dreadful and convoluted error, “Adding the specified count to the semaphore would cause it to exceed its maximum count.” (got it from the InnerException)


Trouble with System.Data.Objects.DataClasses.EntityObject

Friday, June 17th, 2011

I had a .net project that was initially written in C# .Net 2.0, then upgraded to 3.5, and recently to 4.0. So naturally the project have both Linq to SQL class (dbml) and Entity Framework data model class (edmx).

Then this error occurred when I was compiling a ASP.Net page that referenced a EF method call from the data layer, “Error 36 The type ‘System.Data.Objects.DataClasses.EntityObject’ is defined in an assembly that is not referenced. You must add a reference to assembly ‘System.Data.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’….”

This message actually turned out to be related to something else – System.Data.DataSetExtensions. Because after I removed the v2.0 reference to this assembly and replaced with v4.0 version, I got a different error: “The type or namespace name ‘TypedTableBase’ does not exist in the namespace ‘System.Data’ (are you missing an assembly reference?) c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET…”. I finally tracked down the culprit: there were a few auto-generated dataset classes that were added when I created some SQL server reporting service reports to the solution while I was still in .Net 2.0. To prove that, I temporarily exclude all those Reporting Services related files from the web project that is referencing the data layer, then all the compiling errors were cleared.