Extensions

I typically have a Utils.dll that I import in every project. For data/resource access projects, I also include my Utils.Data.dll. Utils.Data started its career as a data access application block similar to SqlHelper from the pre-EntLib days. Today, Utils.Data is a set of extensions that merely makes Enterprise Library more fun to be with.

IDataReaderExtensions

Out of the box, System.Data.IDataRecord only gives you the ability to access fields by their integer index value. As an architect that does not have supervisory control over the database or the objects within, this scares me. Any additions or re-ordering of the output fields will surely cause your index-based mapping to blow up. You could solve this with a call to .GetOrdinal(fieldName) first to get the index, but that is twice the code (not to mention boring plumbing code). My extensions do nothing novel. They simply provide string-based extensions like .GetInt32(string name) that do the retrieval and casting for you. I also added a few frequently-used new extensions like .GetNullableInt(string name) to keep my result mapping as clean as concise as possible.

Reader use with built-in features:

jeep = new Jeep()
{
	ID = row.GetInt32(0),
	Name = row.GetString(1),
	Description = row.GetString(2),
	Status = row.GetBoolean(3)
};

Reader use with extensions:

jeep = new Jeep()
{
	ID = reader.GetInt32(“JeepID”),
	Name = reader.GetString(“Name”),
	Description = reader.GetString(“Description”),
	Status = reader.GetBoolean(“Status”),
};

I advise that you never use string literals in data access code. Data access code is hit hard, so take your performance improvements when you can. I prefer having const strings locally in my data access class or having an internal static class with const strings to share with all classes in my data access project. The attached solution has examples.

Parameter and Result/Row Mapping

The now built-in ParameterMapper, RowMapper, and ResultSetMapper are beautiful. Sometimes you need a little sumpin’ special to make your code easier to read and work consistently when getting one or ten entities in a database call. Similar to how ExecuteSprocAccessor works with row and result set mappers, CreateObject and CreateCollection support generics and build an object or collection of the specified type. Instead of deriving a new class from a base mapper class, I chose to have one delegate method that generates a single object from a reader. This delegate is used by both CreateObject and CreateCollection. Let’s look at the differences with code.

Creating an object with EntLib5 features:

public Jeep GetJeepByID(int id)
{
	Database db = DatabaseFactory.CreateDatabase();
	IParameterMapper jeepParameterMapper = new JeepParameterMapper();
	IRowMapper jeepRowMapper = new JeepRowMapper();
	IEnumerable jeeps = db.ExecuteSprocAccessor(StoredProcedures.GetJeepByID, jeepParameterMapper, jeepRowMapper, id);
	return jeeps.First();
}

internal class JeepRowMapper : IRowMapper
{
	public Jeep MapRow(System.Data.IDataRecord row)
	{
		return new Jeep()
		{
			ID = row.GetInt32(0),
			Name = row.GetString(1),
			Description = row.GetString(2),
			Status = row.GetBoolean(3)
		};
	}
}

Creating an object with extensions:

public Jeep GetJeepByID(int id)
{
	Database db = DatabaseFactory.CreateDatabase();
	DbCommand cmd = db.GetStoredProcCommand(StoredProcedures.GetJeepByID, id);
	Jeep jeep = db.CreateObject(cmd, GenerateJeepFromReader);
	return jeep;
}

private Jeep GenerateJeepFromReader(IDataReader reader)
{
	Jeep jeep = null;
	if (reader.Read())
	{
		jeep = new Jeep()
		{
			ID = reader.GetInt32(Fields.JeepID),
			Name = reader.GetString(Fields.JeepName),
			Description = reader.GetString(Fields.JeepDescription),
			Status = reader.GetBoolean(Fields.JeepStatus),
		};
	}
	return jeep;
}

One more thing to note is that my CreateObject, CreateCollection, and their GetAccessor equivalents have my customized exception handling logic that makes use of the StoredProcedureException. We’ll go through that now.

Customized and Standardized Exceptions

The only value in logging exceptions is if your entire system logs exceptions and other messages in a consistent and meaningful manner. If error messages are logged as “ERROR!” or “All bets are off!!!” then you shouldn’t bother logging. In the real world, few developers, architects, or support staff have access to production databases. Having meaningful and detailed error messages is key to troubleshooting an issue and meeting your SLAs. I created a simple StoredProcedureException that provides the executed (or attempted) command as part of the stack trace.

In the attached code samples, you’ll see two data access methods that call “ExceptionStoredProcedure” that does nothing other than RAISERROR(‘This is an exception’, 16, 1). With the built-in features, you can expect a SqlException and a stack trace that looks like this:

at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
   at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning()
   at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
   at System.Data.SqlClient.SqlDataReader.ConsumeMetaData() at System.Data.SqlClient.SqlDataReader.get_MetaData()
   at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
   at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
   at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
   at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior)
   at System.Data.Common.DbCommand.ExecuteReader(CommandBehavior behavior)
   at Microsoft.Practices.EnterpriseLibrary.Data.Database.DoExecuteReader(DbCommand command, CommandBehavior cmdBehavior)
      in e:\Builds\EntLib\Latest\Source\Blocks\Data\Src\Data\Database.cs:line 460
   at Microsoft.Practices.EnterpriseLibrary.Data.Database.ExecuteReader(DbCommand command)
      in e:\Builds\EntLib\Latest\Source\Blocks\Data\Src\Data\Database.cs:line 846
   at Microsoft.Practices.EnterpriseLibrary.Data.CommandAccessor`1.d__0.MoveNext()
      in e:\Builds\EntLib\Latest\Source\Blocks\Data\Src\Data\CommandAccessor.cs:line 68 at System.Linq.Enumerable.First[TSource](IEnumerable`1 source)
   at DataAccess.JeepDataAccess.GetJeepByIDShowingException(Int32 id)
      in C:\Dev\Cookbook\Utilities\EntLibExtensions\5.0\EntLibExtensions\DataAccess\JeepDataAccess.cs:line 58
   at Client.Program.TestExceptionGetWithEntLib5Only()
      in C:\Dev\Cookbook\Utilities\EntLibExtensions\5.0\EntLibExtensions\Client\Program.cs:line 58
   at Client.Program.Main(String[] args)
      in C:\Dev\Cookbook\Utilities\EntLibExtensions\5.0\EntLibExtensions\Client\Program.cs:line 22

With my extensions, you can expect a StoredProcedureException that includes the text of the full stored procedure being executed at the time. This has saved me countless times as my log table stores the full stack trace and I can reproduce exactly what happened without guessing. The InnerException of the StoredProcedureException will be the same SqlException seen above. The customized stack trace will look like this:

[Stored procedure executed: ExceptionStoredProcedure @RETURN_VALUE=-6, @JeepID=1]
   at Soalutions.Utilities.Data.DatabaseExtensions.CreateObject[T](Database db, DbCommand cmd, GenerateObjectFromReader`1 gofr)
      in C:\Dev\Cookbook\Utilities\EntLibExtensions\5.0\EntLibExtensions\EntLibExtensions\DatabaseExtensions.cs:line 49
   at DataAccess.JeepDataAccess.GetJeepByIDShowingExceptionWithExtensions(Int32 id)
      in C:\Dev\Cookbook\Utilities\EntLibExtensions\5.0\EntLibExtensions\DataAccess\JeepDataAccess.cs:line 65
   at Client.Program.TestExceptionGetWithExtensions()
      in C:\Dev\Cookbook\Utilities\EntLibExtensions\5.0\EntLibExtensions\Client\Program.cs:line 66
   at Client.Program.Main(String[] args)
      in C:\Dev\Cookbook\Utilities\EntLibExtensions\5.0\EntLibExtensions\Client\Program.cs:line 23

So that’s really it. There is some other hidden goodness in there, but it’s not really worth talking about in this post.

Download sample solution: EntLibExtensions.zip – 140 KB (143,360 bytes)

System.IdentityModel.Tokens.SecurityTokenException, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer.

at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.CreateClaims(SamlSecurityToken samlSecurityToken)
at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ValidateToken(SecurityToken token)
at Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ValidateToken(SecurityToken token)
at Microsoft.IdentityModel.Web.TokenReceiver.AuthenticateToken(SecurityToken token, Boolean ensureBearerToken, String endpointUri)
at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request)
at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
at System.Web.HttpApplication.PipelineStepManager.ResumeSteps(Exception error)
at System.Web.HttpApplication.BeginProcessRequestNotification(HttpContext context, AsyncCallback cb)
at System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context)
at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)
at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)
at System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr pHandler, RequestNotificationStatus& notificationStatus)
at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)
at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)

System.IdentityModel.Tokens.SecurityTokenException: ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer.

If you see this, it is likely one of two things:

1. The thumbprint for your trusted issuer is not capitalized.
2. You pasted the thumbprint from the certificates MMC plugin which added some invisible unicode characters to your thumbprint.

In both cases, type the thumbprint instead of pasting it and the error will go away.

In 2008, I changed jobs and started at a company that seemed to value TDD as much as I did. A new greenfield project was starting up, and everyone was tasked with learning the tools and trade of TDD. Sadly, I was not on this project. The team spent weeks, many weeks, downloading mocking frameworks and experimenting with other unit testing frameworks. They tried Moq, Rhino Mocks, Moles, TypeMock, and others. They tried NUnit, TypeMock, and MSTest. Without a TDD expert, the team spent way too much time trying to figure out the right way to test and lost track of the project’s goal… to write code to fulfill a contract. All unit testing was soon forbidden in the interest of time and money.

In my opinion, a single bad test is still better than no tests. Since that event I have tried to avoid using other frameworks and mocking libraries, etc. Sure it makes it easier, but only if you have the time to get up to speed on it and learn to love it. My primary goal on every piece of software I write is to one day be able to walk away and never get a phone call. If I lock a development team into using version 1.2.34.5678 of Crazy Mocks, they are going to 1) hate me 2) remove the test project 3) call me. I don’t want any of that to happen. I want easy-to-read code that looks like code that is versioned with the rest of the code and uses a built-in testing framework like MSTest.

So, what am I saying here and what does it have to do with MVC and fakes? I want to unit test all my code, and testing MVC HTML helpers is hard because there are lots and lots of MVC framework stuff going on that we don’t see. Simply calling your HTML helper’s methods without building the Controller, ControllerContext, HttpContext, ViewContext, ViewDataContainer, RouteData, and ViewEngine needed to support that call will give you mixed results. If your HTML helper is simple enough, you may never need to fake the view engine and context objects. If your helper is a container of built-in System.Web.Mvc.Html helpers, you are in for a tough battle. You will find many solutions to unit test HTML helpers that use Moq or Rhino Mocks. I find that developers generally accept unit tests as being worthy of the effort. They know the benefits and the costs, and try their best. When you get into a sticky situation as with MVC helpers, many give up and the code ends up having no unit tests.

A typical error message you will see is:

System.NotImplementedException – The method or operation is not implemented.

   at System.Web.HttpContextBase.get_Items()
   at System.Web.Mvc.Html.TemplateHelpers.GetActionCache(HtmlHelper html)
   at System.Web.Mvc.Html.TemplateHelpers.ExecuteTemplate(HtmlHelper html,
      ViewDataDictionary viewData, String templateName, DataBoundControlMode mode,
      GetViewNamesDelegate getViewNames, GetDefaultActionsDelegate getDefaultActions)
   at System.Web.Mvc.Html.TemplateHelpers.TemplateHelper(HtmlHelper html,
      ModelMetadata metadata, String htmlFieldName, String templateName,
      DataBoundControlMode mode, Object additionalViewData, ExecuteTemplateDelegate executeTemplate)
   at System.Web.Mvc.Html.TemplateHelpers.TemplateHelper(HtmlHelper html,
      ModelMetadata metadata, String htmlFieldName, String templateName,
      DataBoundControlMode mode, Object additionalViewData)
   at System.Web.Mvc.Html.TemplateHelpers.TemplateFor[TContainer,TValue](HtmlHelper`1 html,
      Expression`1 expression, String templateName, String htmlFieldName,
      DataBoundControlMode mode, Object additionalViewData, TemplateHelperDelegate templateHelper)
   at System.Web.Mvc.Html.TemplateHelpers.TemplateFor[TContainer,TValue](HtmlHelper`1 html,
      Expression`1 expression, String templateName, String htmlFieldName, DataBoundControlMode mode,
      Object additionalViewData)
   at System.Web.Mvc.Html.DisplayExtensions.DisplayFor[TModel,TValue](HtmlHelper`1 html,
      Expression`1 expression)
   at Utils.Web.Tests.DisplayFormRowHelperTest.DisplayFormRow_StringField()
   in C:\Dev\MvcUnitTesting\Utils.Web.Tests\DisplayFormRowHelperTest.cs:line 99

The ActionCacheItems are stored as a dictionary in the HttpContext.Items. If you have successfully used Moq and NSubstitute correctly and mocked away a good part of the framework, you may still see this error because the HttpContext hasn’t been built up correctly.

What can you do? Find or write some fakes. Then create your HTML helper with a method that builds up the view engine and context objects as seen in the code below:

using System.Web.Mvc;
using System.Web.Routing;
using UnitTesting.Web.Mvc;

namespace Utils.Web.Tests
{
	public class HtmlHelperBuilder
	{
		public static HtmlHelper<TModel> GetHtmlHelper<TModel>(TModel model, bool clientValidationEnabled)
		{
			ViewEngines.Engines.Clear();
			ViewEngines.Engines.Add(new FakeViewEngine());

			var controller = new MyTestController();
			var httpContext = new FakeHttpContext();

			var viewData = new FakeViewDataContainer { ViewData = new ViewDataDictionary<TModel>(model) };

			var routeData = new RouteData();
			routeData.Values["controller"] = "home";
			routeData.Values["action"] = "index";

			ControllerContext controllerContext = new FakeControllerContext(controller);

			var viewContext = new FakeViewContext(controllerContext, "MyView", routeData);
			viewContext.HttpContext = httpContext;
			viewContext.ClientValidationEnabled = clientValidationEnabled;
			viewContext.UnobtrusiveJavaScriptEnabled = clientValidationEnabled;
			viewContext.FormContext = new FakeFormContext();

			HtmlHelper<TModel> htmlHelper = new HtmlHelper<TModel>(viewContext, viewData);
			return htmlHelper;
		}
	}
}

Then your unit tests will work, and not look so obnoxious. If you compare the code below, dear blog reader with a head on your shoulders, to the Moq solutions out there, you will notice two things. 1) This looks like a lot of code, but it’s still less than Moq 2) You, and a lot of other people, can actually read this code. Moq is great, but not for most developer’s consumption.

[TestMethod]
public void DisplayFormRow_StringField()
{
	// Arrange
	var model = new MyModel { MyString = "Test" };
	string expected = "Test";
	HtmlHelper<MyModel> html = HtmlHelperBuilder.GetHtmlHelper(model, true);

	// Act
	MvcHtmlString actual = html.DisplayFor(m => m.MyString);

	// Assert
	Assert.AreEqual(expected, actual.ToHtmlString());
}

This should be enough fake action to get someone going down the right path. Feel free to use the fakes library I have linked below. No guarantees. IWOMB

Code hard!
Test lightly!

Links:

• Building Testable ASP.NET MVC Applications
  (Justin Etheredge – MSDN Magazine – July 2009)

Download library of fakes – UnitTesting.Web.Mvc.zip (8.42 KB)

Warning 304 The version of the .NET Framework launch condition ‘.NET Framework 4 Client Profile’ does not match the selected .NET Framework bootstrapper package. Update the .NET Framework launch condition to match the version of the .NET Framework selected in the Prerequisites Dialog Box.

 While building a Setup project, which hosts a Windows Service that requires the full .NET Framework 4 profile, this warning message appears. I do not accept warnings or error messages in my code, so naturally I must seek and destroy the cause of this message. Before you do the following, make sure that the client profile selected matches between your project properties and the .NET framework profile on the prerequisites screen from the setup project’s properties screen.

After the setup project’s prerequisites match your project’s client profile, change the profile for your setup project’s installer Launch Conditions.

1. Right-click on the setup project, select View and then Launch Conditions.
2. Click on .NET Framework under Launch Conditions.
3. Change the Version in the properties window to match the client profile selected in the project properties and setup project prerequisites.

Launch Conditions Settings in Visual Studio

Download ParallelPresentation.zip – 1.21 MB (1,276,111 bytes)

http://channel9.msdn.com/Shows/Going+Deep/Stephen-Toub-Task-Based-Asynchrony-with-Async

Thank you, Microsoft, for working to make our lives better.

1. Client creates workflow instance with WCF message
2. Workflow (service) responds indicating that the workflow instance is running
3. At some point in the future, client wants to resume the same, now waiting, workflow instance with another WCF message

To implement the resumption of the same workflow instance requires that the client have some sort of identifier to get back to the same instance they left earlier. WF4 uses CorrelationHandles to accomplish this. Using the CorrelationHandle class and some send/receive message properties, clients can share some unique ID to get back to the same instance. From a calling client’s perspective, the same scenario as before with correlation looks like this:

1. Client creates workflow instance with WCF message
2. Workflow creates a correlation handle on some unique ID
3. Workflow (service) responds with the unique ID, for later correlation use, also indicating that the workflow instance is running
4. At some point in the future, client wants to resume the same, now waiting, workflow instance with another WCF message
5. Client sends another WCF message, including the unique ID in the message
6. Workflow responds to the incoming message, reads the unique ID from the message, and looks up the correct instance by the correlation handle corresponding to that unique ID
7. The same instance created earlier resumes

You may be asking yourself, “So how do I do all this correlation stuff?” The following procedure will detail the necessary steps. The download link at the bottom of this post contains a sample project that has this sample already implemented.

Procedure:

1. Start with a workflow with two separate ReceiveAndSendReply sequences.
2. If a unique ID is not available for correlation in your workflow already, you can use the WorkflowInstanceId. Put the following code in a new activity, and add the activity between the Receive and SendReply activities in your workflow.

   public sealed class GetWorkflowInstanceId : CodeActivity
   {
       public OutArgument<Guid> WorkflowInstanceId { get; set; }
   
       protected override void Execute(CodeActivityContext context)
       {
           context.SetValue<Guid>(this.WorkflowInstanceId, context.WorkflowInstanceId);
       }
   }

3. Create a new variable named WorkflowInstanceId of type System.Guid.
4. Create a new variable named WorkflowInstanceCorrelationHandle of type CorrelationHandle.
5. Set the WorkflowInstanceId out argument on the GetWorkflowInstanceId activity to the newly created variable WorkflowInstanceId.
6. Modify the SendReply activity Content to include the WorkflowInstanceId guid. This will give the client the unique ID to use in subsequent messages.
7. Open the SendReply activity CorrelationInitializers with the ellipsis button.
8. Click Add initializer in the left pane of the Add Correlation Initializers window. Type the name of the newly created variable WorkflowInstanceCorrectionHandle.
9. Verify that Query correlation initializer is selected in the combo box. Double-click to add a key under XPath Queries. Choose the WorkflowInstanceId item from the outbound message/parameters. In the attached example, this appears after the double-click as “Content : Guid” and appears as “sm:body()/xg0:guid” as an XPath query.
   
10. Click OK to close the Add Correlation Initializers window.
11. For the subsequent Receive activities, modify the Content to include the WorkflowInstanceId guid as either a message or parameter. This will make it possible to lookup the correct workflow instance.
12. On the same Receive activities, open CorrelatesOn with the ellipsis button.
13. Type the name of the variable WorkflowInstanceCorrelationHandle in the CorrelatesWith field.
14. Double-click to add a key under XPath Queries. Choose the WorkflowInstanceId item from the outbound message/parameters. In the attached example, this appears after the double-click as “Content : Guid” and appears as “sm:body()/xg0:guid” as an XPath query.
    
15. Test the interaction by creating a test client (included in the download below) that creates 2 or more instances and resumes them in a different order.
16. The final workflow should look like the image to the right.

Download WfCorrelation.zip – 25.1 KB (25,727 bytes)
(Build the solution before opening the workflow to avoid activity errors)

Download WebMatrix.zip – 969 KB (992,595 bytes)

Download ParallelPresentation.zip – 1.21 MB (1,276,111 bytes)