Elton Stoneman

Mapping and Auto-Mapping Objects from IDataReader

Elton Stoneman — Wed, 04 Jan 2012 21:23:16 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

This is one in a series of posts covering my generic mapping library on github: Sixeyed.Mapping.

1. Mapping and Auto-Mapping Objects

2. Mapping and Auto-Mapping Objects from IDataReader

3. Mapping and Auto-Mapping Objects from XML

4. Mapping and Auto-Mapping Objects from CSV

5. Comparing Sixeyed.Mapping to AutoMapper

The mapping library has support for IDataReader objects used as the source. Using data readers, AutoMap will try to populate the target by matching property names to column names. Alternatively a static map can be defined, manually specifying the mapping between column names and properties.

Auto-Mapping

Using a populated data reader as a source, you can auto-map a target object using the DataReaderAutoMap and the same syntax as for an object source:

IDataReader reader = GetReader(id);

User user = DataReaderAutoMap<User>.CreateTarget(reader);

The data reader must be open, and the map will populate from the current row so the data reader should be read to the desired start position before mapping. For a single row, call Read() once on the reader before passing it to the Create() call.

DataReaderAutoMap and AutoMap share the same base class, and the mapping logic is the same for all sources. Specification, caching strategy and naming strategy options still apply. To specify a property mapping, you need to provide the name of the source column:

var addressMap = new DataReaderAutoMap<Address>()

.Specify("PostCode", t => t.PostCode.Code);

//or:

var addressMap = new DataReaderAutoMap<Address>()

.Specify((s, t) => t.PostCode.Code = (string)s["PostCode"]);

You can also use the conversion overloads for converting the source value during population:

var map = new DataReaderAutoMap<User>()

.Specify<DateTime, DateTime>("JoinedDate", t => t.JoinedDate, sd =>FromLegacyDate(sd));

Static Mapping

For static maps, extend the base DataReaderMap class. As we’re dealing with string constants for the column names, static maps may be the better option in caseswhere the source and target names can’t be matched by convention – they centralise the constant definition in one place:

public class FullUserFromDataReaderMap : DataReaderMap<User>

{

/// <summary>

/// Default constructor, initialises mapping

/// </summary>

public FullUserFromDataReaderMap()

{

this.AutoMapUnspecifiedTargets = false;

Specify(ColumnName.Id, t => t.Id);

Specify(ColumnName.FirstName, t => t.FirstName);

//etc.

}

private struct ColumnName

{

public const string Id = "UserId";

public const string FirstName = "FirstName";

//etc.

}

Nested Maps

Maps can include nested maps, populating an object graph from a flattened representation in a single data reader:

var addressMap = new DataReaderAutoMap<Address>()

.Specify("PostCode", t => t.PostCode.Code);

var map = newDataReaderAutoMap<User>()

.Specify("UserId", t => t.Id)

.Specify((s, t) => t.Address = addressMap.Create(s));

var user = map.Create(reader);

Nested maps can also populate objects from multiple readers – although this requires each reader to be associated with a separate connection:

var addressMap = new DataReaderAutoMap<Address>()

.Specify((s, t) => t.PostCode.Code = (string)s["PostCode"]);

var map = new DataReaderAutoMap<User>()

.Specify("UserId", t => t.Id)

.Specify((s, t) => t.Address = addressMap.Create(addressReader));

var user = map.Create(userReader);

Limitations

Data reader maps can only operate in one direction – populating an object from a reader. They also rely on the column names being available in the IDataReader implementation through the GetOrdinal method. Not all data providers supply this, and if there are no column names available, mapping will fail for auto-maps and static maps, leaving the target object unpopulated.

Performance

Mapping from data readers uses the column names of the source, so only the target is reflected over. For small numbers of reads, there is less of a performance impact than with object-to-object mapping, and the benefits are greater as mapping also takes care of type conversion. Using a SqlServerCe database populated with 250,000 rows (80+Mb of data), the performance was bounded by the speed of the database connection and not the speed of mapping. Up to 1,000 are read and mapped in 0.4-0.6 seconds for all reads, with a small performance hit for the automap:

For larger reads, the performance impact is more significant, with DataReaderAutoMap and a static DataReaderMap taking almost twice as long as manually reading and mapping the data, when you reach 100K or 250K reads:

At 10K reads, performance is still comparable for auto-mapping and manual mapping, so whether you can use the DataReaderAutoMap would need to be looked at in context of your own data, mapping complexity and any upstream caching in your solution.

End-to-end WCF code coverage with PowerShell

Elton Stoneman — Fri, 14 Oct 2011 09:53:44 GMT

I'm a big fan of automated testing which actually proves something. Unit tests may prove all the components in a solution work independently, but that doesn't mean you have a working solution. Integration tests give you confidence in the whole solution, but the cost of having a test suite with a lot of external dependencies is the risk of false build failures and long-running test suites.

To get something in between, we have acceptance tests written in SpecFlow which run tests at the highest layer - targeting WCF services which are the external entry point to our solution. Michael Stephenson has blogged and given sessions on the power of BDD for unifying a project team's understanding of a feature, and being able to get code coverage based on features proves the solution works as expected through all scenarios. Acceptance tests use stubs for any external dependencies, so they run quickly and allow us to confidently assert that our solution works, provided the dependencies work as expected.

Getting coverage for a whole stack of .NET code running beneath the WCF layer is trickier than you might expect. There's no VS or MSBuild functionality for it, and you need to dig down to vsinstr and vspercmd. I've made it all as simple as possible with a generic PowerShell script you can call locally during development, and which runs as part of the MSBuild scripts on the server.

The script is on poshcode here: PowerShell script for running WCF code coverage against IIS.

Technically the script can be used to get coverage on any process which is hosted in IIS. The bulk of the work is done in functions in the script, the main block requires you to specify values for your own solution:

#--------------
# Script begins
#--------------

#set variables:
$solutionFriendlyName = 'XYZ'
$wakeUpServiceUrl = 'http://localhost/x.y.z/Service.svc '
$appPoolName = 'ap_XYZ'
$appPoolIdentity = 'domain\svc_user'
$websiteBinDirectory = 'C:\websites\xyz\x.y.z.Services\bin'
$coverageOutputPath = "Test.coverage"

#instrument assemblies:
# - instrument assembly so ALL namespaces are included in coverage
instrument "x.y.z.Services.dll"
# - instrument assembly so anything from the Ignore1 and Ignore2 namespaces are excluded from coverage
instrument "x.y.z.Core.dll" 'x.y.z.Core.Ignore1.*' , 'x.y.z.Core.Ignore2.*'

#instrument W3WP, run tests & export results:
start-instrumentation
& 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe' Build.proj /t:$msBuildTarget /p:ConfigurationName=$configurationName
stop-instrumentation
export-coverage

#------------
# Script ends
#------------

The sections highlighted in blue above need to be replaced with your own values:

solutionFriendlyName - just a friendly name which is used in logging output
wakeUpServiceUrl - any URL which is part of your solution. The script hits the URL to start an app pool which is can instrument for code coverage. Can be anything which fires up the worker process - .svc, .aspx etc.;
appPoolName - the name of the app pool your solution runs under. Ideally have a dedicated app pool as the covergae run stops and starts it, so if it's dedicated to the solution you won't impact anything else;
appPoolIdentity - the service account the app pool runs under. Used in setting up instrumentation;
websiteBinDirectory - path to the binaries you want to be instrumented, where the IIS site is running;
coverageOutputPath - specify what the coverage file will be called. Should have the .coverage extension;
instrument - add a line for every assembly you want to instrument. If the assembly contains just your code, you only need to name the assembly. If it contains generated code you don't want included (e.g. service reference or EF model code), specify each namespace to exclude after the assembly name. Syntax is important here - each namespace should be fully-specified up to the wildcard, quoted in single quotes, and multiple namespaces are comma-separated.

The script has some expectations which mean hardcoded values in the functions, so if your environment is different you'll need to look at those:

running on Windows Server (expects to instrument W3WP.exe)
VS2010 installed at default path
.NET 4 installed

In our build scripts, we have one target to run the tests, and another to run the tests with coverage. The PowerShell script calls back into the original MSBuild script to run the unit tests, so to incorporate the script into your build you need a target like this:

< Target Name = "AcceptanceTestsWithCoverage">

< Exec ContinueOnError = "true"Command='powershell.exe "$(MSBuildProjectDirectory)\RunCoverage.ps1 -msBuildTarget AcceptanceTests -configurationName $(ConfigurationName)"'WorkingDirectory='$(MSBuildProjectDirectory)' />

</ Target >

- passing the script the name of the MSBuild target to run to execute the tests.

The output from the script is a .coverage file which you can load into VS (note that if you rebuild after running coverage, the assemblies will not be instrumented and the coverage won't load correctly), and an XML export of the coverage (which you can roll up in your build scripts, or load into VS).

Mapping and Auto-Mapping Objects

Elton Stoneman — Tue, 03 Jan 2012 23:22:52 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

This is the first of a series of posts covering my generic anything-to-object mapping library on github: Sixeyed.Mapping.

1. Mapping and Auto-Mapping Objects

2. Mapping and Auto-Mapping Objects from IDataReader

3. Mapping and Auto-Mapping Objects from XML

4. Mapping and Auto-Mapping Objects from CSV

5. Comparing Sixeyed.Mapping to AutoMapper

Enterprise projects typically have entities of the same kind defined multiple times to encapsulate different representations. A User domain entity may be projected into a UserModel, containing a flattened subset of the User properties for display:

With layers for domain entities, data contracts, service contract requests and responses, and presentation models you may have five definitions of a related entity, all of which are under your control, and all of which will (hopefully) have consistent naming conventions. Code to manually map between entity representations looks unnecessary as the source and target are so similar:

User user = GetFullUser();

UserModel model = newUserModel

{

DateOfBirth = user.DateOfBirth,

FirstName = user.FirstName,

Id = user.Id,

LastName = user.LastName

//Intentionally leave out AddressLine1 for now

};

This is time-consuming, error-prone, and can add a huge maintenance overhead when properties are added or removed. Neater to use a generic auto-map, which matches properties between target and source entities, and populates target objects:

User user = GetFullUser();

var model = AutoMap<User, UserModel>.CreateTarget(user);

Sixeyed.Mapping on github provides functionality for auto-mapping, and for creating static maps. (For an alternative, Jimmy Bogard’sAutoMapper on CodePlex, is well established but it has a different approach. I wanted a consistent interface for auto maps and manual maps, the ability to map from different sources, and a smaller performance hit - see Comparing Sixeyed.Mapping to AutoMapper).

Auto-Mapping

Auto-mapping is done at runtime, so when the entity definitions change there are no upstream code changes. AutoMap uses reflection, but the performance hit is relatively small and the map can be cached if it’s going to be used repeatedly. The example above is the simplest, but for cases which aren’t covered by discoverable mappings, you can specify individual property mapping actions:

var map = new AutoMap<User, UserModel>()

.Specify((s, t) => t.AddressLine1 = s.Address.Line1) //flatten

.Specify((s, t) => t.FirstName = s.FirstName.ToUpper()) //convert

.Specify((s, t) => t.Address = AutoMap<Address, PartialAddress>.CreateTarget(s.Address)); //nested map

var model = map.Create(user);

Any properties not explicitly specified are auto-mapped. Mapping degrades gracefully, so any properties which can’t be mapped (either because the names can’t be matched, or the source cannot be read from, or the target cannot be written to) are not populated. (Optionally you can force exceptions to be thrown on mismatches).

AutoMap uses a naming strategy to match properties. By default this uses a simple matching algorithm, ignoring case and stripping non-alphanumeric characters. You can override the default to use exact name matching, aggressive name matching (which acts like the simple match but additionally strips vowels and double-letters), or to supply your own strategy (implementing IMatchingStrategy):

var map = new AutoMap<User, UserModel>(); //matches "IsValid" and "IS_VALID"

var exactMap = newAutoMap<User, UserModel>()

.Matching<ExactNameMatchingStrategy>(); //matches "IsValid" and "IsValid"

var aggressiveMap = newAutoMap<User, UserModel>()

.Matching<AggressiveNameMatchingStrategy>()//matches "IsValid" and "ISVLD"

var customMap = newAutoMap<User, UserModel>()

.Matching<LegacyNameMatchingStrategy>(); //custom, matches "IsValid" and "bit_ISVALID"

Internally, AutoMap uses the naming strategy to generate a list of IPropertyMapping objects which represent maps between source and target properties. By default the list is only cached for the lifetime of the map, so the performance cost of reflecting over the types is incurred every time an AutoMap is instantiated and used. The justification for this is that the mapping cache will grow unknowably large, so a simple dictionary cache could end up with a large memory footprint. Equally the performance hit is small, and .NET uses internal caching for reflected types, so in subsequent generations of the same type of map the performance hit will be smaller.

AutoMap does provide a caching strategy if you do want the mappings cached. You can either use the internal cache (which is a simple dictionary and will never be flushed), the standard .NET runtime cache, or provide a wrapper over your own caching layer with an ICachingStrategy implementation:

var map = newAutoMap<User, UserModel>(); //mappings not cached

var dictionaryMap = newAutoMap<User, UserModel>()

.Cache<DictionaryCachingStrategy>(); //mappings cached in dictionary

var cachedMap = newAutoMap<User, UserModel>()

.Cache<MemoryCacheCachingStrategy>(); //mappings cached in .NET runtime cache

Static Mapping

For complex maps, or for scenarios where you don’t want the reflection performance hit at all, you can define a static map. The interface is the same as AutoMap, except by default all properties have to be specified – there is no auto-mapping of unspecified targets, so additionally the naming and caching strategies are ignored.

Static object maps are derived from ClassMap, with the specifications made in the constructor (FluentNHibernate-style):

public classUserToUserModelMap : ClassMap<User, UserModel>

{

public UserToUserModelMap()

{

Specify(s => s.Id, t => t.Id);

Specify(s => s.FirstName, t => t.FirstName);

Specify(s => s.LastName, t => t.LastName);

Specify((s, t) => t.AddressLine1 = s.Address.Line1);

Specify((s, t) => t.Address.PostCode = s.Address.PostCode.Code);

}

There are various Specify overloads, so you can specify mappings in an action, or specify source and target with funcs as you prefer. Execute the map in the same way by calling Create or Populate to map from the source instance to a target:

User user = GetFullUser();

var map = new UserToUserModelMap();

UserModel model = map.Create(user);

You can mix-and-match static and auto-mapping by setting AutoMapUnspecifiedTargets, meaning that the auto-map will be used for any target properties which have not been explicitly specified:

public class UserToUserModelMap : ClassMap<User, UserModel>

{

public UserToUserModelMap()

{

AutoMapUnspecifiedTargets = true;

Specify((s, t) => t.AddressLine1 = s.Address.Line1);

Specify((s, t) => t.Address.PostCode = s.Address.PostCode.Code);

}

This also allows your static map to leverage the naming and caching strategies of AutoMap.

Nested Maps

AutoMap doesn’t traverse object graphs, it will only populate properties in the first-level object (except where you have specified a mapping for a child object). To populate full graphs you can use nested auto-maps or static maps, with one of the Specify overloads to supply a conversion which invokes the map on the target property:

Specify((s, t) => t.User = new FullUserToPartialUserMap().Create(s.User));

//or:

Specify(s => s.User, t => t.User, c =>new FullUserToPartialUserMap().Create(c));

//or:

Specify((s, t) => t.User = AutoMap<User, UserModel>.CreateTarget(s.User));

Performance

As always, the generic solution has a performance implication, although the mapping has had a couple of rounds of optimisation done to minimise the overhead. The highest-value AutoMap solution, which removes as much code and maintenance overhead as possible, has the highest impact. Populating 250,000 objects, the static AutoMap<>.CreateTarget() method takes 13 seconds, compared to 5 seconds for manually populating the targets. Caching the map reduces the time to 8 seconds, and generating the map once and reusing it reduces it again to 7 seconds. Using a static map takes 6 seconds:

In a more representative sample, mapping a single object, the disparity is not so pronounced. Manual and AutoMap versions take approximately the same time; in different test runs, one will be quicker than the other. The static map is consistently faster than manually populating the target object (what? Yes. Possibly due to the hard-core reflection optimisation technique from Jon Skeet):

Up to 1,000 objects, the performance hit in using the AutoMap is negligible:

Above 1,000 objects the cost is more pronounced:

Note that the effort in mapping is computational, not memory-bound, so in a higher-spec system the differences will be smaller.

In a production system, adding 0.0x seconds to a service call involving a database lookup or a service call is likely to be acceptable, especially if the map is used for a single object, or the map can be reused – in which case the overhead will be 0.00x seconds. Likewise if you’re populating a single model for a view, it’s likely to be justifiable for the reduction in the solution’s technical debt.

In different scenarios, the computation of the AutoMap may be an unacceptable performance hit, in which case a static map at least isolates the mapping logic and provides some of the benefits, at a lower performance cost.

ExpectedException in MSTest does not check the exception message

Elton Stoneman — Fri, 30 Sep 2011 14:08:10 GMT

When you're writing a unit test to verify that an exception is thrown and you want to check the content of the error message, the ExpectionException attribute doesn't do it.

This code (which you see a lot):

[TestMethod]

[ExpectedException(typeof(ValidationException), "Postcode must be provided")]

publicvoid PostcodeIsNullOrWhitespace()

{

//etc.

}

- checks that an exception is thrown, and the test will pass if the exception is of type ValidationException. The second parameter of the ExpectedException attribute is the string that will be written in the MSTest output if the test fails, so this test is not checking the content of the exception message.

If you do want to test the exception message as well as the exception type, this utility method does it for you:

///<summary>

/// Runs the action statement and asserts that it causes an exception with the expected type and message

///</summary>

///<typeparam name="TException"></typeparam>

///<param name="action"></param>

///<param name="expectedMessage"></param>

publicstaticvoid AssertRaisesException<TException>(Action action, string expectedMessage)

where TException : Exception

{

try

{

action();

Assert.Fail("Call suceeded. Expected exception of type: {0} with message: {1}".FormatWith(typeof(TException).Name, expectedMessage));

}

catch (Exception ex)

{

if (ex isAssertFailedException)

throw ex;

var exception = ex as TException;

Assert.IsNotNull(exception, "Expected exception of type: {0}, actual type: {1}".FormatWith(typeof(TException).Name, ex.GetType().Name));

Assert.AreEqual(expectedMessage, exception.Message, "Expected message: {0}".FormatWith(expectedMessage));

}

Usage:

[TestMethod]

[ExpectedException(typeof(ValidationException))]

publicvoid PostcodeIsNullOrWhitespace()

{

var postcode = " ";

AssertRaisesException<ValidationException>(() => ValidatePostcode(postcode), "Postcode must be provided");

//etc.

}

Specifying parameterless constructors in Unity configuration

Elton Stoneman — Tue, 04 Oct 2011 09:34:24 GMT

When you ask Unity to resolve a type with multiple constructors, by default it picks the constructor with the most parameters, to facilitate maximum dependency injection.

Richard Blewett has a good post on specifying a different constuctor in config, but it doesn't cover the scenario when the constructor you want is the default, parameterless constructor.

The documentation is a bit lacking, although the config is logical - here's how it looks:

<unity>

<types>

<typetype="x.y.z.Spec.IInterface,x.y.z"

mapTo="x.y.z.Impl.Implementation,x.y.z">

</type>

</types>

</container>

</containers>

</unity>

Distributing WCF service load vertically as well as horizontally

Elton Stoneman — Fri, 16 Dec 2011 07:52:12 GMT

Overview

I've been looking into a solution recently which has a series of remote nodes publishing events to a central node. The publishers have no logic, they just need to contact the central node and record that an event has happened. Off the back of that, the central node does some work inferring what the event means, and computing its relationship to a bunch of other events. Simple enough, but the solution needs to be scalable and make efficient use of its resources.

I started off building it around NServiceBus, but when I had a better understanding of the components and the physical architecture, decided on a different approach. The central node will most likely be an EC2 cluster; using NServiceBus, cluster nodes can communicate with each other's queues, but the remote nodes would need a bridging mechanism to talk to the central node, and I'd rather have a consistent communication model. So I started rebuilding the service layer in WCF, but I wanted flexibility on how the central cluster nodes distributed work amongst themselves.

Solution

Briefly, I wanted a nice solution for this scenario: remote nodes will always talk to the central cluster over HTTP with a REST service; central nodes will distribute load amongst themselves as efficiently as they can. In a low-load situation, the node receiving the originating message should do all the work in the workflow. In a high-load situation, the node receiving the originating message should farm out work to the other nodes. EC2 will let you set up a nice load balancer, but the option to balance load between nodes OR within a node needs a bit more thought - i.e. when a cluster node receives an event published message, it can call the next service in the workflow either by remotely sending a WCF service request to the load balanced URL, or by executing the code locally.

This is actually very simple, and I've published a working example on my github code gallery: DistributedServiceSample. In the sample, all service calls in the central node are run through a generic service invoker:

Service .Execute< IComputeService >(svc => svc.Compute(jobId));

The invoker either builds a WCF client proxy, or instantiates the service implementation locally, and makes the call. In the sample the logic for deciding whether to go remote or local is done in config, but this could be worked into something more complex based on current capacity etc. The sample also allows the invoker to decide whether to make a synchronous call, or farm the work out to an async task (again, through config).

Dependencies

Dynamically building a WCF client proxy is very simple, there are no dependencies outside .NET and you can leave all the endpoint configuration to the normal <serviceModel> config section. When the central node is in remote mode, it gets the proxy like this:

var factory = newChannelFactory<TService>("*");
service = factory.CreateChannel();

(The asterisk tells WCF to pull the client endpoint and binding from config based on the contract name and assumes there is only one client entry per contract).

When in local mode, it's a little bit more involved to do it dynamically. In the sample I have a marker interface (IService) to denote a service contract. In the service application startup I register all service implementations in an IoC container (a wrapper around Unity), and then the central node gets the service like this:

service =

Container.Get<TService>();

The actual method call on the service is done through functions or actions (depending on whether the service returns a response), so it's all typesafe.

Running the sample

Build the sample locally, and open http://localhost/DistributedServiceSample.Services/JobService.svc in WCFStorm or soapUI. Call CreateJob with whatever parameter you like, and you will see output similar to this in DebugView:

JobService.CreateJob called with Name: fhwfiy
Service.GetExecutionMode using *Synchronous* for service: DistributedServiceSample.Contracts.Services.IJobService
Service.GetServiceLocation using *Remote* for service: DistributedServiceSample.Contracts.Services.IJobService
JobService.SaveJob called with jobId: fhwfiy
Service.GetExecutionMode using *AsynchronousIgnoreResponse* for service: DistributedServiceSample.Contracts.Services.IComputeService
Service.GetServiceLocation using *Local* for service: DistributedServiceSample.Contracts.Services.IComputeService
ComputeService.Compute called with jobId: 621849676

The workflow is that CreateJob triggers a SaveJob call, which in turn triggers a Compute call. The service decides whether each downstream call will be made locally or remotely, synchronously or asynchronously based on the contents of the <distributedservicesample.invoker> section in Web.config.

Extensions

The obvious extension is to add an operation name to the config settings, so different operations within the same service can be executed in different ways, which is pretty straightforward. More complex is the idea of dynamically deciding whether to make a local or a remote call. The logic for the decision is all isolated, so it would be a case of swapping out the config stuff with some environment checks, so calls were made locally unless CPU or private bytes or current connections were above a threshold.

The value of a Diagnostics service

Elton Stoneman — Mon, 12 Dec 2011 09:18:38 GMT

For an integration solution with lots of dependencies, it's difficult to definitively state that everything is wired up correctly and that all components in the stack are working. A while ago, Michael Stephenson proposed having a diagnostic service in a solution as a quick way of verifying that a given environment was working, end-to-end. Initially I was sceptical, on the grounds that there shouldn't be any code in a solution which isn't directly solving a business problem, but having tried it out I've been won over.

We now have a dedicated suite of diagnostics services which check a whole range of stuff, including availability of all the downstream services, the in-process and out-of-process caches, and the accessibility of BizTalk file drops. We also include environmental stuff like the version number of the solution, machine name, server date and time, IP addresses etc. And we have a rolled-up service which gives us a green or red status for the solution.

For devs and technical owners of the solution, this gives us a very detailed view of the health of the stack, but we have REST endpoints for the general healthcheck services, and we now use these all over the place:

in our automated deployment process, we send an email after an environment had been deployed. That email contains the output of the healthcheck service, so we can tell if a deployment was successful;
the REST URLs are published to the team, so testers and service consumers can quickly check if the environment is operational before starting work on a release;
we have something like 10 environments which are all catalogued, and the REST URL for the version number service means we're not manually updating version numbers in the catalogue after a release;
we have nightly releases of the integration solution and the downstream services, so we have simple PowerShell script run from a Windows schedule every morning, which checks the output of the REST services and emails the team with the test environment status;
calling the diagnostic service warms up the server app pool, and all the app pools of the downstream services, so the scheduled job warms everything up after a recycle.

With this simple stuff in place we're saving a bunch of time investigating problems which turn out not to be problems in the integration solution, and the offshore test team can quickly see if there are problems with the stack before investing time on tests. Highly recommended.

Extension method for neatly checking a type implements an interface

Elton Stoneman — Tue, 04 Oct 2011 09:00:09 GMT

I've never liked having to pass a string to Type.GetInterface() to check if a type implements an interface.

This extension method to the Type class lets you check more neatly with a generic:

///<summary>

/// Extension methods for the <see cref="Type"/> class.

///</summary>

public static class TypeExtensions

{

///<summary>

/// Returns whether the type implements the given interface

///</summary>

///<param name="value"></param>

///<returns></returns>

public static bool ImplementsInterface<T>(this Type type)

{

var implements = false;

if (typeof(T).IsInterface)

{

var interfaceName = typeof(T).Name;

implements = (type.GetInterface(interfaceName) != null);

}

return implements;

}

Usage:

Assert.IsTrue(typeof(Stub).ImplementsInterface<IStub>());

Uncaught exceptions in Task threads will kill IIS - even with WCF error handling

Elton Stoneman — Fri, 30 Sep 2011 10:42:26 GMT

Yes, all unhandled exceptions will kill the IIS worker process, but in WCF you can tag an IErrorHandler onto your service behavior and all unhandled exceptions will be neatly taken care of. Unless that exception is thrown from a factory task, in which case the error handler is bypassed and the worker process is killed.

So this code:

public ServiceResponse OnBoardClient(Client newClient)

{

if (IsValid(newClient))

{

var client = newClient;

Task.Factory.StartNew(() => OnBoardClientInternal(client));

}

//etc.

}

private static void OnBoardClientInternal(Client newClient)

{

var zero = 0;

var dbz = 10 / zero;

}

- will throw a System.AggregateException in the TaskExceptionHolder.Finalize() method and it will take down the IIS worker process with it (as described in this StackOverflow question). Of course this also kills any other connections being handled by the worker process.

This is in-line with the expected behaviour for ASP.NET applications:

"Exceptions that occur in the context of a request do not cause the worker process to end. However, unhandled exceptions outside the context of a request, such as exceptions on a timer thread or in a callback function, cause the worker process to end".

So the WCF error handler only applies within the request-response context, and within task code you need to explicitly add error handling:

private static void OnBoardClientInternal(Client newClient)

{

try

{

var zero = 0;

var dbz = 10 / zero;

}

catch (Exception ex)

{

//etc.

}

- which can call into your error handler's HandleError method (if your scenario warrants consistent error handling).

Setting up a remote git repository on your ReadyNAS

Elton Stoneman — Thu, 09 Jun 2011 21:29:48 GMT

More of a note-to-self, but may be useful to other ReadyNAS users who aren’t quite at home with Linux.

As I’m doing a lot of coding with different environments, and I want easy SCM, git is a fine choice. Git runs through IP addresses, so I can access remote servers inside VMs without any weird config needed. It integrates natively with XCode for iOS programming, and msysgit is a simple UI for Windows (there is also a VS extension for git).

Setting up git on the ReadyNAS is straightforward, but there are a couple of fiddly steps. First of all install the git add-on and get it configured correctly:

Install the latest version of the community git add-on (download the .bin file and upload as a local update through FrontView, as with any other packages).
Enable root SSH access with the ReadyNAS add-on
Sign on to SSH as root: ssh root@your_nas_ip (using your FrontView admin password)
Open the remote logon script for SSH - text editor vi will get you there: vi .bashrc
Insert a new line in the script to add the folder with the git binaries to the path for remote logins: export PATH=PATH:/opt/rfw/bin

To create & populate your remote repository:

Sign on to SSH as root: ssh root@your_nas_ip
Create the folder for your repository: mkdir /opt/git/what_ever && cd /opt/git/what_ever
Initialise the repository: git – bare init
Exit SSH (exit)
Navigate to the local git project folder: cd projects/etc
Add the remote repo: git remote add origin ssh://root@your_nas_ip/opt/git/what_ever
Populate the remote repository: git push origin master (using your admin password).

All done, and you can push, pull and clone to your NAS drive as if it were github. Navigate to local Web interface (https://your_nas_ip/gitweb/gitweb.cgi) and you should see your new project listed, and you can browse all the previous commits.