Jeremiah Clark's Blog https://docs.microsoft.com/archive/blogs/miah/feed.xml A place to collect my ramblings about Microsoft and the .NET Framework. Thu, 02 Apr 2015 18:38:41 GMT en-US hourly 1 Visual Studio Unit Testing Extensions v1.2.0.0 https://docs.microsoft.com/archive/blogs/miah/visual-studio-unit-testing-extensions-v1-2-0-0 Tue, 07 Feb 2012 09:21:00 GMT https://blogs.msdn.microsoft.com/miah/2012/02/07/visual-studio-unit-testing-extensions-v1-2-0-0/ Version 1.2.0.0 of these Unit Testing Extensions are available on CodePlex today. The original post that talks about the project can be found here.  An updated NuGet package is also available.

This release contains additional assertions on IEnumerable<T>, String, and Type.  Additionally, a helper method was added, AssertHelper.AssertFailed(), to allow consumers to create their own custom assertions.

Here are some examples of the new assertions in action:

// IEnumerable<T>
 
[TestMethod]
public void Test()
{
    IEnumerable<int> source = new List<int>();
    source.ShouldBeEmpty();
}
 
[TestMethod]
public void Test()
{
    IEnumerable<int> source = new List<int>() { 1 };
    source.ShouldNotBeEmpty();
}
 
[TestMethod]
public void Test()
{
    IEnumerable<int> source = new List<int>() { 1, 2, 3, 4, 5 };
    source.ShouldContain(2);
}
 
[TestMethod]
public void Test()
{
    IEnumerable<int> source = new List<int>() { 1, 2, 3, 4, 5 };
    source.ShouldNotContain(6);
 
    source = new List<int>();
    source.ShouldNotContain(1);
}
 
[TestMethod]
public void Test()
{
    IEnumerable<int> source = new List<int>() { 1, 2, 3, 4, 5 };
    source.ShouldHaveCountOf(5);
}
 
[TestMethod]
public void Test()
{
    IEnumerable<int> source = new List<int>() { 1, 2, 3, 4, 5 };
    source.ShouldNotHaveCountOf(4);
}
 
[TestMethod]
public void Test()
{
    IEnumerable<int> source = new List<int>() { 1, 2, 3, 4, 5 };
    source.ShouldHaveCountOfAtLeast(4);
}
 
[TestMethod]
public void Test()
{
    IEnumerable<int> source = new List<int>() { 1, 2, 3, 4, 5 };
    source.ShouldHaveCountOfAtMost(6);
}
 
 
// String
 
[TestMethod]
public void Test()
{
    "test".ShouldHaveLengthOf(4);
    String.Empty.ShouldHaveLengthOf(0);
}
 
[TestMethod]
public void Test()
{
    "test".ShouldNotHaveLengthOf(3);
    String.Empty.ShouldNotHaveLengthOf(1);
}
 
[TestMethod]
public void Test()
{
    "test".ShouldHaveLengthOfAtLeast(3);
    String.Empty.ShouldHaveLengthOfAtLeast(0);
}
 
[TestMethod]
public void Test()
{
    "test".ShouldHaveLengthOfAtMost(5);
    String.Empty.ShouldHaveLengthOfAtMost(2);
}
 
 
// Type
 
[TestMethod]
public void Test()
{
    (typeof(ICollection)).ShouldBeAssignableFrom(typeof(IEnumerable));
}
 
[TestMethod]
public void Test()
{
    (typeof(IList)).ShouldBeAssignableFrom<IEnumerable>();
}
]]> PowerShell and SQL Server Compact 4.0: A Happy Mix https://docs.microsoft.com/archive/blogs/miah/powershell-and-sql-server-compact-4-0-a-happy-mix Mon, 08 Aug 2011 18:53:03 GMT https://blogs.msdn.microsoft.com/miah/2011/08/08/powershell-and-sql-server-compact-4-0-a-happy-mix/ Using SQL Server Compact 4.0 from PowerShell is easy and powerful.

Here is an example that shows how to reference the needed libraries, create the database, and add a table to the database – all from PowerShell.

   1: $binpath = "C:\Program Files\Microsoft SQL Server Compact Edition\v4.0\Desktop\";
   2: [Reflection.Assembly]::LoadFile("$binpath\System.Data.SqlServerCe.dll")
   3: $connectionString = "Data Source='C:\temp\testDB.sdf';"
   4:  
   5: $engine = New-Object "System.Data.SqlServerCe.SqlCeEngine" $connectionString
   6: $engine.CreateDatabase()
   7: $engine.Dispose()
   8:  
   9: $connection = New-Object "System.Data.SqlServerCe.SqlCeConnection" $connectionString
  10: $command = New-Object "System.Data.SqlServerCe.SqlCeCommand"
  11: $command.CommandType = [System.Data.CommandType]"Text"
  12: $command.Connection = $connection
  13:  
  14: $connection.Open()
  15:  
  16: $command.CommandText = "CREATE TABLE [Files] ([Id] int NOT NULL  IDENTITY (1,1), [Name] nvarchar(450) NOT NULL);"
  17: $command.ExecuteNonQuery()        
  18:             
  19: $command.CommandText = "ALTER TABLE [Files] ADD CONSTRAINT [PK_Files] PRIMARY KEY ([Id]);"
  20: $command.ExecuteNonQuery()
  21:             
  22: $command.CommandText = "CREATE UNIQUE INDEX [IX_Files_Name] ON [Files] ([Name] ASC);"
  23: $command.ExecuteNonQuery()
  24:  
  25: $command.Dispose()
  26: $connection.Close();
  27: $connection.Dispose;
  28:  
  29:

Using SQL Server Compact also provides the ability to deploy the scripts without having to install an SQL Server on the target machine.  You can copy the libraries from “C:\Program Files\Microsoft SQL Server Compact Edition\v4.0\bin” and “C:\Program Files\Microsoft SQL Server Compact Edition\v4.0\Desktop” to the location of your scripts and the SQL Compact Engine will be able to run anywhere.

]]> ASP.NET MVC: Fun With Routes https://docs.microsoft.com/archive/blogs/miah/asp-net-mvc-fun-with-routes Mon, 24 Jan 2011 17:10:00 GMT https://blogs.msdn.microsoft.com/miah/2011/01/24/asp-net-mvc-fun-with-routes/ For the purposes of this post, let’s say that we are building a community blogging site.  We want multiple users to be able to maintain separate blogs on the site.  We have an area in our MVC application that is called Blogs.  We have a controller in the Blogs area called BlogController and this controller will return views that display the blog posts.

Our URL path to a blog post could be something like this: /Blogs/Blog/ViewPost/jeremiah.clark/2011/01/15/SomePostTitle
The route for this path would be:

   1: routes.MapRoute(
   2:     "Blogs_display", 
   3:     "Blogs/Blog/ViewPost/{username}/{year}/{month}/{day}/{postTitle}"
   4: );


And our BlogController would look something like this:

   1: public class BlogController : Controller
   2: {
   3:     private readonly IBlogRepository _blogRepository;
   4:  
   5:     public BlogController(IBlogRepository blogRepository)
   6:     {
   7:         this._blogRepository = blogRepository;
   8:     }
   9:  
  10:     public ActionResult ViewPost(string username, int year, 
  11:         int month, int day, string postTitle)
  12:     {
  13:         // validate arguments
  14:         ...
  15:  
  16:         var blogModel = blogRepository.GetPost(username, year, 
  17:             month, day, postTitle);
  18:  
  19:         return View(blogModel);
  20:     }
  21: }


Instead of this, we want the path to the post to be: /Blogs/jeremiah.clark/2011/01/15/SomePostTitle
The difference is that we don’t want to specify a controller or action method in the path, but we still want to use the common BlogController to handle the requests.  It also makes for a cleaner and more readable URL for our blog posts.

Our new route looks like this:

   1: routes.MapRoute(
   2:     "Blogs_display",
   3:     "Blogs/{username}/{action}/{year}/{month}/{day}/{postTitle}",
   4:     new { controller = "Blog", action = "ViewBlog" }
   5: );


And our new BlogController looks something like this:

   1: public class BlogController : Controller
   2: {
   3:     private readonly IBlogRepository _blogRepository;
   4:     private string _blogOwner;
   5:  
   6:     public BlogController(IBlogRepository blogRepository)
   7:     {
   8:         this._blogRepository = blogRepository;
   9:     }
  10:  
  11:     protected override void Initialize(RequestContext requestContext)
  12:     {
  13:         base.Initialize(requestContext);
  14:         this.blogOwner = this.ControllerContext.RouteData
  15:             .Values["username"].ToString();
  16:     }
  17:  
  18:     public ActionResult ViewPost(int year, int month, 
  19:         int day, string postTitle)
  20:     {
  21:         // validate arguments
  22:         ...
  23:  
  24:         var blogModel = blogRepository.GetPost(this.BlogOwner, year, 
  25:             month, day, postTitle);
  26:  
  27:         return View(blogModel);
  28:     }
  29: }


So what is happening with this new route?

The controller and the action are being set to Blog and ViewBlog for every matching request.  Every route that matches will be sent to the BlogController and it will invoke the ViewBlog action method. 

This solves part of our problem, but not the entire thing. 

  • We still need to validate that the username part of a path is a valid user.
  • This breaks the route to any other controllers that exist in the Blogs area.
  • We don’t want a path available to the BlogController, it must specify a username.

Here is a good spot to use an IRouteConstraint.  We can create a class that implements this interface and apply it to the username route value.  If the constraint passes, then we have a match and a valid user.  If not, then the route does not match and the routing system searches for a different matching route.  Here is an implementation of IRouteConstraint that checks to see if the supplied username value exists in our repository:

   1: public class BlogOwnerRouteConstraint : IRouteConstraint
   2: {
   3:     private readonly IUserRepository userRepository;
   4:  
   5:     public BlogOwnerRouteConstraint(IUserRepository userRepository)
   6:     {
   7:         this.userRepository = userRepository;
   8:     }
   9:  
  10:     public bool Match(HttpContextBase httpContext, Route route, 
  11:         string parameterName, RouteValueDictionary values, 
  12:         RouteDirection routeDirection)
  13:     {
  14:         string username = values["username"].ToString();
  15:         return (userRepository.Exists(username));
  16:     }
  17: }


Now we can update our route to use the constraint.  We can also add additional routes to fix our other two problems that were listed above.  Here are the new routes:

   1: // This will block any direct access to the BlogController
   2: routes.IgnoreRoute("Blogs/Blog/{*pathInfo}");
   3:  
   4: // This provides our dynamic routing based on username
   5: routes.MapRoute(
   6:     "Blogs_display",
   7:     "Blogs/{username}/{year}/{month}/{day}/{postTitle}",
   8:     new { controller = "Blog", action = "ViewBlog" },
   9:     new { username = new BlogOwnerRouteConstraint(
  10:             DependencyResolver.Current.GetService<IUserRepository>()
  11:         ) }
  12: );
  13:  
  14: // This provides the default route for any path that does not match above
  15: routes.MapRoute(
  16:     "Blogs_default",
  17:     "Blogs/{controller}/{action}/{id}",
  18:     new { controller = "Home", action = "Index", id = UrlParameter.Optional }
  19: );


This example just shows some of the cool things that can be done with ASP.NET Routing.  For more on ASP.NET Routing, check out the documentation on MSDN: http://msdn.microsoft.com/en-us/library/cc668201.aspx.

]]> Visual Studio Testing Extensions now available on NuGet https://docs.microsoft.com/archive/blogs/miah/visual-studio-testing-extensions-now-available-on-nuget Thu, 20 Jan 2011 12:02:00 GMT https://blogs.msdn.microsoft.com/miah/2011/01/20/visual-studio-testing-extensions-now-available-on-nuget/ I have become a huge fan of NuGet lately.  It really makes managing references and dependencies a lot easier.

If you are not familiar with NuGet, here is the description from its site:

NuGet (formerly known as NuPack) is a free, open source developer focused package management system for the .NET platform intent on simplifying the process of incorporating third party libraries into a .NET application during development.

So today I added the Visual Studio Testing Extensions as a package in the official NuGet feed.  Once installed, you can use NuGet to insert the library into your testing application instead of downloading it and adding the reference manually.

Here are the quick steps once NuGet is installed in Visual Studio:

First, you can right-click on the References item in the Test Project, and select the “Add Library Package Reference” option.

image

This will bring up a dialog that will allow you to search for and add packages to your project. You will need to select the Online option on the left, and then you can search for a package as shown on the right of the image.  Finally, click install to have NuGet install the package into your project.

image

Once you have installed the package, the library assembly will be downloaded to a new “package” directory in your solution folder and the reference will be added to your project.

image

NuGet makes it that simple.

]]> Book Review – Microsoft .NET: Architecting Applications for the Enterprise https://docs.microsoft.com/archive/blogs/miah/book-review-microsoft-net-architecting-applications-for-the-enterprise Tue, 04 Jan 2011 21:01:00 GMT https://blogs.msdn.microsoft.com/miah/2011/01/04/book-review-microsoft-net-architecting-applications-for-the-enterprise/ For the entire month of January, I am doing the Daddy Day Care thing for our 4 month old twins.  Since I can’t really work during this time, I figured that it would be a good chance to catch up on some reading that I have been putting off.

This book does a fantastic job of explaining common industry architecture patterns and practices in the context of .NET technologies.  The book was well organized and flowed as the reader is led through the process of designing a multi-tier architecture.  From inversion of control to invariants, domain driven design to dependency injection, mocking to model view controller; this book explains it all.

I really like that the writers explained the various patterns without showing preference to any one specific methodology.  The pros and cons of using the various industry approaches were shown for each of the primary.NET delivery technologies (MVC, Web Forms, Windows Forms, WPF, Silverlight).  They maintained an objective stance and I think that is important in a reference book like this.

The book consistently references classics like Martin Fowler’s Patterns of Enterprise Architecture and Eric Evans’s Domain Driven Design.  It highlights the topics discussed in those references and shows how to apply them to .NET architectures.  While not a deep reference material, this book is a great pocket reference for various design fundamentals.  Anybody interesting in learning, or honing, the application of solid design fundamentals should definitely take a look at this book.

]]> Visual Studio Unit Testing Extensions v1.1.0.0 https://docs.microsoft.com/archive/blogs/miah/visual-studio-unit-testing-extensions-v1-1-0-0 Fri, 03 Dec 2010 12:15:00 GMT https://blogs.msdn.microsoft.com/miah/2010/12/03/visual-studio-unit-testing-extensions-v1-1-0-0/ I just released version 1.1.0.0 of these Unit Testing Extensions on CodePlex today.  The original post that talks about the project can be found here.

This release contains additional assertions on DateTime, ICollection<T>, and String.  This release is also targeted to the .NET 4 Framework.

Here are some examples of the new assertions in action:

[TestMethod]
public void Test()
{   
   DateTime foo = DateTime.Now;   
   foo.ShouldBeBefore(Datetime.MaxValue);
} 
 
[TestMethod]
public void Test()
{  
   DateTime foo = DateTime.Now;
   foo.ShouldBeAfterOrSameAs(Datetime.MinValue);
} 
 
[TestMethod]
public void Test()
{
   List<int> foo = new List<int>() { 1, 2, 3 };
   foo.ShouldNotBeEmpty();
} 
 
[TestMethod]
public void Test()
{
   List<int> foo = new List<int>() { 1, 2, 3 };
   foo.ShouldContain(1);
} 
 
[TestMethod]
public void Test()
{
   List<int> foo = new List<int>() { 1, 2, 3 };
   foo.ShouldHaveCountOf(3);
} 
 
[TestMethod]
public void Test()
{
   string foo = "foobar";
   foo.ShouldContain("foo");
} 
 
[TestMethod]
public void Test()
{
   string foo = "foobar";
   foo.ShouldNotContainIgnoringCase("TEST");
}
]]> 2010 – A New Year, Some New Goals https://docs.microsoft.com/archive/blogs/miah/2010-a-new-year-some-new-goals Fri, 08 Jan 2010 21:21:00 GMT https://blogs.msdn.microsoft.com/miah/2010/01/08/2010-a-new-year-some-new-goals/ Like most people, I assume, every new year I come up with a set of goals that I would like to accomplish during the upcoming year.  But I never seem to write them down, so I always forget what my plan was by the time February rolls around.  So starting this year, I am going to make a list of the primary things that I want to achieve in 2010.

Geek-related

  • Blog more!  I tend to blog when I learn something new and I have not written a post recently (which I guess means that I have not learned anything).  I have been busy working on finishing my basement for the past few months, but that is no excuse.
  • Deep dive into compiler and language principles.  I have always had an interest in writing a compiler/language and would like to focus on that in the coming year.   I don’t think that there is any better way to become a better developer than to understand the concepts and ideas that define the basis for our work.
  • Deep dive into concurrent programming.  This and the language/compiler topic above should keep me plenty busy during the year.  This goal involves a lot of subtopics: parallel computing, functional programming, scalability, concurrency, etc.  I would just like to get a better grasp of these concepts and how they can help me to write better code.

Personal

  • Ride in RAGBRAI in July.  My father-in-law has done this event for 10 years now, and since I have gotten into cycling recently, I figure I should join him in the fun.  It is an annual event in which you ride across the state of Iowa.
  • Play in some competitive golf events.  I currently plan to participate in some of the state golf association tournaments in 2010 and would like to actually do well in these events.  This is going to require a lot of practice and play in the next few months to prepare.

Now this gives me a place throughout the year to look at the goals I have laid out for myself.  These items should keep me quite busy for a while and I will write some posts as I work to accomplish these goals.  I might even add to this list if I think of some more things.

]]> ServiceLocator and Unity – Be Careful https://docs.microsoft.com/archive/blogs/miah/servicelocator-and-unity-be-careful Tue, 12 May 2009 15:00:00 GMT https://blogs.msdn.microsoft.com/miah/2009/05/12/servicelocator-and-unity-be-careful/ Chris Tavarez has provided a handy adapter (UnityServiceLocator) for using ServiceLocator to resolve types from a Unity container.  You can then use ServiceLocator.SetLocatorProvider() to register the UnityServiceLocator as the default provider for ServiceLocator. 

For this example, we will be using ServiceLocator and Unity to resolve the type IFoo to Foo using a singleton lifetime.  Then we will get two instances of IFoo and compare to ensure that they are the same object. 

Here are four different approaches to configuring ServiceLocator and Unity that I have found during my searches on the web:

1:

   1: static void Main(string[] args)
   2: {            
   3:     UnityServiceLocator locator = new UnityServiceLocator(ConfigureUnityContainer());
   4:     ServiceLocator.SetLocatorProvider(() => locator);
   5:  
   6:     var a = ServiceLocator.Current.GetInstance<IFoo>();
   7:     var b = ServiceLocator.Current.GetInstance<IFoo>();
   8:  
   9:     Console.WriteLine(a.Equals(b));            
  10: }
  11:  
  12: private static IUnityContainer ConfigureUnityContainer()
  13: {
  14:     UnityContainer container = new UnityContainer();
  15:     container.RegisterType<IFoo, Foo>(new ContainerControlledLifetimeManager());
  16:     return container;
  17: }

2:

   1: static void Main(string[] args)
   2: {      
   3:     ServiceLocator.SetLocatorProvider(() => new UnityServiceLocator(ConfigureUnityContainer()));
   4:  
   5:     var a = ServiceLocator.Current.GetInstance<IFoo>();
   6:     var b = ServiceLocator.Current.GetInstance<IFoo>();
   7:  
   8:     Console.WriteLine(a.Equals(b));            
   9: }
  10:  
  11: private static IUnityContainer ConfigureUnityContainer()
  12: {
  13:     UnityContainer container = new UnityContainer();
  14:     container.RegisterType<IFoo, Foo>(new ContainerControlledLifetimeManager());
  15:     return container;
  16: }

3:

   1: static void Main(string[] args)
   2: {
   3:     UnityContainer container = new UnityContainer();
   4:     container.RegisterType<IFoo, Foo>(new ContainerControlledLifetimeManager());
   5:  
   6:     ServiceLocator.SetLocatorProvider(() => new UnityServiceLocator(container));
   7:  
   8:     var a = ServiceLocator.Current.GetInstance<IFoo>();
   9:     var b = ServiceLocator.Current.GetInstance<IFoo>();
  10:  
  11:     Console.WriteLine(a.Equals(b));            
  12: }

4:

   1: static void Main(string[] args)
   2: {
   3:     UnityContainer container = new UnityContainer();
   4:     container.RegisterType<IFoo, Foo>(new ContainerControlledLifetimeManager());
   5:     UnityServiceLocator locator = new UnityServiceLocator(container);
   6:     
   7:     ServiceLocator.SetLocatorProvider(() => locator);
   8:  
   9:     var a = ServiceLocator.Current.GetInstance<IFoo>();
  10:     var b = ServiceLocator.Current.GetInstance<IFoo>();
  11:  
  12:     Console.WriteLine(a.Equals(b));            
  13: }

 

So these implementations seem to to do the same basic thing: register the UnityServiceLocator and use it to resolve types.  But…

howardpayne

Pop quiz:

Can you find the subtle differences and explain the problems that they can cause? 

Explanation:

Example #1:  This implementation works as expected.  The two instances (a and b) reference the same container controlled object.

Example #2:  This one is just wrong.  The two instances are not the same object, but two distinct objects.  Since the argument for the SetLocatorProvider() method is a delegate, each call to ServiceLocator.Current executes the delegate again, creating a new Unity container for every call.  This one also has the same side effect as #3.

Example #3:  This one gives the correct behavior with respect to instances a and b, but leads to a new UnityServiceLocator object being created for each ServiceLocator.Current call.  This could lead to a lot of objects just hanging around until the GC runs and reclaims the memory.

Example #4:  Works as expected.  Essentially the same as #1 but without wrapping the container creation in a method.

 

The two primary conclusions that I came to during this exercise are:

  1. Make sure that you understand the API and code that you are calling.  It may not always be black and white.  As in example #2 above, forgetting that this is a delegate can lead to the wrong behavior.
  2. Don’t rely blindly on example code from the internet.  Some of the code that I have posted is probably error prone.  Sample code is just that: a sample.
]]> Tip: Entity Framework, Unity, and The ASP.NET RoleProvider – Read the MSDN Fine Print https://docs.microsoft.com/archive/blogs/miah/tip-entity-framework-unity-and-the-asp-net-roleprovider-read-the-msdn-fine-print Mon, 11 May 2009 14:28:00 GMT https://blogs.msdn.microsoft.com/miah/2009/05/11/tip-entity-framework-unity-and-the-asp-net-roleprovider-read-the-msdn-fine-print/ A custom Role Provider is a very useful tool for adding custom authorization to your ASP.NET and/or ASP.NET MVC applications.  A common use for a custom Role Provider is when you have role information stored in a data store that differs from the schema that is used by the built-in ASP.NET Role Providers.  In this case, ASP.NET provides a abstract RoleProvider class that can be used to implement the custom provider.  This contains role-specific methods such as: CreateRole, DeleteRole, GetRolesForUser, etc.  In a custom Role Provider, you provide the implementation of these methods using your database access mechanism of choice.  The MSDN documentation for implementing a custom Role Provider is a good place to start if you want to learn more about this.

In this post, I am NOT going to detail the steps in creating a custom Role Provider.  Examples of this can be found all over the internet.  Rather, I am going to talk about a recent gotcha with implementing a custom Role Provider that was encountered on a project that I am working on. 

The following preconditions are used in our custom implementation:

  • We are using the Entity Framework as our data access and the Unity Application Block/Service Locator for dependency injection and inversion of control. 
  • We are abstracting away the Entity Framework context using the Repository pattern.
  • The IRoleRepository instance is managed by Unity using a per-request lifetime manager.

Here is a quick snippet of the initial custom provider that we implemented:

   1: public class CustomRoleProvider : RoleProvider
   2: {
   3:     private IRoleRepository roleRepository;
   4:  
   5:     public CustomRoleProvider()
   6:         : this(ServiceLocator.Current.GetInstance<IRoleRepository>())
   7:     {
   8:     }
   9:  
  10:     public CustomRoleProvider(IRoleRepository roleRepository)
  11:     {
  12:         this.roleRepository = roleRepository;
  13:     }
  14:  
  15:     // Role Provider Abstract members
  16:  
  17:     // ...
  18:  
  19:     public override void CreateRole(string roleName)
  20:     {
  21:         Role newRole = Role.CreateFromName(roleName);
  22:         this.roleRepository.Add(newRole);
  23:     }
  24:  
  25:     // ...
  26: }

At the outset, this seemed to be working great.  The application functioned.  The unit tests passed.  Our roles that were stored in the database were being managed by the custom Role Provider.  Then we started to notice some weird behavior. 

  • Direct modifications of the Role table in the database were not exposed by the role provider until a restart of Cassini/IIS.
  • Changes made using a per-request instance of IRoleRepository were not exposed by the role provider, but changes made using the System.Web.Security.Roles class were.

Blank-Facepalm

I had a facepalm moment and quickly realized that I had neglected to remember a very important part of implementing a custom Role Provider.  During the initialization of an ASP.NET application, a single instance of the RoleProvider class is instantiated and used for the life of the application.  Of course, this all made perfect sense now.  The Entity context for the role provider was effectively a singleton since is was only being injected at the beginning of the application.  It didn’t take long for this context to become stale if changes were made to the roles during other requests.

The MSDN fine print does talk about this:

 

For each role provider specified in the configuration for an application, ASP.NET instantiates a single role-provider instance that is used for all of the requests served by an HttpApplication object. As a result, you can have multiple requests executing concurrently. ASP.NET does not ensure the thread safety of calls to your provider. You will need to write your provider code to be thread safe. For example, creating a connection to a database or opening a file for editing should be done within the member that is called, such as AddUsersToRoles , rather than opening a file or database connection when the Initialize method is called.

“Implementing a Role Provider (Threading Section)", Microsoft Developer Network Library, http://msdn.microsoft.com/en-us/library/8fw7xh74.aspx

The quick fix for this problem was to change the custom role provider to use a new IRoleRepository without a lifetime manager (returning a new instance for every call to GetInstance()) for each call to a method on the provider:

   1: public class CustomRoleProvider : RoleProvider
   2: {
   3:     public CustomRoleProvider()
   4:     {
   5:     }
   6:  
   7:     // Role Provider Abstract members
   8:  
   9:     // ...
  10:  
  11:     public override void CreateRole(string roleName)
  12:     {
  13:         Role newRole = Role.CreateFromName(roleName);
  14:  
  15:         IRoleRepository roleRepository = ServiceLocator.Current.GetInstance<IRoleRepository>(“NoLifetime”);
  16:         roleRepository.Add(newRole);
  17:     }
  18:  
  19:     // ...
  20: }

So what have we learned? 

  • When using the Entity framework, make sure that you are handling your context with care.  Misuse can often cause bugs that are hard to find.
  • Read the MSDN documentation.  It may contain very important information that you might overlook or forget.
  • Integration testing is just as important as unit testing.
  • Remember that ASP.NET has some architectural paradigms that do not always behave the way that you think they should (more on this in a future post with the always fun ThreadStatic attribute).
]]> Testing Your Unity XML Configuration https://docs.microsoft.com/archive/blogs/miah/testing-your-unity-xml-configuration Fri, 03 Apr 2009 18:02:00 GMT https://blogs.msdn.microsoft.com/miah/2009/04/03/testing-your-unity-xml-configuration/ When using Unity as your IoC container, one way to configure the container is to use an configuration section in your app.config or web.config file.  A simplified example of this configuration is shown below:

   1: <?xml version="1.0" encoding="utf-8" ?>
   2: <configuration>
   3:   <configSections>
   4:     <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration" />
   5:   </configSections>
   6:  
   7:   <unity>
   8:     <typeAliases>
   9:       <typeAlias alias="IMyInterface1" 
  10:                  type="UnityConfigTestApp.IMyInterface1, UnityConfigTestApp" />
  11:       <typeAlias alias="MyClass1" 
  12:                  type="UnityConfigTestApp.MyClass1, UnityConfigTestApp" />
  13:     </typeAliases>
  14:     <containers>
  15:       <container>
  16:         <types>
  17:           <type type="IMyInterface1" mapTo="MyClass1" />
  18:         </types>
  19:       </container>
  20:     </containers>
  21:   </unity>
  22: </configuration>

This configuration allows you to specify the types and the mappings for your Unity container.  An example of how to implement this concept can be found here: http://weblogs.asp.net/podwysocki/archive/2008/03/27/ioc-and-unity-configuration-changes-for-the-better.aspx

In this post, I am going to show an easy way to test the validity of your Unity XML configuration.  In the example configuration above, we are only dealing with two types and one mapping so things are not too complicated.  But in a real application you might have a large number of types and mappings which can make the configuration difficult to maintain.  A small typo can cause your application to fail at runtime since there is no compile time validation of the Unity configuration.

To perform this validation, I am going to write a couple of simple unit tests.  Now, these are not true unit tests since they are not testing a unit of code, but I found a unit test construct to be the best way to perform this validation in a simple and quickly testable way.  The two unit tests that I wrote are shown below:

   1: using System;
   2: using System.Linq;
   3: using System.Text.RegularExpressions;
   4: using System.Xml;
   5: using Microsoft.VisualStudio.TestTools.UnitTesting;
   6:  
   7: [TestMethod]
   8: [DeploymentItem(@"UnityConfigTestApp\App.config")]
   9: public void TypeAliases_should_reference_valid_types()
  10: {
  11:     XmlDocument unityConfig = new XmlDocument();
  12:     unityConfig.Load("App.config");
  13:     XmlNode unityNode = unityConfig.DocumentElement.SelectSingleNode("unity");
  14:     XmlNodeList typeAliases = unityNode.SelectNodes("typeAliases/typeAlias");
  15:  
  16:     foreach (XmlNode typeAliasNode in typeAliases)
  17:     {
  18:         string typeFullName = RemoveWhiteSpace(typeAliasNode.Attributes["type"].Value);
  19:         Type currentType = Type.GetType(typeFullName);
  20:  
  21:         Assert.IsNotNull(currentType, String.Format("'{0}' is not a valid type.", typeFullName));
  22:     }
  23: }
  24:  
  25: [TestMethod]
  26: [DeploymentItem(@"UnityConfigTestApp\App.config")]
  27: public void Type_mappings_should_be_compatible()
  28: {
  29:     XmlDocument unityConfig = new XmlDocument();
  30:     unityConfig.Load("App.config");
  31:     XmlNode unityNode = unityConfig.DocumentElement.SelectSingleNode("unity");
  32:     XmlNodeList typeList = unityNode.SelectNodes("containers/container/types/type");
  33:  
  34:     foreach (XmlNode typeNode in typeList)
  35:     {
  36:         string typeName = typeNode.Attributes["type"].Value;
  37:         string mapToName = typeNode.Attributes["mapTo"].Value;
  38:  
  39:         XmlNode typeTypeAliasNode = unityNode.SelectSingleNode(String.Format("typeAliases/typeAlias[@alias = \"{0}\"]", typeName));
  40:         XmlNode mapToTypeAliasNode = unityNode.SelectSingleNode(String.Format("typeAliases/typeAlias[@alias = \"{0}\"]", mapToName));
  41:  
  42:         Assert.IsNotNull(typeTypeAliasNode, String.Format("Could not locate a typeAlias element for '{0}'.", typeName));
  43:         Assert.IsNotNull(mapToTypeAliasNode, String.Format("Could not locate a typeAlias element for '{0}'.", mapToName));
  44:  
  45:         string typeFullName = RemoveWhiteSpace(typeTypeAliasNode.Attributes["type"].Value);
  46:         string mapToFullName = RemoveWhiteSpace(mapToTypeAliasNode.Attributes["type"].Value);
  47:  
  48:         Type currentType = Type.GetType(typeFullName);
  49:         Type mapToType = Type.GetType(mapToFullName);
  50:         Assert.IsNotNull(currentType, String.Format("'{0}' is not a valid type.", typeFullName));
  51:         Assert.IsNotNull(mapToType, String.Format("'{0}' is not a valid type.", mapToFullName));
  52:  
  53:         bool areTypesCompatible = false;
  54:  
  55:         if (currentType.IsAssignableFrom(mapToType) ||                                          // test assignabilty
  56:             mapToType.Name == currentType.Name ||                                               // or matching names
  57:             mapToType.GetInterfaces().Where(x => x.Name == currentType.Name).Count() == 1 ||    // or generic interfaces
  58:             (mapToType.BaseType != null && mapToType.BaseType.Name == currentType.Name))        // or generic base classes
  59:         {
  60:             areTypesCompatible = true;
  61:         }
  62:  
  63:         Assert.IsTrue(areTypesCompatible, String.Format("Cannot map '{0}' to '{1}'.", typeName, mapToName));                
  64:     }
  65: }
  66:  
  67: private static string RemoveWhiteSpace(string inputString)
  68: {
  69:     if (inputString == null)
  70:         return null;
  71:  
  72:     return Regex.Replace(inputString, @"[\s\r\n]", String.Empty);
  73: }

A couple of things about configuring the tests:

  1. You will notice the DeploymentItemAttribute on each of the tests.  This references the relative path to the config file from the solution directory.
  2. Any assemblies that are referenced in the unity configuration section need to be included as references in the test project.

The first test validates that the types specified in the <typeAliases> are valid types.  We just iterate through each <typeAlias> and check that the type can be found.  If it can be found, then it should be a valid type.

The second tests validates the type mapping specified in the <type> elements of the configuration.  To do this, we get the full names for the types by referencing back to the matching <typeAlias> elements.  We then get a reference to those types and compare them for compatibility (This part is done at line 55 in the code above).  The types are checked for compatibility by following a set of rules:

  1. Check to see if the types are directly assignable.
  2. Check to see if the names match.
  3. Check to see if the to type implements the from interface (needed for generic interfaces)
  4. Check to see if the to type inherits from the from base class (needed for generic base classes)

Once we have these tests in our test suite, we can validate the types and mappings without having to run the application and hope that we didn’t mistype something in the configuration.

]]>