James Allderidge's Blog

XmlNodeWriter is an implementation of XmlWriter that is created with reference to an XmlDocument allowing the creation of an XmlDocument from code that expects a writer object. XmlNodeWriter was available as sample code via MSDN.

We had used this class and another memory buffer based mechanisms for generating XmlDocument's. It turns out that the framework does have its own mechanism for creating an XmlWriter for writing to an XmlDocument, via the XPathNavigator object created from the XmlDocument. The following code snippets demonstrate how this can be used.

The following code snippet shows how some of our code used a memory buffer for creating a dom via an XmlWriter, this is pretty inefficient and introduced bugs as shown below where the encoding was provided which couldn't handle non Unicode characters very well, replacing them with '?', and blew up with “” characters. It works better when you don't specify the encoding but its still inefficient, although I haven't tested if it still works with “” characters.

MemoryStream ms = new MemoryStream();
XmlTextWriter writer = new XmlTextWriter( ms, Encoding.Default );
obj.WriteXml( writer );

// Load into a dom and return
writer.Flush();
ms.Position = 0;
XmlDocument dom = new XmlDocument();
dom.Load( ms );
return dom;

The implementation using the XmlNodeWriter sample code looks like:

XmlDocument doc = new XmlDocument();
obj.WriteXml(new XmlNodeWriter(doc, false));

The implementation using only framework classes is:

XmlDocument dom = new XmlDocument();
using (XmlWriter writer = dom.CreateNavigator().AppendChild())
{
   obj.WriteXml(writer);
}

It can also be used when your performing an XSLT:

XmlDocument outputDom = new XmlDocument();

using (XmlWriter writer = outputDom.CreateNavigator().AppendChild())
{
   XslCompiledTransform ct = new XslCompiledTransform();
   ct.Load(stylesheetUri);
   ct.Transform(inputDom, args, writer);
}

In order to get WIX projects compiling with the default setting for TFS builds a couple of things need to be changed.

One option is be to make the build target the x86 platform, but I quite often have issues with this. The other option is to alter the build definitions to force the Installer to build with the Any CPU target. This is achieved by changing the following:

1. In the configuration manager of Visual Studio. Ensure that the Installer project is selected to build for the Any CPU platform. By default this is unselected (as shown).

2. Edit the Installer project definition so that it will always build under the Any CPU platform:

• Remove the following line from the top of the definition:

    <Platform Condition=" '$(Platform)' == '' ">x86</Platform>

• Change the following property groups associated with the different configurations and platforms removing the platform conditions. E.g. change:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
  <OutputPath>bin\$(Configuration)\</OutputPath>
  <IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
  <DefineConstants>Debug</DefineConstants>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
  <OutputPath>bin\$(Configuration)\</OutputPath>
  <IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
</PropertyGroup>

to:

<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
  <OutputPath>bin\$(Configuration)\</OutputPath>
  <IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
  <DefineConstants>Debug</DefineConstants>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
  <OutputPath>bin\$(Configuration)\</OutputPath>
  <IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
</PropertyGroup>
<ItemGroup>

The installer should now build with a TFS build targeting the Any CPU platform, the MSI appearing in the build output.

The Dynamic Data set of technologies Microsoft have introduced to speed web site development are build on top a set of libraries that provide meta data about a database model. Lots of this information such as maximum field lengths can be very useful within your own code. Below is an example of how to access this data in order to perform some processing on it.

I add a property to the partial class we have for the entity context:

/// <summary>
/// Gets the context meta model which can be used for finding out the model
/// meta data, such as length of fields.
/// </summary>
/// <value>The context meta model.</value>
internal static MetaModel ContextMetaModel
{
    get
    {
        // there doesn't appear to be a way to test if a model has been registered
        // without an exception being thrown. The web application normally registers the context
        // when it starts, we need to ensure its registered when we are operating outside
        // the web application
        MetaModel model;
        try
        {
            model = MetaModel.GetModel(typeof(MyContextContainer));
        }
        catch (InvalidOperationException)
        {
            model = new MetaModel();
            model.RegisterContext(typeof(MyContextContainer),
                new ContextConfiguration() { ScaffoldAllTables = false });
        }
        return model;
    }
}       

For example to find the maximum length of a name field:

int maxLength = MyContextContainer.ContextMetaModel.GetTable("Customer").GetColumn("Name").MaxLength

Although I haven't tested this, I assume the above works just as well with LINQ for SQL contexts.

Following on from a recent post regarding XML serialisation of ADO.NET Entity Framework one issue I've come across is getting entities within the XML in the correct order.

The main issue is that the EntityCollection<IEntityWithRelationships> type used to maintain references within the entity framework is that its un-ordered. This makes perfect sense of course as entities in a database have no reliable order.

Even though this makes sense its very annoying if you just want your entities to come out in a defined order within an object structure and the any XML serialised from it. You could of course order the XML once it has been serialised, either via a transform, or in code, but having data contract references makes this pretty difficult.

I've come up with a pretty hacky mechanism that forces the order that objects are returned via the EntityCollection Enumerators. The solution uses reflection and won't be guaranteed to work in future versions of the framework. Essentially it finds the HashSet object used by EntityCollection to store its values and re-orders the data structure that the HashSet loops through in its enumerator.

Once a sort order has been applied to the entity collection the only code that runs against the collection must only work via the hashsets enumerator. I.e. use a context object solely to get all the objects for the re-order process and only ever read from the collections that have been re-ordered after that. Any attempt to add or remove items will cause the HashSet object to blow up as its underlying data structures have been messed with.

The code is:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data.Objects.DataClasses;
using System.Collections;
using System.Reflection;

namespace Examples

{
    public static class EntityUtil
    {
        /// <summary>
        /// Reorders the entities in an entity collection by the keySelector function.
        /// </summary>
        /// <remarks>
        /// This class uses reflection to re-write the slots in the underlying hashset used by the entity
        /// collection to contain the references.
        ///
        /// The only action that should be taken on the entity collection after this method has been called
        /// is via its enumerators, as the hash set is not left in a consistant state.
        /// </remarks>
        /// <typeparam name="TSource">The type of the entity objects.</typeparam>
        /// <typeparam name="TKey">The type of the key to order by.</typeparam>
        /// <param name="source">The entity collection source to re-order.</param>
        /// <param name="keySelector">The key selector function that returns the key to order by.</param>
        public static void ReorderEntities<TSource, TKey>(
            this EntityCollection<TSource> source, Func<TSource, TKey> keySelector)
            where TSource : class, IEntityWithRelationships
        {
            HashSet<TSource> relatedEntities = (HashSet<TSource>)
                typeof(EntityCollection<TSource>).GetProperty("RelatedEntities", BindingFlags.Instance | BindingFlags.NonPublic).GetValue(source, null);
            // re-order the sets slots to fix the ordering, (but mess up everything else probably)
            Type slotType = typeof(HashSet<TSource>).Assembly.GetType("System.Collections.Generic.HashSet`1+Slot").MakeGenericType(new Type[] { typeof(TSource) });

            FieldInfo slotField = typeof(HashSet<TSource>).GetField("m_slots", BindingFlags.Instance | BindingFlags.NonPublic);
            FieldInfo lastIndex = typeof(HashSet<TSource>).GetField("m_lastIndex", BindingFlags.Instance | BindingFlags.NonPublic);
            System.Array slots = Array.CreateInstance(slotType, relatedEntities.Count);
            int index = 0;
            foreach (TSource obj in new List<TSource>(relatedEntities).OrderBy(keySelector))
            {
                object test = Activator.CreateInstance(slotType);
                slotType.GetField("hashCode", BindingFlags.Instance | BindingFlags.NonPublic).SetValue(test, obj.GetHashCode());
                slotType.GetField("value", BindingFlags.Instance | BindingFlags.NonPublic).SetValue(test, obj);
                slotType.GetField("next", BindingFlags.Instance | BindingFlags.NonPublic).SetValue(test, -1);
                slots.SetValue(test, index++);
            }
            slotField.SetValue(relatedEntities, slots);
            lastIndex.SetValue(relatedEntities, slots.Length);
        }
    }

}

The reflection code itself is quite interesting as it find and constructs an inner type (Slot) of a generic type. The inner type is a struct so the Activator class is used as struct's don't have a constructor to invoke.

An example use of the code is:

Customer customer;
using (ContextContainer context = new ContextContainer())
{
    // cause a load of static data types first
    customer = context.Customers
        .Include("Addresses")
        .Include("Addresses.AddressLines")
        .First(e => e.CustomerId == customerId);
}

// reorder the structure in memory
customer.Addresses.ReorderEntities(e => e.Order);

foreach (Address a in customer.Addresses)
{
    a.AddressLines.ReorderEntities(e => e.Order);

}

The structure will now have the correct serialisation order. FYI an example xslt snippet that works correctly with ordered referenced entites is:

<xsl:for-each select="do:Addresses/do:Address">
  <xsl:apply-templates select="self::node()[@z:Id]"/>
  <xsl:for-each select="self::node()[@z:Ref]">
    <xsl:variable name ="ref" select="@z:Ref"/>
    <xsl:apply-templates  select="//do:Address[@z:Id = $ref]"/>
  </xsl:for-each>
</xsl:for-each>

An application I'm writing has a requirement to only allow authorised users access to particular areas of data, generally referred to as 'Data Authorisation'. Generally when restricting access to data it's a good idea to create a framework that applies authorisation at the layer that the rest of the application uses, i.e. all data access is protected, stopping coding mistakes made at the higher layers exposing unauthorised data.

The application is a typical data entry web site using ADO.NET entities so I've decided to apply data authorisation to data in the ADO.NET Entity classes. Whilst trying to do this it turns out that Entities doesn't appear to allow a fully featured mechanism to prevent data access. For example, you cannot add the ability to restrict queries from returning un-authorised data.

The web site has many EntityDataSource's that generally load data via the entity set name plus a few where clauses. As we cannot generically alter the data returned from these queries I found that if you want to keep on using EntityDataSource's you will need to add joins to the tables containing the access control lists (ACL's) for an entity at the web tier. This isn't ideal but the application is mainly data entry orientated so having the web tier close to the data tier isn't too bad.

What I have found you can do though is to throw exceptions when un-authorised data has been loaded from the database. Although a developer has to know about the access control tables when writing queries, if they get things wrong exceptions will be thrown, highlighting any incorrect code. I.e. even though the web tier defines the join's to the access control tables, if it gets it wrong then the data tier throws exceptions. In addition pages that allow editing of a single entity that load the entity via a query string are protected as the underlying data layer will throw an exception if incorrect data is loaded via the manipulation of the query string.

The application then uses three main mechanisms for authorising data access:

• All queries are written to join to the access control tables when they need to display lists filtered by ACL's.
• All entity objects requiring data authorisation have methods added in partial files to check the ACL's when those entities are loaded from the database.
• When the context saves changes checks are performed to ensure the user is authorised to perform those changes.

The code added to each entity to check access control lists is in general as below. It assumes that each entity has a single identifier, in this case called EntityTypeId (we name our identifies in relation to the type name, for example CustomerId, AddressId...). The code below is invoked whenever an entity is constructed from the database, it makes an assumption that the id is never set when creating new objects (our identifiers are auto generated).

/// <summary>
/// An entity identifier is changed when the object is materialised
/// from the database. Therefore check for permissions here.
/// </summary>
/// <param name="value">The id being changed</param>
partial void OnEntityTypeIdChanging(long value)
{
    if (this.EntityState == System.Data.EntityState.Detached)
    {
        DataAccessControl.AssertEntityTypeAccess(value);
    }
    else
    {
        // all other access potentially alters the acl's so re-cache
        DataAccessControl.AccessCache.ClearThreadAssociations();
    }
}

In my implementation the DataAccessControl class maintains a thread local cache of id's that can be accessed, this will be loaded on each web request and cleared down at the end of a request, or when a different user identity is found. Alternative mechanisms can be used though.

We can monitor when a context has it changes saved through the following code added to the partial class for the context:

partial void OnContextCreated()
{
    this.SavingChanges += new EventHandler(ContextContainer_SavingChanges);
}

void ContextContainer_SavingChanges(object sender, EventArgs e)
{
        List<ObjectStateEntry> checks =
            new List<ObjectStateEntry>(ObjectStateManager.GetObjectStateEntries(EntityState.Added));
        checks.AddRange(ObjectStateManager.GetObjectStateEntries(EntityState.Modified));

        PerformAccessChecks(checks);
}

The above code just gathers up all the changes and ensures that the user has access to objects being added or modified (deleted could be added to if required).

In general a generic data access authorisation mechanism can be added to ADO.NET Entities by performing the following:

• Perform an access check when the entities primary key is changed, when the entity is detached via the partial OnChanging methods.
• Perform an access check to all entities when being saved by listing to the SavingChanges event on the context.

We have some unit tests that tests code which relies on a variable stored in the Asp.Net session state (HttpSessionState) accessed from the HttpContext.Current.Session property.

Our unit tests run within the Microsoft Unit Test framework that comes with Visual Studio, but I think that the technique should apply to other frameworks such as NUnit.

Without doing any work HttpContext.Current returns null. It appears quite easy to make set a current HttpContext to contain a session:

HttpContext.Current = new HttpContext(new HttpRequest("", "http://localhost/", ""), new HttpResponse(new System.IO.StringWriter()));

Now HttpContext.Current returns a context, but HttpContext.Current.Session still returns null. You can attach a basic session object with the following line:

System.Web.SessionState.SessionStateUtility.AddHttpSessionStateToContext(
 HttpContext.Current, new HttpSessionStateContainer("",
  new SessionStateItemCollection(),
  new HttpStaticObjectsCollection(), 20000, true,
  HttpCookieMode.UseCookies, SessionStateMode.Off, false));

Now HttpContext.Current.Session can be assigned to and read from allowing my unit tests to run.

I think the code is best put in the a method marked with a [TestInitialize] attribute. The context should also be cleared when a test has completed:

[TestCleanup]
public void Clean()
{
 HttpContext.Current = null;
}

I'm not expecting the HttpContext to work well for any other calls, but it might allow more than just interaction with the session.