Visual Studio 2012 testing with csla and entity framework

Question

In VS2010 my MSTest test run just fine.

When running in VS2012 I am getting an error. The test sets the Csla.ApplicationContext.User with a Custom Business Principal. When the EntityFramework is asked to provide a new ObjectContext I receive a SerializationException saying that my Custom Business Principal type cannot be found.

All the tests that use the EntityFramework fail when running through VS2012's test runner or Resharper7's test runner. I have tried NCrunch's test runner and they all pass.

How can I resolve this issue?

Cameliacamella

I found my real issue. VS2012 runs the tests in a separate AppDomain and our data access layer loads via Reflection. Still not sure why EF requires knowledge of the principal but our solution was to reset our principal to a GenericPrincipal prior to accessing EF then placing back the original. I am still wrestling with the thought that maybe an IoC container would alleviate this issue. – Cameliacamella

Can you add your findings as an answer and mark them as accepted if it solved the problem? – Commentate

Answer 1

I found my real issue. VS2012 runs the tests in a separate AppDomain and our data access layer loads via Reflection. Still not sure why EF requires knowledge of the principal but our solution was to reset our principal to a GenericPrincipal prior to accessing EF then placing back the original. I am still wrestling with the thought that maybe an IoC container would alleviate this issue

Cameliacamella

Actually I don't think EF wants to know about your principal specifically, but it may look at it, and when it attempts to marsh the object from the original appdomain to this new one, it fails (as it can't find the assembly your principal is defined in. – Pooler

Answer 2

You should also note the .net 4.5 claims principal approach. Im Using EF5.0 on VS2012 targeting .net4.5 target .net4.5 test the difference between WindowsIdentity.GetCurrent().Name;
and Thread.CurrentPrincipal

I use a little routine like this under FORMS auth. So Windows Auth and Forms Auth can play together.

Not the exact same situation, but it does highlight the important difference which is overlooked when everything just works.
Worth a quick read... http://msdn.microsoft.com/en-us/library/system.security.claims.claimsprincipal.current

using System;
using System.Collections.Generic;
using System.Linq;
using System.Security.Claims;
using System.Security.Principal;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using System.Web;


namespace BosIdentityManager
{
public class BosPrincipal
{
    /// <summary>
    /// The current principal is set during FORMS authentication.  If WINDOWS auth mode is in use, Windows sets it.
    /// </summary>
    /// <returns> The Name from Thread.CurrentPrincipal.Identity.Name unless alternate delegate is configured</returns>  
    public static string GetCurrentUserName()
    {
    //   http://msdn.microsoft.com/en-us/library/system.security.claims.claimsprincipal.current   
    //  with forms auth and windows integrated,ClaimsPrincipal.Current will be set.

        var prin = ClaimsPrincipal.Current;  //normally this reverts to Thread.CurrentPrincipal, but can chnage !
        return prin.Identity.Name;

    }

    public static string GetCurrentWindowsUserName()
    {
        return WindowsIdentity.GetCurrent().Name;   
    }

    public static void SetPrincipal(BosMasterModel.Membership memb)
   {
       var claims = new List<Claim>(){ new Claim(ClaimTypes.Name, memb.SystemUser.UserName),
                                       new Claim(ClaimTypes.NameIdentifier,memb.UserId.ToString()),
                                       new Claim(ClaimTypes.Role, "SystemUser") };

       var ClaimsId = new ClaimsIdentity(claims,"Forms");

       var prin = new ClaimsPrincipal(ClaimsId);
       Thread.CurrentPrincipal = prin;

   }
}
}

Untinged