Adventures in Enterprise Software Development https://docs.microsoft.com/archive/blogs/nkpatterson/feed.xml Wed, 17 Apr 2019 03:51:53 GMT en-US hourly 1 Managing Developer VMs in Azure with a Chocolatey Twist https://docs.microsoft.com/archive/blogs/nkpatterson/managing-developer-vms-in-azure-with-a-chocolatey-twist Mon, 26 Jan 2015 06:07:00 GMT https://blogs.msdn.microsoft.com/nkpatterson/2015/01/26/managing-developer-vms-in-azure-with-a-chocolatey-twist/ Overview

Imagine you're in charge of managing your development team's workstation infrastructure. Let's say you have 20 developers and they all have their own physical workstation. Those workstations might have started life from a common sys-prepped image with a standard set of developer-related tools installed on them (Visual Studio, SQL Server, Fiddler, etc.). Oftentimes, there will also be a Software or Tools file share somewhere out on the network where the devs can manually install whatever else they need. But, over time, new software and tools are released and your devs want to use them. Your baseline workstation image is out-of-date the day after you build it and it's tedious and time-consuming to maintain. Keeping up the Software share with the latest/greatest toolset is a full-time job by itself. On top of that, your team is growing fast and it's getting really expensive to procure new workstations so your CTO is moving your development to the cloud. Well, it's your lucky day my friend because the cloud affords us many opportunities that we didn't have before. The combination of 3 cool technologies- Azure PowerShell, Windows PowerShell Desired State Configuration (DSC) and Chocolatey- will make managing your development environment in the cloud trivial. 

If you're not already familiar, Chocolatey is a machine package manager, similar to apt-get, but built for Windows. This enables you to install many common dev/test/ops tools with a simple command. Need Visual Studio 2013 Ultimate? Simple:

PS: \> choco install visualstudio2013ultimate

BAM! Done. Say goodbye to that pesky Software share that you have to maintain. But what about the common list of software you need installed on all the new VMs? And what if I want to push new tools out to my existing VMs? That's where Azure PowerShell and DSC comes in. Azure PowerShell is a set of cmdlets designed to make scripting out your cloud environment dead simple while DSC is a technology that is used to automatically configure a machine with a desired state (think Windows Roles/Features, directory structures, security settings, etc.)

In this post, I will show you how to use these three technologies together to make your life easy.

Install the latest Azure PowerShell SDK

First things first. If you haven't already installed or used Azure PowerShell before, follow these steps to get started: How to install and configure Azure PowerShell. These tools are AMAZING, very simple to use and absolutely essential when talking about automating/standardizing your cloud environment.

Download and install the cChoco DSC Resource

The real magic of this particular scenario is how we can extend DSC to include Chocolatey natively in the process. I (foolishly) started writing my own custom DSC resource to wrap Chocolatey but when I ran into several issues, I Googled it with Bing and quickly realized that, like every other "original" idea I've ever had, someone from the community had already beat me to it :) cChoco is one of several projects hosted up on GitHub in the PowerShell.org repository and it makes using Chocolatey with DSC a breeze. Here's how to download and install:

  1. Download cChoco from the following location: https://github.com/PowerShellOrg/cChoco 
  2. Extract the downloaded zip to the following path on your workstation: C:\Program Files\WindowsPowerShell\Modules
That's it! You will then be able to import and leverage cChoco from your custom DSC configuration file which you'll now create.

Create your custom DSC configuration file with Chocolatey packages

There are several out of the box DSC resources that you can take advantage of. For example, you could use the WindowsFeature resource to install IIS on all of your development workstations. Here is a list of all of the built-in DSC resources. For this example, however, we'll just stick to using Chocolatey to install some common dev tools. Here's what our DSC file looks like:

https://gist.github.com/nkpatterson/ec1cd1c17ae27b11944a

This looks like a pretty typical DSC file. The cChocoInstaller performs the initial installation of Chocolatey on the machine (if it's not already there). The 3 cChocoPackageInstaller sections specify which packages to install. You have the complete list of Chocolatey packages at your fingertips but in this case I'm just installing Google Chrome, Fiddler and Visual Studio 2013 Ultimate. The Name attribute in the DSC file corresponds to the package name. Remember where you save your DSC file, you will be referencing it in the next step.

Use the DSC PowerShell cmdlets to publish your package

Once you've got your DSC file just the way you like it, you will need to package it up and push it to the cloud so it can be referenced while Azure is configuring your VMs. This is made easy with the Publish-AzureVMDSCConfiguration cmdlet.  You just need to obtain a reference to your Azure storage account, point it at your DSC file and the command does the rest.

https://gist.github.com/nkpatterson/5d532bd6fe9bed02a9ed#file-publish-ps1

Now, if you go to the Azure Portal and browse to your storage account and click over to the Containers tab, you will see your DSC file sitting up in the cloud ready for the next step.

Provision a new Developer VM using your new DSC package

Using the Set-AzureVMDSCExtension cmdlet, we can create new virtual machines with our DSC package. I went ahead and wrote a simple script that encapsulates all of the necessary steps, taking in a few parameters such as your storage account name, the local path to the DSC file, the desired names of the virtual machines, etc. to make provisioning one or more VMs really easy.

https://gist.github.com/nkpatterson/ce00ede9a03777aa1578#file-provision-ps1

With this script in hand, you can easily create 3 new developer VMs in a matter of minutes:

PS: \>.\Provision.ps1 -StorageAccountName "MyAccountName" -DscConfigurationPath "DSC.ps1" -DscConfigurationName "DevWorkstation" `
 
 -ServiceName "DevWorkstations" -VmNames @("devvm01", "devvm02", "devvm03") -AdminUsername "Admin" -AdminPassword "SomethingMoreSecureThanThis"

A few things like the VM image and size are hard-coded in there but hopefully you get the point. After the script runs, you'll see this in the management portal:

And once the VMs are started and running, you can log in using the credentials you entered and verify that the software you had specified in your Chocolatey DSC file are, in fact, there. Cool!


Update an existing Developer VM with new Chocolatey packages

This is all well and good and helpful in getting your development environment stood up quickly. The REAL power, however, comes when you want to make a change to your workstation baseline. For example, what if after provisioning 20 of these developer VMs I want to install an awesome new tool that I found on all of them? If you were using a custom VM image, you would need to download the image VHD, start it up, install the new software, sysprep it and then upload it back into Azure, yada yada. This only covers new VMs going forward and does nothing for you regarding the 20 VMs you already have. You would have to manually install the software on each of those. With DSC and Chocolatey, this tedious maintenance scenario becomes a simple matter of updating your DSC file with the new Chocolatey packages you wish to install and leveraging the same PowerShell cmdlets we were using to provision new VMs to update the existing ones. Here's a script I threw together to do just that:

https://gist.github.com/nkpatterson/2292baa29bcf0820a8a7#file-updatevms-ps1

After adding the cool new package to our local DSC file you can call the Provision.ps1 script again with just the minimal parameters to get the DSC file uploaded to storage.

PS: \>.\Provision.ps1 -StorageAccountName "MyAccountName" -DscConfigurationPath ".\DSC.ps1"

That will overwrite the existing DSC file in your storage container and make it ready for the next call to UpdateVMs.ps1:

PS: \>.\UpdateVMs.ps1 -StorageAccountName "MyAccountName" -DscConfigurationFileName "DSC.ps1.zip" -DscConfigurationName "DevWorkstation" -ServiceName "DevWorkstations" -VmNames @("devvm01", "devvm02", "devvm03")

And in just a few minutes, all of your VMs will be updated with the new software!

Scripts.zip

]]> A Re-Usable NHibernate Paging Extension Method https://docs.microsoft.com/archive/blogs/nkpatterson/a-re-usable-nhibernate-paging-extension-method Fri, 29 Jun 2012 10:44:04 GMT https://blogs.msdn.microsoft.com/nkpatterson/2012/06/29/a-re-usable-nhibernate-paging-extension-method/ Every developer knows that they should always try to avoid returning an unbounded result set from the database, right?  Of course they do.  The obvious solution to this problem is to page through the results in smaller chunks that the database (and most likely the end-user) can handle efficiently.  I didn’t want to have to reinvent the wheel for every query I wrote so I wrapped the necessary NHibernate logic up in a nice, tidy extension method.

Side note: NHibernate Profiler is an indispensible tool for optimizing your NHibernate code.  I couldn’t live without it, nor would I want to.  And no I don’t receive kickbacks from Ayende.

Of course, in order to make this truly useful, I needed a custom collection that could keep track of the various paging settings like the current page index, the total number of records in the database, how many records are returned for each page, etc.  For this, I blatantly stole borrowed the PagedList<T> code from Rob Conery and ScottGu.  I also later found a great project on github by Troy Goode that is basically the same but with some supporting unit tests and optimizations.  Either way, here is teh codez that I use.

PagedList.cs – contains an interface and a default implementation of a generic PagedList<T>.  It also has a helper extension method so you can quickly turn any IEnumberable<T> into a PagedList<T>.

PagedList.cs

  1. public interface IPagedList
  2. {
  3.     long TotalCount { get; set; }
  4.     int TotalPages { get; set; }
  5.     int PageIndex { get; set; }
  6.     int PageSize { get; set; }
  7.     int FirstItem { get; }
  8.     int LastItem { get; }
  9.     bool HasPreviousPage { get; }
  10.     bool HasNextPage { get; }
  11. }
  12.  
  13. [Serializable]
  14. public class PagedList<T> : IPagedList
  15. {
  16.     public List<T> Items { get; private set; }
  17.     public int TotalPages { get; set; }
  18.     public long TotalCount { get; set; }
  19.     public int PageIndex { get; set; }
  20.     public int PageSize { get; set; }
  21.  
  22.     public PagedList()
  23.     {
  24.         Items = new List<T>();
  25.     }
  26.  
  27.     public PagedList(IEnumerable<T> source, long totalCount, int pageIndex, int pageSize)
  28.     {
  29.         PageSize = pageSize;
  30.         PageIndex = pageIndex;
  31.         TotalCount = totalCount;
  32.         TotalPages = (int)(TotalCount / pageSize);
  33.  
  34.         if (TotalCount % pageSize > 0)
  35.             TotalPages++;
  36.  
  37.         Items = new List<T>(source);
  38.     }
  39.  
  40.     public bool HasPreviousPage
  41.     {
  42.         get { return (PageIndex > 0); }
  43.     }
  44.  
  45.     public bool HasNextPage
  46.     {
  47.         get { return PageIndex < TotalPages - 1; }
  48.     }
  49.  
  50.     public int FirstItem
  51.     {
  52.         get
  53.         {
  54.             return (PageIndex * PageSize) + 1;
  55.         }
  56.     }
  57.  
  58.     public int LastItem
  59.     {
  60.         get { return FirstItem + PageSize - 1; }
  61.     }
  62. }
  63.  
  64. public static class Pagination
  65. {
  66.     public static PagedList<T> ToPagedList<T>(this IEnumerable<T> source, int totalCount, int pageIndex, int pageSize)
  67.     {
  68.         return new PagedList<T>(source, totalCount, pageIndex, pageSize);
  69.     }
  70. }

NHibernateExtensions.cs – this is where the NHibernate goodness comes in.  This warrants a little explanation but take a look first and see if you can see what’s going on.

NHibernateExtensions.cs

  1. public static class NHibernateExtensions
  2. {
  3.     public static PagedList<T> PagedList<T>(this ICriteria criteria, ISession session, int pageIndex, int pageSize) where T: class
  4.     {
  5.         if (pageIndex < 0)
  6.             pageIndex = 0;
  7.  
  8.         var countCrit = (ICriteria)criteria.Clone();
  9.         countCrit.ClearOrders(); // so we don't have missing group by exceptions
  10.  
  11.         var results = session.CreateMultiCriteria()
  12.             .Add<long>(countCrit.SetProjection(Projections.RowCountInt64()))
  13.             .Add<T>(criteria.SetFirstResult(pageIndex * pageSize).SetMaxResults(pageSize))
  14.             .List();
  15.  
  16.         var totalCount = ((IList<long>)results[0])[0];
  17.  
  18.         return new PagedList<T>((IList<T>)results[1], totalCount, pageIndex, pageSize);
  19.     }
  20. }

First of all, this method is an extension of NHibernate’s ICriteria class so it obviously requires you to be using NHibernate’s Criteria API.  This type of thing would be much more difficult using the HQL syntax.

Essentially what we want to do is leverage NHibernate’s multi-criteria feature to send two different SQL statements to the server at the same time.  One to retrieve the total record count of the query and two to get the actual results of that query, limited to the page size and page index that we specify.  That’s why we Clone the original criteria that is passed into the method.  This will be what is used to get the total record count for the query.  We call the ClearOrders method on this instance of the ICriteria because: 1) we don’t care about how the query is ordered if we’re just getting the total row count; and 2) the order statements can cause problems if there are groupings in the criteria. Trust me on this.

We then create the multi-criteria object on line 11 and add the total row count criteria that we cloned and the original criteria passed in but we use the SetFirstResult and SetMaxResults methods to limit the number of records returned.

Finally, we retrieve the values from the two result sets.  The first being the total row count.  The second, the actual results of the query and return the results using our fancy new PagedList<T> class.

The usage of this extension method couldn’t be simpler.

Code Snippet

  1. public PagedList<Order> GetCompletedOrders(int pageIndex, int pageSize)
  2. {
  3.     // _currentSession is an instance of ISession, instantiation not shown
  4.     return _currentSession.CreateCriteria<Order>()
  5.         .Add(Expression.Eq("Status", (int)OrderStatus.Complete))
  6.         .AddOrder(Order.Desc("OrderCompletedDate"))
  7.         .PagedList<Order>(_currentSession, pageIndex, pageSize);
  8. }

As a bonus, I’m going to post some code that I use in my ASP.NET MVC projects that allows you generate a Pager control complete with customizable, CSS classes, next/previous text customizations, AJAX support, etc. from our PagedList<T> class in ONE LINE OF CODE.  Stay tuned…

Update: here’s the post on those ASP.NET MVC Pager helper classes I mentioned.

]]> Multiple AND/OR Statements with NHibernate https://docs.microsoft.com/archive/blogs/nkpatterson/multiple-andor-statements-with-nhibernate Fri, 29 Jun 2012 10:42:44 GMT https://blogs.msdn.microsoft.com/nkpatterson/2012/06/29/multiple-andor-statements-with-nhibernate/ I’m sure you’ve encountered the scenario where you need to add multiple AND or OR statements to an NHibernate query.  The string parsing and manipulation required to do it in HQL would be enough to send you straight to programmer hell.  So it turns out the easiest (in my opinion) option is to use the good ol’ Criteria API.  But it’s not as obvious as it first seems.  In order to accomplish the task, you actually need to use a pair of constructs that may be new to you: Conjunction which represents a grouping of AND statements (A and B and C…); and Disjunction, a grouping of OR statements (A or B or C…).  Here’s an admittedly contrived example of how you could query for Persons by FirstName that are not archived (IsArchived), ordering by FirstName:

Contrived Disjunction Example

  1. string[] namesToCheck = { "Nick", "Dave", "Bryan", "James" };
  2. using (ISession session = SessionManager.CreateSession())
  3. {
  4.     var criteria = session.CreateCriteria<Person>();
  5.     var disjunction = Restrictions.Disjunction();
  6.  
  7.     criteria.Add(Expression.Eq("IsArchived", false));
  8.  
  9.     foreach (var name in namesToCheck)
  10.     {
  11.         disjunction.Add(Restrictions.Eq("FirstName", name));
  12.     }
  13.  
  14.     criteria.Add(disjunction);
  15.     criteria.AddOrder(Order.Asc("FirstName"));
  16.  
  17.     return criteria.List<Person>();
  18. }

This would generate something similar to the following SQL-statement:

Disjunction SQL Results

  1. SELECT * FROM Person
  2. WHERE IsArchived = 0 AND
  3.     (FirstName = "Nick" OR
  4.     FirstName = "Dave" OR
  5.     FirstName = "Bryan" OR
  6.     FirstName = "James")
  7. ORDER BY FirstName

If you needed ANDs instead of ORs you would use Conjunction instead of Disjunction.

A more powerful example would be if you needed multiple sets of statements.  Consider the following scenario:

Select all Persons where IsArchived is false and the FirstName is “Nick”, or all Persons where IsArchived is true and the FirstName is “Bryan”

Here’s how you would do it using Conjunctions and Disjunctions:

Less Contrived Example

  1. using (ISession session = SessionManager.CreateSession())
  2. {
  3.     var criteria = session.CreateCriteria<Person>()
  4.         .AddOrder(Order.Asc("FirstName"));
  5.  
  6.     // IsArchived is FALSE and FirstName = "Nick"
  7.     var conjunction1 = Restrictions.Conjunction();
  8.     conjunction1.Add(Restrictions.Eq("IsArchived", false));
  9.     conjunction1.Add(Restrictions.Eq("FirstName", "Nick"));
  10.  
  11.     // IsArchived is TRUE and FirstName = "Bryan"
  12.     var conjunction2 = Restrictions.Conjunction();
  13.     conjunction2.Add(Restrictions.Eq("IsArchived", true));
  14.     conjunction2.Add(Restrictions.Eq("FirstName", "Bryan"));
  15.  
  16.     // This combines the two statements into an OR
  17.     var disjunction = Restrictions.Disjunction();
  18.     disjunction.Add(conjunction1);
  19.     disjunction.Add(conjunction2);
  20.  
  21.     criteria.Add(disjunction);
  22.  
  23.     return criteria.List<Person>();
  24. }

Which would produce the following:

SQL Results

  1. SELECT * FROM Person
  2. WHERE
  3.     (IsArchived = 0 AND FirstName = "Nick") OR
  4.     (IsArchived = 1 AND FirstName = "Bryan")
  5. ORDER BY FirstName
]]> Integrating StructureMap, Unit of Work and WCF https://docs.microsoft.com/archive/blogs/nkpatterson/integrating-structuremap-unit-of-work-and-wcf Sat, 19 Nov 2011 07:30:00 GMT https://blogs.msdn.microsoft.com/nkpatterson/2011/11/19/integrating-structuremap-unit-of-work-and-wcf/ When I initially set off on using StructureMap as my IoC of choice on a recent ASP.NET MVC/WCF project, I didn’t realize how deep the rabbit hole actually was.  Oh, the MVC part was easy.  StructureMap integration in an MVC application has been demonstrated a thousand times over and is made even easier with the latest release of ASP.NET MVC 3 and NuGet.  Getting StructureMap to serve up objects in a WCF application, now THAT’S a horse of a different color.

Standing on Someone Else’s Shoulders

Two blog posts helped me tremendously when attempting this:

I highly recommend reading both posts first, in that order.

Service Request/Response

Before going any further, I need to take a moment to define the pattern I was using on the project for calling the WCF service layer.  For each service operation I defined two data contracts: [OperationName]Request; and [OperationName]Response.  Both of these classes are decorated with the DataContract attribute and encapsulated the parameters in both the request and response to the service.  This allows the values that are passed into and returned from the service to change without breaking the service contract.  Much more flexible, IMHO.  Here’s an example.

IInventoryService

  1. [ServiceContract]
  2. public interface IInventoryService
  3. {
  4.     [OperationContract]
  5.     public CreateProductResponse CreateProduct(CreateProductRequest request);
  6. }

CreateProductRequest

  1. [DataContract]
  2. public class CreateProductRequest
  3. {
  4.     [DataMember]
  5.     public string Name { get; set; }
  7.     [DataMember]
  8.     public decimal Price { get; set; }
  9. }

CreateProductResponse

  1. [DataContract]
  2. public class CreateProductResponse
  3. {
  4.     [DataMember]
  5.     public int NewProductId { get; set; }
  6. }

Taking it a Step Further

Andreas’ example would rollback the transaction if an unhandled exception was thrown in the WCF application.  This is all well and good but I didn’t like the idea of throwing exceptions from my service layer.  I thought a much cleaner approach would be to return one or more OperationResult objects in the service response object if a problem occurred.  An OperationResult would basically just consist of a Key/Message pair that identifies exactly what or where something went wrong (in the Key) as well as details of the error (in the Message).  In most cases, this could represent validation errors bubbled up from the domain model.  The Key would be the property name that was invalid and the Message would contain, well, the error message of the validation error (e.g., “Email address is in the wrong format”).  But this could also include other, more generic, errors as well.

OperationResult

  1. [Serializable]
  2. public class OperationResult
  3. {
  4.     public string Key { get; set; }
  5.     public string Message { get; set; }
  6. }

I decided to create a base class that contained a collection of OperationResult objects so that I wouldn’t have to reinvent the wheel for every Response object I created.  It looks like this:

OperationResultResponse

  1. public interface IOperationResultResponse
  2. {
  3.     public void AddResult(string key, string message);
  4.     public IList<OperationResult> Results { get; set; }
  5. }
  7. [DataContract]
  8. public class OperationResultResponse : IOperationResultResponse
  9. {
  10.     private void initResults()
  11.     {
  12.         this.Results = new List<OperationResult>();
  13.     }
  15.     public IList<OperationResult> Results { get; set; }
  17.     public void AddResult(string key, string message)
  18.     {
  19.         if (this.Results == null)
  20.             initResults();
  22.         this.Results.Add(new OperationResult { Key = key, Message = message });
  23.     }
  25.     public OperationResultResponse()
  26.     {
  27.         initResults();
  28.     }
  29. }

And then, for all (or some, if not applicable) of your response simply inherit from the OperationResultResponse base class.

Inherit from response base

  1. [DataContract]
  2. public class CreateProductResponse : OperationResultResponse
  3. {
  4.     [DataMember]
  5.     public int NewProductId { get; set; }
  6. }

Where the Magic Happens

OK, that was a lot of lead up to the big reveal.  How do we take this service request/response object model and use it to rollback our Unit of Work (and consequently our NHibernate session transaction)?  I got one, err, two, ish words for you: IParameterInspector.  This is another one of WCF’s many extensibility points and, like IDispatchMessageInspector, it allows you to perform work when a request is received and before a response is sent.  In our case, we want to perform the following steps before each response is sent:

  1. Get a reference to the Unit of Work for the current request
  2. Check the response object type and see if it implements IOperationResultResponse
  3. If the response object DOES implement IOperationResultResponse, interrogate the Results property to see if there are any errors contained therein
  4. If there ARE errors in the Results property, rollback the Unit of Work by calling Rollback()
  5. If none of the above applies, call Commit() and Dispose() on the UoW before sending the response on its way

Here’s what our IParameterInspector implementation looks like:

Custom IParameterInspector

  1. public class OperationResultParameterInspector : IParameterInspector
  2. {
  3.     private IContainer _container;
  5.     public OperationResultParameterInspector(IContainer container)
  6.     {
  7.         _container = container;
  8.     }
  10.     public void AfterCall(string operationName, object[] outputs, object returnValue, object correlationState)
  11.     {
  12.         // Step 1: Get UoW
  13.         var uow = _container.GetInstance<IUnitOfWork>();
  15.         // Step 2: Check for IOperationResult
  16.         var opResultResponse = returnValue as IOperationResultResponse;
  17.         if (opResultResponse != null)
  18.         {
  19.             // Step 3: Interrogate Results for errors
  20.             if (opResultResponse.Results.Count > 0)
  21.             {
  22.                 // Step 4: Rollback our UoW before sending response
  23.                 uow.Rollback();
  24.             }
  25.         }
  26.         else
  27.         {
  28.             // Step 5: If we're still here, commit and dispose
  29.             uow.Commit();
  30.         }
  32.         uow.Dispose();
  33.     }
  35.     public object BeforeCall(string operationName, object[] inputs)
  36.     {
  37.         // No implementation
  38.         return null;
  39.     }
  40. }

Why We Can’t Use BeforeSendReply

We’re still going to reuse the Andreas’ UnitOfWorkMessageInspector to create and initialize the Unit of Work in the AfterReceiveRequest but instead of committing and disposing of the UoW in the BeforeSendReply method, we’re going to rely on our parameter inspector’s AfterCall method to do the work.  The reason we’re not performing the above logic in the BeforeSendReply method of IDispatchMessageInspector is because BeforeSendReply happens AFTER the response has been serialized into a Message object, making it much more difficult to interrogate the values.  Believe me, I tried.  AfterCall of IParameterInspector is invoked BEFORE the return value has been serialized into a Message object so you can easily just cast the return value to our IOperationResultResponse interface. 

Wiring It All Up

Wiring up our IParameterInspector is just like wiring up the IDispatchMessageInspectors, IErrorHandlers, etc.  Iterate through each EndPoint, get the list of IParameterInspectors  (you may have more than one!) from StructureMap and append them to each DispatchOperation.  Here’s what our updated StructureMapServiceBehavior class looks like.  I’ve omitted the other details for brevity.

StructureMapServiceBehavior

  1. public class StructureMapServiceBehavior : IServiceBehavior
  2. {
  3.     private IContainer _container;
  5.     public StructureMapServiceBehavior(IContainer container)
  6.     {
  7.         _container = container;
  8.     }
  10.     public void Validate(ServiceDescription serviceDescription,
  11.         ServiceHostBase serviceHostBase) { /* No implementation */ }
  12.     public void AddBindingParameters(ServiceDescription serviceDescription,
  13.         ServiceHostBase serviceHostBase, Collection<ServiceEndpoint> endpoints,
  14.         BindingParameterCollection bindingParameters) { /* No implementation */ }
  16.     public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
  17.     {
  18.         foreach (ChannelDispatcherBase cdb in serviceHostBase.ChannelDispatchers)
  19.         {
  20.             var cd = cdb as ChannelDispatcher;
  21.             if (cd != null)
  22.             {
  23.                 foreach (EndpointDispatcher ed in cd.Endpoints)
  24.                 {
  25.                     // Not shown: Add InstanceContextInitializers, IDispatchMessageInspectors, ICallContextInitializers, etc.
  27.                     foreach (DispatchOperation op in ed.DispatchRuntime.Operations)
  28.                     {
  29.                         // Add custom IParameterInspectors
  30.                         foreach (var pi in _container.GetAllInstances<IParameterInspector>())
  31.                         {
  32.                             op.ParameterInspectors.Add(pi);
  33.                         }
  34.                     }
  35.                 }
  36.             }
  38.             // Not shown: Add IErrorHandlers
  39.         }
  40.     }
  41. }

And of course, we add the mapping between IParameterInspector and our custom OperationResultParameterInspector in the traditional StructureMap way:

ServicesRegistry

  1. public class ServicesRegistry : StructureMap.Configuration.DSL.Registry
  2. {
  3.     public ServicesRegistry()
  4.     {
  5.         // Not shown: wiring up all other WCF extensions
  6.         For<IParameterInspector>().Add<OperationResultParameterInspector>();
  7.     }
  8. }

Conclusion

This really turned into an exercise in learning the various WCF extension points, what you can and cannot do at each, etc.  We’ve learned though that the best place for inspecting the actual service response objects before they’re sent across the wire is in the AfterCall method of the IParameterInspector interface.

]]>