Category Archives: Async

Entity Framework 6 and Async

At a previous company that I worked for, one of my colleagues, Paul Czywczynski referred to Entity Framework as “Database Crack”. I can see where he was coming from. There is no substitute for a database developer who knows how to write a Common Table Expression. These days however, to be a well-rounded back-end developer, you’re a step ahead of the rest if you can write your own SQL code. Entity Framework is great for getting up and going quickly. The dynamic query generation is much better today than it was just a few years ago. Code-First has come a long way, especially with the introduction of Database Migrations.

The Task Parallel Library (TPL) is good. Async is great. Await is even better.

Recently, the EF team has brought asynchronous operations to the EF API. You now see extension methods for everything that executes a query; FirstOrDefaultAsync, SingleAsync, ToListAsync, etc… AWESOME right?

Not so fast…

Check this out, directly from the EF 6 Codeplex site:

For the moment, EF will detect if the developer attempts to execute two async operations at one time and throw.

Basically what this is saying, is that you cannot access the result of an async operation until you have awaited the previous. Doesn’t that effectively defeat the power and purpose of async operations in EF? I believe the problem at hand is that DbContext or ObjectContext is not thread safe. In other words, because EF manages change tracking behind the scenes, making it async is a no-no. If you change something on one thread, what happens to that object on the other thread? This is not a problem that I personally want to solve, but I hope that someone at Microsoft does. If they truly want to make the EF 6 API async, then they must tackle this as well.

These days, Microsoft is making their newer API’s task based. My advice to anyone reading this, is that if you are developing against the Microsoft stack, it would greatly benefit you to brush up on your async skills.

*** UPDATE ***

I filed a “bug” on the CodePlex site last week regarding this. Technically, it wasn’t a bug, but I wanted to see what they would say: CodePlex Entity Framework Work Item #1279

Advertisements

Await, Async, Mvc and Impersonation

I’ve been using AsyncControllers in Asp.net mvc for quite a while now.   I’ve also been using the Tasks Parallel Library sparingly.  Only recently have I used them together, with and without the new .Net 4.5 async and await keywords.  Throw unmanaged impersonation into the mix and you’re in for a smorgasbord of technologies that don’t necessarily play well together.

I want to tell you a story, but I must first set the stage for you.

  • I was developing an internal web app for my company TempWorks Software.
  • I Wanted to make use of concurrency wherever possible.
  • The data layer needed several different elevated credentials in varying contexts, other than that of the AppPoolIdentity.

Our last release to production web product, WebCenter 6 used AsyncControllers, taking advantage of the AsyncManager, rather than Task’s with continuation. If you are unfamiliar with either, have a look at this concise outline of the evolution of Mvc asynchronous controllers here. This time, I chose to use the more straightforward, Task with Task.ContinueWith.

The first problem I encountered was trying to make my impersonation context flow through my tasks and continuations. Imagine something like the following inside one of my Actions (the important thing to note is how I am doing impersonation).

FeatureEditorViewModel viewModel;

using (ElevatedUser.Impersonate())
{
    var features = LicensingService
        .GetFeatures(false);

    viewModel = new FeatureEditorViewModel(features, versionID, productID);
}

return View(viewModel);

The IDisposable ElevatedUser object you see above is a derivative of the code in the following article: Windows Impersonation Using C#. The important part about this is that it is IDisposable in my class, and that it is calling unmananged code via DllImport to do impersonation.

Interestingly enough, I never noticed any problem with this until I deployed to production servers. The reason was, that because I was using IIS Express, my AppPoolIdentity was in fact MY user account, and I happened to have permissions on the object I was accessing. When I deployed to production, the AppPoolIdentity was no longer me, it was the App Pool user account, thus making all data calls under the wrong context.

I scoured the net in search of answers, and discovered that I had a few options.

1. Change the aspnet.config file (there are 2 of them if you have an x64 machine), setting the value “legacyImpersonationPolicy” to enabled=false, and “alwaysFlowImpersonationPolicy” to enabled=true
2. Do the same as above except in the context of the app pool only (I discovered later on that this does not work)
3. Capture the impersonation context outside of my thread, and then re-impersonate inside of my thread

I chose option 3 because I wanted to adhere to the least privilege principal. I wanted keep elevated credentials to the absolute minimum so as not to expose any overlooked security holes in my application.

I came up with my own TPL extension method class that I could use in place of the default TPL methods.

using System;
using System.Linq;
using System.Security.Principal;
using System.Threading.Tasks;

public static class TaskFactoryExtensions
{

    public static Task StartNewImpersonated(this TaskFactory taskFactory, Action action)
    {
        var identity = WindowsIdentity.GetCurrent();
        return taskFactory.StartNew(() =>
        {
            using (identity.Impersonate()) 
            {
                action();
            }
        });
    }

    public static Task<TResult> StartNewImpersonated<TResult>(this TaskFactory taskFactory, Func<TResult> function)
    {
        var identity = WindowsIdentity.GetCurrent();
        return taskFactory.StartNew<TResult>(() =>
        {
            using (identity.Impersonate())
            {
                return function();
            }
        });
    }

    public static Task ContinueWithImpersonated<TResult>(this Task<TResult> task, Action<Task<TResult>> continuationAction)
    {
        var identity = WindowsIdentity.GetCurrent();

        return task.ContinueWith((antecedent) =>
        {
            using (identity.Impersonate())
            {
                continuationAction(antecedent);
            }
        });
    }

    public static Task<TNewResult> ContinueWithImpersonated<TResult, TNewResult>(this Task<TResult> task, Func<Task<TResult>, TNewResult> continuationFunction)
    {
        var identity = WindowsIdentity.GetCurrent();

        return task.ContinueWith<TNewResult>((antecedent) =>
        {
            using (identity.Impersonate())
            {
                return continuationFunction(antecedent);
            }
        });
    }

    public static Task ContinueWhenAllImpersonated(this TaskFactory taskFactory, Task[] tasks, Action<Task[]> continuationAction)
    {
        var identity = WindowsIdentity.GetCurrent();

        return taskFactory.ContinueWhenAll(tasks, (antecedent) =>
        {
            using (identity.Impersonate())
            {
                continuationAction(antecedent);
            }
        });
    }

    public static Task<TResult> ContinueWhenAllImpersonated<TResult>(this TaskFactory taskFactory, Task[] tasks, Func<Task[], TResult> continuationFunction)
    {
        var identity = WindowsIdentity.GetCurrent();

        return taskFactory.ContinueWhenAll<TResult>(tasks, (antecedent) =>
        {
            using (identity.Impersonate())
            {
                return continuationFunction(antecedent);
            }
        });
    }

    public static void ForAllImpersonated<TSource>(this ParallelQuery<TSource> source, Action<TSource> action)
    {

        var identity = WindowsIdentity.GetCurrent();

        source.ForAll(new Action<TSource>((tsource) =>
        {
            using (identity.Impersonate())
            {
                action(tsource);
            }
        }));
        
    }

}

This worked great aside from the fact that everytime I needed to use a varied overload in the TPL, I needed to code a new extension method in my class.

Enter .Net 4.5… Async, await.

Before converting my app to 4.5 and the “new way” of doing things, I ingested as many Kindle books as I could find on the topic. Here is my short list:

So here I was at a cross-roads. I now had enough knowledge to start using the async and await keywords in place of “continuations” using ContinueWith and various Wait techniques. At this point however, I theorized that if I was to substitute usage of ContinueWith (or in fact, my very own ContinueWithImpersonated as noted above) with await, that the impersonation context would be lost.

I converted a couple of methods to async/await and threw in a couple of debug breakpoints. To much chagrin, I was right, the impersonation context was lost AFTER my await keyword.

Back to the drawing board! My options were few, and I still didn’t want to turn on the aspnet.config options that I mentioned earlier.

I then diagrammed my architecture:

* Controller
* Actions -> call services via Tasks (impersonate here)
* Services -> call repositories via Tasks
* Repositories

It became very apparent that because I couldn’t persist my impersonation context through tasks and continuation, that I had to move where I was doing my impersonation.

My arch then looked like this:

* Controller
* Actions -> call services via Tasks
* Services -> call repositories via Tasks
* Repositories (impersonate here)

So, now I would have to rewrite how I was calling my database, so that impersonation was done there.

I am using a variation of Oh So Simple SQL, so I created some extension method overloads to handle this.

    public static class RepositoryExtensions
    {
        // public List<O> FetchAll<O>();
        public static List<O> FetchAll<O>(this QueryBuilder<StoredProcedure> baseQuery, IElevatedUser elevatedUser)
        {
            using (elevatedUser.Impersonate())
            {
                return baseQuery.FetchAll<O>();
            }
        }
        public static List<O> FetchAll<O>(this QueryBuilder<Query> baseQuery, IElevatedUser elevatedUser)
        {
            using (elevatedUser.Impersonate())
            {
                return baseQuery.FetchAll<O>();
            }
        }

        //public O Fetch<O>();
        public static O Fetch<O>(this QueryBuilder<StoredProcedure> baseQuery, IElevatedUser elevatedUser)
        {
            using (elevatedUser.Impersonate())
            {
                return baseQuery.Fetch<O>();
            }
        }
        public static O Fetch<O>(this QueryBuilder<Query> baseQuery, IElevatedUser elevatedUser)
        {
            using (elevatedUser.Impersonate())
            {
                return baseQuery.Fetch<O>();
            }
        }

        //public void Execute();
        public static void Execute(this QueryBuilder<StoredProcedure> baseQuery, IElevatedUser elevatedUser)
        {
            using (elevatedUser.Impersonate())
            {
                baseQuery.Execute();
            }
        }
        public static void Execute(this QueryBuilder<Query> baseQuery, IElevatedUser elevatedUser)
        {
            using (elevatedUser.Impersonate())
            {
                baseQuery.Execute();
            }
        }

    }

My IElevatedUser object looks like this:

    public interface IElevatedUser : IDisposable
    {

        IElevatedUser Impersonate();
        IElevatedUser Impersonate(string account, string password);

        string Account
        {
            get;
            set;
        }

        string Password
        {
            get;
            set;
        }

    }

The moral of the story is 2-fold.

1. Impersonation doesn’t flow through the TPL automatically
2. Make sure you are doing impersonation at the right place

I’ve also compiled the impersonation classes as a gist available here.

Twin Cities Code Camp 2012 – Day 1

This post will be a compilation of my notes from Twin Cities Code Camp 2012.

Understanding WebAPI in ASP.NET MVC 4 – Matt Milner – Rapson 56

What is web api?

  • API for HTTP Services – client and server components
  • WCF vs MVC – why do we need this api?
  • WCF – some people just want HTTP, REST services is complicated. Global error handling is almost impossible. Goal was to make WCF extremely flexible. Transport neutral just like SOAP. Because WCF was trying to cover ALL transports and protocols, HTTP became buried.

MVC was primarily built to pass back a View – typically HTML. JSON/JSONP were after thoughts. This is not a perfect model for RESTful services.

HTTP is a protocol in and of itself. Don’t need another protocol (e.g. SOAP). The protocol has been optimized over the years.

HTTP is widely accessible and MUCH easier to reach ALL devices.

Web API MVC Integration

  • MVC is for web applications
  • Web API is for web APIs
  • what they have in common is usually the model or domain

Cool new features: media type formatters for resource type handling. validation at the handler level which supports cancelation and pass-through instead of lowest level – the action. Better json support with the new System.Json library. Self-hosted testing built upon a partial wcf service stack. Support for OData URI queries. Simply return IQueryable. CONS: partial support for OData – only $page, $filter, and $sort – not $select. Doesn’t seem like the will be adding support for this. There is talk about adding built in support for Expression for DTO transformation on the server side.

There is also talk about combining the ServiceResolver configuration (configuration.ServiceResolver.SetResolver) to support both MVC and WebAPI in the same call. For example, right now you configure your MVC service resolving and a separate configuration for WebAPI service resolving. Simplification of this is on the table. Hopefully by the time the release comes around, we see a unified method.

TAKEAWAY MESSAGE: FORGET COMPLICATED SOAP PROTOCOL which is the standard for RIA Services and WCF. Simplify your api with REST. Forget about the mvc paradigm of method based access to your resources. You now access your resources via GET, POST, PUT, DELETE. You access a resource from a Controller. One controller per type of resource. Web API has content negotiation. It returns the data in the format that your request based on the Accept header. If I want JSON, I get JSON. You could expand upon this to return resources in whatever format you need; image, doc, resume, and more. The same for xml. Etc… Input validation is handled by the model binding mechanisms of MVC which builds a model state object.

Note: WebAPI is NOT a replacement for WCF. If you still need to support multiple endpoints in different protocols (for example pure TCP), then WCF is still the best option out there. If you want a simplified API that will be accessible for the widest audience, consider WebAPI.

NOTE TO SELF: check out $.validator.unobtrusive.revalidate(form, validationResult) – validationResult is the json object; { “Speaker”: “Speaker is required” } – where in this example Speaker is the name attribute of the form input element – this takes a json object and interprets it using jquery.validation unobtrusive. Is this a NEW method?

Async Today and Tomorrow – Joe Mayo – Rapson 54

Talk about the Async CTP. How we use async programming today and how we will use it in the future. The Async CTP hides the complexity of async programming. It leverages the TPL (Tasks Parallel Library).

Why do we need async for UI responsiveness? Ex. click on a button in a Windows Form. The program does some long running operation. The user doesn’t know what is happening until all of a sudden, the UI shows something. NOT A GOOD USER EXPERIENCE.

TPL at it’s core revolves around the Task class. It has a fluent api. Uses continuation methods (similar to callbacks).

  • Language Integration – Changes to C# and VB in .NET. Async – the await and async Context Keywords.
  • Every platform – Desktop, Web, and Device
  • leverage Opportunities – Clarity, lifetime, progress, UI, and exceptions

void functions – regular event handlers
functions that return typeof Task<T>– represents the ongoing operation – get exceptions off of that task. The Task wraps the <T> – it holds information about what happened when it returned the <T>.

Async CTP code looks like synchronous code except for the await and async keywords.

Previous convention was to write methods with the Async as the end of the method name. For example WriteAsync. The new paradigm is to write the method as WriteTaskAsync.

Everything after the await keyword is the continuation.

Multiple tasks in parallel… Task.WhenAll.  Or alternatively, Task.WhenAny.  NEAT!

Task based Async Patterns – continuation, cancellation, etc. Task.Wait(), AggregateException, ae.InnerExceptions, CancellationToken

Notes:  this is going to be a fun library to work with.  I can hardwly wait to get home and start coding!  That was not sarcasm but true enthusiasm.

Android Development for the .NET Developer

This is about native Android development, not developing using PhoneGap or MonoDevelop.

http://mike-marshall.net outlines the way to install the JDK, SDK, and everything you need to get an Android IDE up and running here.

  • android.app.Activity class
  • Combined with layouts (views), represents a single type of work that can be accomplished in your application
  • Reusable
    • Can be chained within your application to build a workflow
    • Can be published for use by other applications through :Intents” (more later)

Outlines how to create an Android Application Project within Eclipse.

The .net delegate event handler does not apply.

Working with resources can be annoying.

“Form” designer is very similar to XAML designer in visual studio.  Nothing is absolutely positioned unless you tell it to be as such.