C#, Entity Framework

Add Sql Script through code first migration – Entity Framework

You can add scripts to code first migration.

First, make sure if any existing migration is pending. If so,

-open the package manager console window.

-Select appropriate project

-Run “update-database” command (without quote)

Now, add the migration you want to put SQL into.

-Run “Add-Migration SQLIntoMigration”  (without quote)

A new MIgration file will be added with an empty body like this:

public override void Up()

public override void Down()


Now add the below code inside up() method.

SQL(@"Select * FROM TEMP");

I hope it helps!

C#, Programming, Uncategorized

How to get the description of an enum in C#?

This simple code shows how to get the description of an enum in C#.

A sample enum could be-

public enum Colors{
[Description("Green but not so much!")]
[Description("Sky Blue")]
[Description("Blood Red")]
Blood Red

This below code gets the description of the enum-

public string GetEnumDescription(object val)
.FirstOrDefault()?.GetCustomAttribute<DescriptionAttribute>(false)?.Description ??
(val.ToString() == "0" ? "" : val.ToString());

C#, Programming

Get display name of an enum in C#

This is a simple code to get the display name of an enum in C#. Sometimes we need a proper name, not the property names of the enum. The code below gives us the display name of an enum in c#.

A sample enum could be like this:

public enum UserType
[Display(Name = "Administrator")]
[Display(Name = "Compliance Officer")]
[Display(Name = "HR & Accounts")]

To get the display name-

public string GetDisplayName(this object val)
return val.GetType().GetMember(val.ToString())
.FirstOrDefault()?.GetCustomAttribute(false)?.Name ??
(val.ToString() == "0" ? "" : val.ToString());

It gets the custom attribute- “Display Attribute” to get the display name of the enum.

SCRUM, Technology

Estimate bugs in SCRUM?

Bug fix in the agile scrum is a buzzing issue to discuss that we all love to avoid. We use tools like JIRA and scrum board to estimate bugs. But do we want to estimate bugs? Do we really need to?

To understand this aspect properly, we will first need to revise the artifacts of SCRUM. SCRUM has sprints. and for each sprint, it has a fixed backlog that the development team commits to. And it is thriving to produce a functional increment of the product in the sprint.

Now, how do the bugs really come? Bugs can come from mainly two scenarios. The development team has completed a story. During the sprint, the team has found a problem with the completed story. As a result, a bug/issue has been raised. In this context, do we really need to estimate bugs? The more important question would be, when do we actually estimate it? As there is a bug, it means the functionality that the team has produced is not done. So the story cannot be done/completed. Until all the issues related to the story is done away, the story remains open, even if the sprint reaches its end. At this point, the sprint goal won’t be achieved and the PBI (Product Backlog Item) item number will not decrease.

The other scenario- the team hasn’t found any issue during the sprint and the story was completed during one of the previous sprints. Now during the ongoing sprint, the team has found some issues. So how do we really handle this? Sprint backlog cannot be changed as PBI tracking will not be accurate. So the issue can not be handled in this sprint. So we put it in the next sprint.

During the next sprint’s planning meeting, will the team give any estimation? For any kind of estimation to be done for the backlog items, we know that the team has to analyze the stories, understand the problem they are solving, and then plan how many stories they want to do this sprint. But for a bug to be estimated, the team needs to analyze the bug first to understand what is causing the bug to be produced in the first place!

Estimating bugs takes a lot of time (not in all but a lot of cases). When we have investigated a bug enough to make a proper estimation, we could have also fixed that bug at that time.

Now we might say that there are some bugs that we easily know how much time it will take to solve. For defects like these, what we can do is that we can allocate a chunk of time from the sprint to solve as many bugs the team can solve. And this could be at the beginning of the sprint. Jeff Sutherland uses at PatientKeeper half a day of the sprint to solve the bugs remaining from the previous sprint. There is a healthy discussion on stackoverflow on estimating the bugs.
But most importantly, we need to ask the question- if there is something so trivial is left behind, are we really following scrum properly? Are we really delivering functional product increment at the end of the sprint? If our retrospective is being done properly, we would be coming with these answers very early in the sprint. Only then we would be able to save time to implement functionality rather than wasting time to estimate bugs that are not even properly analyzed.

What about the production bugs or critical bugs that come from the end users? If we are following SCRUM as we should be, we will be delivering functional products and the probability of finding this kind of issues is very rare. And when we find this kind of blocking issues, this needs to be handled outside of the scrum team. You can not add a new item to the backlog, so how do you handle it? What if you only have only one scrum team and it needs to be handled right away. In that case, we can assign one or some team members, who have the profound knowledge of the item that is associated with and get it done in a separate branch -preferably as a hotfix. Or after discussing among the scrum team members, keeping in mind about the severity of the issue, the product owner can cancel the sprint for bug fix. But this has to be one of a kind exception, not as a process. They should also keep this item to be discussed in the retrospective. And in the retrospective, it should come out how it came alive in the first place and what needs to be done to avoid it in the future.

Scrum asks are we adding value to what we are doing? More often bugs occur because of technical debts, and as a result, does not bring new business value (it shouldn’t exist in the first place!), so why waste time on estimating something that doesn’t bring value to the customers? It should just be a part of the velocity, so time-boxing to reduce the waste of additional estimations is actually a good idea.

For a bug that needs to be analyzed, assign a random hour to investigate and solve that. If the team is able to fix that inside that timebox, it’s all good. But if it’s not possible then the team needs to discuss this issue according to scrum guide.
-No changes are made at this point that endangers the sprint goal set at the beginning of the sprint.
-The scope can be renegotiated between the product owner and the development team, that means escalating the issue as soon as possible.

In the end, SCRUM is all about adding value to the customers. The time spent to estimate bugs adds less value to the customer. It would have been better spent that time on creating a functional product by adhering to the scrum principles from the very beginning. When we focus more on estimating something like bugs, we are forgetting about the core of agile – Individuals and interactions over processes and tools. Just because estimating is available in issue tracking tools like JIRA and TFS, you don’t have to use that. Estimating bugs and taking that into process violates the very core agile is formed on.

If you have liked what I said here or disagreed with the article please leave a comment so that we can have a healthy discussion. And if you want to know more about SCRUM, please download and read the free SCRUM book.


Asp.Net, Programming

Entity Framework Bulk Update

We often need to update items in bulk while working with Entity Framework. As good as it is, entity framework has its quirks like any other ORM tools. Entity Framework bulk update is needed only when you need to update multiple items at a go.

We used classic ADO.NET stored procedure for our long running processes. But when updating multiple items from models at once we found it rather a tedious process to maintain. We were already using entity framework in our project for data access along with the classic ADO.NET. So decided to use entity framework for bulk update operations.

In this very short article, I am showing a way how we have updated our list of objects using entity framework DB first. Here we want to update some particular property of a list into our database.

ItemObject = Object model from database
list = the list of items we want to update
ContextFactory.GetContext() = A factory method to get a particular context. This is our application specific method.

using (var context = ContextFactory.GetContext())

                foreach (var item in list)

                    DbEntityEntry<ItemObject> entry = context.Entry(item);
                    entry.Property(p => p.ReceivedDate).IsModified = true;
                    entry.Property(p => p.ModifiedDate).IsModified = true;



Here we updated just a few properties in our model. If we want entity framework to update the whole model we need to set the entity state property to modified for the whole entity.

using (var context = ContextFactory.GetContext())

                foreach (var item in list)

                    DbEntityEntry<ItemObject> entry = context.Entry(item);
                    entry.State = EntityState.Modified;



After the loop is finished, save the context. The data will be updated in the database.

Entity framework bulk update or insert operation is slow. I’d recommend any other option if we can find to do such bulk updates. But in terms of code maintenance, we found it feasible in our case. Be sure to use it when you need this kind of operation.

I hope this helps you guys. If you have any suggestion regarding anything or how should I improve please don’t forget to knock. I’d really appreciate your feedbacks.

Asp.Net, Programming

Unable to load the specified metadata resource – Entity Framework

We got this issue when we were calling the EDMX file from our DataAccess project. We used entity framework database first approach.

Our EDMX file lied in another project and the DataAccess project was used to do various operations on the EDMX file. But we forgot to add the connection string to the corresponding EDMX file into our DataAccess Project. Hence, this very ambiguous message :

"Unable to load the specified metadata resource" 

The reason is Res://*/ is a URI which points to resources in the CURRENT assembly. If the Edm is defined in a different assembly from the code which is using it, res://*/ is not going to work because the resource cannot be found. So we need to add the connection string to all the projects that it’s being used in.
So I decided to dig a bit more and found out some possible reasons for this exception in entity framework including ours:

  • The EDMX resides in a separate project. We have to maintain connection string in both the projects. (This is our problem)
  • The MetadataArtifactProcessing property of the model You may have been changed to Copy to Output Directory.
  • There might be a post-compile task to embed the EDMX in the assembly and it’s giving errors for some reason.
  • The connection string itself is wrong. Yes I know it’s a very small thing, but it happens a lot.


Asp.Net, Programming

The mapping of CLR type to EDM type is ambiguous because multiple CLR types match the EDM type

This error occurred in our application with a particular case when we stored two procedures with the same name in two different databases. These databases were internally related. We used Entity Framework database first approach for our application.

As EF uses only class names to identify the type mapped in EDMX (namespaces are ignored) – it is a convention to allow mapping classes from different namespaces to a single model, the EDMX could not differentiate the two classes generated from the stored procedures. So it threw this particular error-

The mapping of CLR type to EDM type is ambiguous because multiple CLR types match the EDM type

So the solution is:

  • Don’t use classes with the same unqualified name.
  • Name your stored procedures differently even if they’re in separate databases if you’re planning to use them in a single BLL.