Entity framework designer "entityset" naming bug

I ran into a curious bug in the Visual Studio Entity Framework Designer (edmx editor). There is an inconsistency in how entity sets are named when importing in a database compared to when their created or edited in the designer.

I have the following model for some basic Entity Framework testing:

Database Model

To generate the model, I use the standard wizard that you use when you initially add an item of type "ADO.NET Entity Data Model" to your project.

Model Import Wizard

Using this wizard, my model is created perfectly as one would expect. However, it appears that the code that generates the model from the database, and the code that is generated by the model editor are different.

Now, I edit my model by renaming "TestTable" to "TestTables", save the model, then simply rename it back to its previous name ("TestTables" to "TestTable"). When I compare the code, the names assigned to my entity sets have now changed:

edmx Comparison

The names of the entity sets went from being named after the tables, to being the name of the table with the "Set" suffix.

Because of how I implement the standard repository pattern with Entity Framework, the naming must be consistent. This issue means that whenever I generate a new model, I have to edit it in some way, and then save it. However, future updates to the model from the database do not cause the names to revert back.

Be aware that if you're importing your database model, you may see some inconsistencies between the import and the future data generated by the entity editor.

Like this post? Please share it!

See a mistake? Edit this post!

Don't lose your code - 3 methods that can help

Inevitably, you'll lose power to your computer, have a hard drive crash, have lightening strike, accidentally delete code that hasn't been checked in, or encounter some other crazy scenario that I can't even imagine. What is your plan? Read on if you want some solutions that may just save your code.

Did I just delete that code?

I've had it happen to me, I accidentally deleted hours of work and had to spend the time to rewrite the code. I even remember a time while working at my first job that the power went out to our whole building. At the time, most computers were desktop machines without a UPS. It was seconds after the lights went out that I heard an agonizing moan from one of the offices. Another developer hadn't saved often enough and lost everything he was working on.

Use a automated screenshot tool

For the past few months, I've been using a product called TimeSnapper. Basically, it takes a screenshot of your desktop every few seconds. I have mine set up to the default of taking a snapshot every 10 seconds.

TimeSnapper Options TimeSnapper Day View

You can store the screenshots as standard image files such as PNG or JPG. You can optionally encrypt the images so that they can only be viewed with the correct encryption key.

Usually one of the first concerns with this backup method is that the image files take up a fair amount of space. Luckily, there are a few ways to optimize the screenshots. Below are the options that I use personally. I use a high level of compression for the images, and only capture the window that has focus. These settings work well with my goal of being able to read the code that was displayed on my screen at any given time.

Image Quality Options

I honestly can't recommend this product enough. It's well worth the $25 price tag. Its not only saved me from losing valuable code, but I've even used it to lookup information that I found on the web but can't relocate.

Here is partial list of features to get you salivating:

  • Play your day back like a movie - Watch your entire day in minutes, or quickly scan a time range to find code that may have been deleted.
  • Track productivity by telling it which programs should count as "productive".
  • View reports on how long each type of application is used. Not necessarily useful, but interesting nonetheless.
  • Flag sections to associate them with other items such as work items in a bug tracking system.
  • Filter by application - You can configure it to track only Visual Studio for example.

Use a keylogger

The next option has the advantage of being a little more lightweight, but may not offer the same level of code protection as using a screenshot tool. Basically, you install a keylogger that will record every keystroke that you make.

When I first had the idea to use a keylogger, I discovered that there are a number of legitimate keyloggers out there. Apparently, book authors frequently use keyloggers to save their work.

You have two options for the type of keylogger you can use. You can use a hardware solution that plugs into your computer on one end, and the mouse plugs into the other. The other option is to use a software keylogger such as PyKeylogger (open source, free).

The biggest problem with keyloggers is that they store the information as you originally typed it, not as it is in your code files. That means that if you're jumping between files, or making a lot of edits or corrections, the key log won't be of much use to you.

Most keyloggers do allow you to encrypt the recorded information so that your passwords and other sensitive information are fairly safe.

Automate code backups

There are a number of automated backup tools that will run scheduled backups of your local files. Personally, I like offsite backups for smaller files because they're portable. I use a product called JungleDisk, which I've mentioned before. I have it set up to backup my code every 15 minutes. It minimizes my potential loss of work to 15 minutes at most.

JungleDisk Backup Selection

If you frequently work on a specific network with access to a secure file share, you can also automate network backups. Windows Vista actually comes with a sophisticated file copy tool that supports quick differential copies. Keep in mind that if you're not connected to the network, you won't have any protection against lost code at all.


I've given you a few ways that you can protect your precious code (in addition to your source control system of course). Personally, I use a combination of JungleDisk and TimeSnapper. Between the two, I could potentially lose a maximum of 15 minutes of work, and in most cases, I won't lose ANY work. Can you say the same thing?

Like this post? Please share it!

See a mistake? Edit this post!

Generic Method Overloading Selection Pitfall

Recently I ran into a very unexpected behavior when working with an overloaded generic method. Basically, the selection process for overloaded versions of generic methods is different than their non-generic counterparts.

First, lets look at how a regular overloaded method signature is matched. Consider the following methods:

public void a(object obj)

public void a(IEnumerable enumerable)

If we call the method "a" with a class that implements IEnumerable such as an array or a List, the second version will be called. Basically, the compiler matches the method that is the most specific.

Now, consider the generic versions of the same methods:

public void a<T>(T obj)

public void a<T>(IEnumerable<T> enumerable)

Now, if we pass in a generic list such as "List", you might expect the second version to be called. Unfortunately, you would be wrong. The first version of the method is called. There are two ways to force the second version to be used:

((IEnumerable<string>)new List<string>());
a<string>(new List<string>());

As you can see, you can either cast the generic list specifically to a generic IEnumerable, or you can specify the type parameter on the generic method.

What you're seeing is a subtle difference in the way method overloading is handled with generic methods vs non-generic methods. Standard method overloading picks the match at compile time, and chooses the most specific, or "best" match. When you don't specify a type parameter for a generic call, it type inference to determine the correct signature to call. Unfortunately, it chooses the most direct route, not the most specific match.


I've already mentioned the ways that you can work around this issue by modifying the way that you make the call to the generic method. Unfortunately, you're relying on knowledge that the caller must have. If you want to avoid ambiguity, do not use standard method overloading. You can see that the authors of Linq to SQL must have ran into the same issue. Take a look at "InsertOnSubmit" vs "InsertAllOnSubmit". If it was easy to use method overloading for that scenario, that would have been a great opportunity for simplification.


I recommend being very careful when overloading generic methods. There are a lot of hidden side-effects that can occur. I also recommend checking out another post, which talks about the effects of overloading non-generic methods with generic methods. Don't be ambiguous when writing code that other developers may call. Make your code easy to use, but also clear as to which code path will be taken.

Like this post? Please share it!

See a mistake? Edit this post!

Jason Young I'm Jason Young, software engineer. This blog contains my opinions, of which my employer - Microsoft - may not share.

@ytechieGitHubLinkedInStack OverflowPersonal VLOG