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 the 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.

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.

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 feedback.

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 :

[code language=”csharp”]"Unable to load the specified metadata resource" [/code]

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.

 

Authentication in Module vs MessageHandler

We are often confused about where to put our authentication code in the Asp.Net life cycle’s pipeline. I believe the below discussion can come to help in that regard.

Modules vs MessageHandler:  We can use HTTP message handler to handle our authentication logic. In this case, the message handler examines the HTTP requests and sets the principal. But there are some trade-offs you want to consider before doing that.

  • An HTTP module sees all the requests that go through the ASP.NET pipeline, a message handler sees only the requests that are bound to the web API.
  • We can set authentication logic for each routes using message handlers
  • HTTP modules only work with IIS, so it can only be used for web hosting. Message handler doesn’t depend on IIS. Authentication using message handler can be used for both web hosting and self-hosting.
  • HTTP modules are used for IIS logging, auditing etc
  • HTTP modules run very early in the ASP.NET pipeline. On the other hand, if the principal is set using the message handler, then it only runs when that message handler runs and the principal’s value gets reset when response leaves the message handler.

Usually, if self-hosting is not needed, HTTP module is the correct place to put authentication code. And if we need self-hosting, we need message handlers to handle authentication logics.

Authentication basics in ASP.Net

Authentication: Is the process that makes it known about the identity of the user. When a user logs in with his username, password, the server identifies the user based on that.

Creating the principal:

  • Authentication happens in the host. EX: IIS. IIS uses HTTP modules for authentication.
  • Modules can be built in or custom.
  • The host authenticates the user by creating a Principal, It is an IPrincipal object. It represents the security context under which the code is running.
  • Host attaches this newly created principal to the current thread. As we know whenever a request comes to the web server it creates a separate thread for that request to be handled. (Huge discussion). It does so by setting the Thread.CurrentPrincipal.
  • Each principal contains an object called Identity that contains information about the user.
  • If the user is authenticated the identity.isAuthenticated property returns true. For anonymous requests, it returns false.

Setting the principal:

  • For custom authentication: We need to set the principal in two places.
    • Thread.CurrentPrincipal
    • HttpContext.Current.User

Code:

[sourcecode language=”csharp”]

Private void SetPrincipal(IPrincipal Principal)

{

       Thread.CurrentPrincipal = principal;

       if(HttpContext.Current.User != null)

        {

            HttpContext.Current.User = principal;

        }

}

[/sourcecode]

  • For web hosting we need to set these both. For self hosting the HttpContext.Current.User is null.

Modules vs MessageHandler:  We can use HTTP message handler to handle our authentication logic. In this case, the message handler examines the HTTP requests and sets the principal. But there are some trade-offs you want to consider before doing that.

  • An HTTP module sees all the requests that go through the ASP.NET pipeline, a message handler sees only the requests that are bound to the web API.
  • We can set authentication logic for each routes using message handlers
  • HTTP modules only work with IIS, so it can only be used for web hosting. Message handler doesn’t depend on IIS. Authentication using message handler can be used for both web hosting and self-hosting.
  • HTTP modules are used for IIS logging, auditing etc
  • HTTP modules run very early in the ASP.NET pipeline. On the other hand, if the principal is set using the message handler, then it only runs when that message handler runs and the principal’s value gets reset when response leaves the message handler.

Usually, if self-hosting is not needed, HTTP module is the correct place to put authentication code. And if we need self-hosting, we need message handlers to handle authentication logics.