Every once in a while it’s easy to get sidetracked by something that is totally irrelevant to what you are trying to accomplish.  Case in point is the Local Database Cache, where the wizard generates a *.sdf (compact framework database) at the top level of your solution.  When you start working with your code, its easy to look at the *.sdf at the top level of your solution and say “That’s where my database is”.  One might even be tempted to add a reference to the database (located at the top level of the solution) through Server Explorer, making it easier to observe changes while configuring synchronization and testing an occasionally connected client.

The problem occurs when writing code to execute synchronization and testing to verify that all is set up properly.  When verifying, its easy to open the *.sdf through Server Explorer to verify that synchronization was successful, but the changes aren’t there.  This sets off a sequence of debugging code to verify that changes are being made and there aren’t any errors or exceptions.  When the code looks and runs perfect, one would verify that the database being looked at at is the same one in the solution. Perhaps a few random queries on search engines would be appropriate too, yielding nothing.  After having checked the connection strings, which were autogenerated, it might become apparent that the location of the database isn’t necessarily the same as what the connection string indicates, especially since the Data Source contains the |DataDirectory| macro.

As it turns out, there is an *.sdf file in appDir/bin/Debug.  Considering the |DataDirectory| in the connection string, the following blog post that explained this situation quite well:

http://blogs.msdn.com/smartclientdata/archive/2005/08/26/456886.aspx

By default, |DataDirectory| means that the local database cache will be created in the same location as the *.exe, which is where all of the updates occur.  Therefore, setting Server explorer to look at appDir/bin/Debug/*.sdf does the trick.  Of course, changing the project configuration from Debug to Release would mean that the database would be in appDir/bin/Release/*.sdf.  The post describes ways to alter this location, but the default behavior seems fine for most scenarios; especially attractive is the smart client scenario where you really don’t know the physical location of the *.sdf until runtime.

Going back to the original distraction motivating this blog post, it might be best to delete the *.sdf created by the Local Database Cache wizard; Otherwise, someone might accidentally think the *.sdf at the top level of the solution is the client database cache and waste their own time in a manner described in this post. ;)

Ran into a glitch where I couldn’t retrieve the MembershipUser during the LoggedIn event.  I wanted to cache some info in Session that I would be using on multiple pages.  Yeah, I know about the tradeoffs of keeping info in Session state, but I wanted to it anyway. ;)  Normally, passing the user name should work, like this:

MembershipUser user = Membership.GetUser(LoginCtrl.UserName);

Problem was that the UserName property of LoginCtrl (the Login control reference) was blank, resulting in a null return value.  This is weird because the UserName is normally available during this event.  As it happens, User.Identity.Name was blank also; Too strange.

After Live Searching (hmm, lacks the ring of Googling) the following blog entry revealed the culprit:

http://www.codeplex.com/cssfriendly/WorkItem/View.aspx?WorkItemId=7187

To summarize, the link describes a bug in the CSS Friendly Control Adapters where the UserName and Password aren’t set if you switch the Login control to use templates.  So, here’s the fix:

string userName = (LoginCtrl.FindControl(“UserName”) as TextBox).Text;

MembershipUser user = Membership.GetUser(userName);

Needless to say, a CodePlex issue got my vote. :)