Beckshome.com: Thomas Beck's Blog

Sometimes you know that something works a certain way but you haven’t really internalized it, you haven’t grok’ed it, until you experience it firsthand. Such was my knowledge of the interaction between .NET web services and the XML Serializer a couple of weeks ago.

While troubleshooting calls made from a smart client to back-end web services, I was using Process Monitor to see what was going on under the hood. It didn’t dawn on me at first why I was seeing dynamic generation of temporary C# files and compilation of these files using the C# compiler (csc.exe) as shown in the image below. Since the services in question were provided by a legacy mainframe and were necessarily granular and immutable, the client application was generating a lot of new proxies, meaning a lot of wasted time.

The items being generated and compiled, XML serialization assemblies, are necessary to guarantee speedy serialization and de-serialization of type-specific data. Although you’d ideally like to have these assemblies there all of the time, I’ve found several instances under which these assemblies are not present by default:

• If you compile your assemblies using the compiler (e.g. csc.exe) directly. This is true even if you build in release mode with optimizations enabled.
• If you build in debug mode using Visual Studio, as illustrated by the image below.
• If you’re using a third party product that leverages .NET assemblies for service-based interoperation, you might be subject to dynamic proxy compilation and not even be aware of it.

In the final part of this post, I’ll assume that you’re interested in knowing the ways you can get around dynamic XmlSerializer generation and compilation. As you’ve probably derived from the previous section, building a solution with VisualStudio or directly from the underlying MSBuild tool will take care of call the XML Serializer Generator (sgen.exe) for you, as illustrated in the following image.

You can also invoke sgen.exe directly. If you do so, be sure to use the /C flag to pass compiler options. Alternately, if you’re using WCF, you can choose the alternative DataContractSerializer, which has been optimized to avoid the overhead of generating and using the extra assembly and shared only the data contract without sharing the underlying type data.

I picked up this gem of a book when it first came out in eBook format during the PDC. I sent it over to my Kindle and got through the entire book during session downtimes. I planned on being the first to post a review of this book on Amazon but I’ve sat it out too long and will now be the fifth review.

The first four reviewers did a pretty respectable job of providing and overview of Mr. Kiessig’s qualifications and the book content and have all awarded the book the entirely deserved 5 start rating. Rather than pile on more information about Rick Kiessig or what’s in the book, I’m going to tell you why, as a person who has spent a good amount of time looking at .NET application performance, I recommend this book to every person I work with as mandatory reading:

• Although there are great rules out there for web site optimization and corresponding tools to test these rules (e.g. Yahoo’s Yslow), it’s great to see the client side examples from an ASP.NET specific point of view.
• It’s interesting to see someone who bucks the current trends and provides some real insight on when it’s appropriate to use ORM’s, saying essentially that objects are good but ORM’s might not be the best engine if you’re building a Formula 1 race car.
• Try finding another book that will even touch web gardens, partitioning an application into different AppPools, or using the /3GB switch. Try finding a Microsoft engineer who will talk to you about those items and offer objective guidance.
• The write-up and source code on asynchonous web pages and background worker threads – worth the price of the book alone.
• Creative, out-of-the-box ideas: using SQL Server Express for caching, using BI services to support the web tier of the application, etc. – not the kind of advice you find in your typical MSDN article.

It would be interesting to see how ASP.NET MVC and Silverlight play out performance-wise but alas, these technologies are a bit newer and Mr. Kiessig had to get a book to press. I’d gladly pay for the second edition of this book if it includes a couple of additional chapters that address these technologies. Until then, this is by far the most thorough and pragmatic book on ASP.NET performance to be had on the market. It might be simply an eye-opening read or the book that saves your skin one day. Either way, you won’t regret picking this book up.

For quick and easy prototypes, you’ve got to admire ASP.NET MVC and WCF RIA Services. These approaches may not be perfect out-of-the-box but they’re structured much better than the old “bind a dataset to a grid and let it fly” approach of 2003. As easy as these approaches are, I’m always looking for ways to make things easier. I get a lot of bang for my buck by using SQLite as an in-memory database whenever I create a new MVC or RIA Services solution. In fact, I create 4 SQLite databases with each new solution: one each for application data, test data, membership/role data, and logging/tracing data. Below I’ve described the techniques I make use of to utilize each of these databases.

System.Data.Sqlite + ORM of Choice
If you’ve never used SQLite with .NET before, you’ll be happy to know that it’s as easy as can be. The System.Data.SQLite open source ADO.NET provider gives you everything you need. The provider is a complete ADO.NET implementation, including full support for the ADO.NET Entity Framework and Visual Studio design-time support – all in a 900 KB assembly. Need support for VisualStudio 2010? Ion123 includes a library compatible with 2010 in this post. So whether you use Entity Framework or NHibernate, just drop in the System.Data.Sqlite DLL, create a database, wire up your objects to the ORM and go to town. Data access simply could not be easier.

SQLite-Backed Testing
There are lots of good reasons to implement proper interfaces and mock objects or stubs for the purposes of testing. Sometimes it’s just easier not to have to deal with it. SQLite-backed testing provides the perfect alternative. You can still create your unit tests, even exercising framework elements and third party libraries that aren’t always the easiest to cover with traditional mocking frameworks. Just plug in a temporary SQLite test database, write your test code just as you’d write your application code and use one of several mechanisms to purge the data between tests. As usual, Ayende provides the definitive reference on how to do this for NHibernate. I’ve provided code below from my experiences doing this with file backed databases for Castle ActiveRecord. Find your way to Google for references on how to accomplish this with the Entity Framework.

using Castle.ActiveRecord;
using Castle.ActiveRecord.Framework;
using Castle.ActiveRecord.Framework.Config;
using Gallio.Framework;
using Gallio.Model;
using MbUnit.Framework;
using MyNameSpace.Models;
using System;

namespace MyNameSpace.Tests
{
    public abstract class AbstractBaseTest
    {
        protected SessionScope scope;

        [FixtureSetUp]
        public void InitializeAR()
        {
            ActiveRecordStarter.ResetInitializationFlag();
            IConfigurationSource source = new XmlConfigurationSource("TestConfig.xml");
            ActiveRecordStarter.Initialize(source, typeof(Object1), typeof(Object2));
        }

        [SetUp]
        public virtual void Setup()
        {
            Object2.DeleteAll();
            Object1.DeleteAll();
            scope = new SessionScope();
        }

        [TearDown]
        public virtual void TearDown()
        {
            scope.Dispose();
        }

        public void Flush()
        {
            scope.Flush();
            scope.Dispose();
            scope = new SessionScope();
        }
    }
}

SQLite as a Membership and Role Provider
Both ASP.NET MVC and WCF RIA Services use SQL Server ASP.NET Membership and Role Providers by default. Take SQL Server out of the equation and swap in the custom SQLite Membership and Role Providers and you can use SQLite for your security data as well. Configuration of the custom provider can all be done right in the web.config file, as illustrated below.

<configuration>
  <connectionStrings>
    <add name="MembershipConnection" connectionString="Data Source=C:ProjectsDatabasesMyApp_Membership.s3db;Version=3;"/>
  </connectionStrings>
	<system.web>
		<authentication mode="Forms">
			<forms loginUrl="~/Account/LogOn"/>
		</authentication>
    <membership defaultProvider="SQLiteMembershipProvider" userIsOnlineTimeWindow="15">
      <providers>
        <clear/>
        <add name="SQLiteMembershipProvider" type="MyNameSpace.Web.Helpers.SqliteMembershipProvider" connectionStringName="MembershipConnection" applicationName="MyApplication" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="true" passwordFormat="Hashed" writeExceptionsToEventLog="true"/>
      </providers>
    </membership>
    <roleManager defaultProvider="SQLiteRoleProvider" enabled="true" cacheRolesInCookie="true" cookieName=".ASPROLES" cookieTimeout="30" cookiePath="/" cookieRequireSSL="false" cookieSlidingExpiration="true" cookieProtection="All">
      <providers>
        <clear/>
        <add name="SQLiteRoleProvider" type="MyNameSpace.Web.Helpers.SQLiteRoleProvider" connectionStringName="MembershipConnection" applicationName="MyApplication" writeExceptionsToEventLog="true"/>
      </providers>
    </roleManager>
	</system.web>
</configuration>

SQLite Logging and Tracing with NLog
I recently covered the integration of NLog with SQLite. A simple configuration file entry and all of your log and trace output can go into a single SQLite database.

One of the things I’m often asked to do for clients is to create an applicability matrix. That is, which technology applies best to which particular challenges in an enterprise? There would seem to be an acute need for this type of clarification in the realm of Microsoft’s service technologies. With the recent releases of Web Process Activations Services (WAS) on Windows Server 2008, WCF 3.5 and 4.0, Windows Server AppFabric, BizTalk 2009 and 2010, and Windows Azure AppFabric, the waters of Microsoft’s service and integration technologies is muddy indeed. In this post, I’m going to provide some clarification; explaining what new service and integration offerings are on the way from Microsoft, offering a frame of reference on how I see them applying to enterprise customers, and furnishing references to materials you can use to educate yourself in these technologies.

Let’s start off with a quick tour of Microsoft’s new service and integration offerings. Specifically, I’m going to cover WCF 4.0, Server AppFabric, and Azure AppFabric. In this overview, I’m going to restrict the discussion to technologies that specifically relate to the challenges of traditional large enterprise application integrations. Interesting aspects of Microsoft’s new offerings such as WCF 4.0 RESTful service support (incorporated from the WCF Rest Starter Kit) and AppFabric Caching (formerly known as ‘Velocity’) will not be covered in detail.

What I’ve found is that knowledge of these new service and integration offerings alone does not get you to the point where you intuit when to apply them to enterprise application integration challenges. Therefore, I have begun to cluster these technologies together and think about what the best use cases are for each of the respective technologies. The image below represents these clusters, along with the archetype use case and particular features of the clusters’ technologies. This clustering represents a fundamental simplification of reality and doesn’t account for many of the shades of gray. Decisions such as whether workflows are best hosted in WF under AppFabric or under BizTalk are best made by application architects, based upon their knowledge of the organizational, business and technical constraints that impact their applications. That said, these clusters represent what I feel to be sound heuristics for Microsoft service and integration decisions over the next several years.

I’ve been ranting to some colleagues about a particularly useful table that showed the interactions between WCF’s InstanceContextMode and ConcurrencyMode behaviors.  I referenced it in a conversation again today and decided that I needed to go hunt down the phantom table so that it haunted me no longer.

I thought the table was in Lowy’s Programming WCF Services. Full attribution to Essential Windows Communication Foundation: For .NET Framework 3.5, one of my other favorite WCF books. I’ve copied the table below so that I can refer to it by hyperlink forever more.

The table is awesome because it shows you the results of the different ways of combining these two important WCF concurrency settings, including the default combination.  Without some trial and error, it’s not always easy to intuit what the combination of these settings means. This table makes it easy.