Monday, April 13, 2009

Copying dependency files to the output directory when running unit tests with MSTest

A rather long title don't you think :) But have you ever wanted to write a unit test using Visual Studio Test Edition and MSTest to have a dependency on configuration files other than app.config to fulfill your test?

This post is mainly about test support for device testing but is the same for desktop testing too.

Now, most people use app.config as a configuration file in .NET for desktop applications. On devices, System.Configuration is not supported. So some device developers end up writing there own configuration reader by serializing the XML into an object. Alternatively they use the class from OpenNETCF SDF or they might parse the XML using LINQ to XML or plain old System.Xml.

Personally I tend to use the serialization option. My configuration files are not named app.config I tend to name them something more specific. You'll find Visual Studio or the test engine does not deploy any other file to the tests Output directory, even if you set properties Build Action to Content and Copy to Output Directory to Copy always. Running your test will fail if you have a dependency on the given configuration file as Visual Studio will not deploy the custom configuration file. It is highly likely most desktop developers have never seen this or unaware this limitation exists because most desktop devs use app.config. In most cases for desktop devs there is no problem.

So how do device guys get around this problem? You can use the same technique as the Mobile p&p team do with the DataAccess block which forms part of the recent Mobile Application Blocks drop: In one of there test projects they have a mock database dependency that is tested on the desktop but need a sample database to test against.
They set the Build Action to Embedded Resource then they use reflection to unpack it. You might think this is quite a bit of work, but they have a reusable class named TestResourceFile that belongs to the TestUtilities project. Using this class does all the unpacking for you.

The code to copy this dependency could look like the following (I've taken this from the p&p Mobile codebase):
private TestResourceFile CreateDbFile()
dbFile = new TestResourceFile(this, "MockDatastore.sdf");
connectionString = String.Format(connectionStringPattern, dbFile.Filename);
return dbFile;

public void ThrowsIfNullParameterNameIsPassed()
using (TestResourceFile file = CreateDbFile())
using (Database database = new SqlDatabase(connectionString))
Database service = new SqlDatabase(connectionString);
delegate { DbParameter param = service.CreateParameter(null, "Maria Anders"); });
But even still there is a better way to solve this problem and that is to use the DeploymentItemAttribute class. It's use is simple. The following code illustrates it use:
public class DataContextFactoryTests
The above code will copy the file "Mobile.DataMapper.config" to the test output directory. You need to ensure to set the file properties Build Action to Content and Copy to Output Directory to Copy always.

I've got to say thanks to Chris Tacke for telling me about this attribute class.

Sunday, April 12, 2009

Microsoft has recently (last few months) announced and released a website for Windows Vista users to post questions here:

There is quite a large MVP presence there to answer your Windows Vista questions.

Friday, April 10, 2009

What type of applications can we build on Windows Mobile today - Part 3 of 10

This is part 3 of 10 of the getting started with Windows Mobile development series. For previous posts in this series please see here.

Today mobile development is getting easier. Many folks from the desktop can port there C# skills over and hit the ground running fairly quickly. The Compact Framework is maturing nicely. Development tools and emulators are getting more feature rich and more reliable.

The types of applications you can build today for Windows Mobile - with regards to managed code fall into the following groups:
  1. Microsoft .NET Compact Framework. This is a subset of the Microsoft .NET Frameworkdesigned specifically for mobile devices. Use this technology for mobile applications that must run on the device without guaranteed network connectivity.
  2. ASP.NET Mobile. This is a subset of ASP.NET, designed specifically for mobile devices. ASP.NET Mobile applications can be hosted on a normal ASP.NET server. Use this technology for mobile Web applications when you need to support a large number of mobile devices and browsers that can rely on a guaranteed network connection.

ASP.NET for Mobile no longer has designer support in Visual Studio 2008. You can simply use the desktop controls and they will render. Now with "6on6" which is IE 6 engine on Windows Mobile 6.1 this will make web development for mobile easier. You can test IE 6 with the recently released WM 6.1 emulators. I wrote a post on this here. One thing to bear in mind is of course screen size.

Most developers write .NET Compact Framework applications over ASP.NET for LOB (Line of Business applications) due to the smart client nature. Also the power of a .NET CF application allows the developer to do whatever he wants. You can access the camera the GPS chipset the radio or the phone. You can access Outlook, manipulate appointments or add/change a contact. You can access a Relational Database Management system such as SQL Server Compact to store your applications data then sync back to SQL Server desktop using Sync Services (Sync Framework). You can write very compelling UI using GDI or on later devices GDI+ for support such as gradient backgrounds and transparency. XNA sadly is not supported, however DirectX is but is limited and memory intensive.

The main power of using the .NET Compact Framework over any other technology is the fact that it is embedded and works great in smart client environments where connectivity is an issue.

ASP.NET is rarely used in my experience, one reason is due to the connectivity issues. Under ASP.NET, mobile devices require a constant connection with the server in order for this type of architecture to work. Web applications do not work well in enterprise solutions for mobile devices. They do work well for consumer applications but not mission critical ones.

You'll probably be thinking how do you architect an application for the .NET Compact Framework. Most developers adopt the Active record pattern for the business layer. This tends to work well as mobile applications tend not to be as complex as desktop applications. And now performance tends not to be so much of a problem as it once was. ORMs and Domain Driven Development with patterns such as the repository data access layer is not quite as good a story.

The only ORM that supports the CF and SQL CE to date is LLBLGen. I am in the process of building an ORM for the Compact Framework and intend on writing an MSDN article how I did it.

The CF 3.5 does support WCF as a consumer, ServiceHost is not supported. There are many binding and other limitations however. Usually the device will have its own domain that uses either a message protocol which can be completely bespoke over TCP or a service layer with standard DTOs via HTTP. Or in some cases Sync data directly using Sync Services or merge replication. Each application is different. Of course vanilla Web Services ASMX has been supported since CF 1.0.

Thursday, April 02, 2009

An example of the Plugin pattern on the Compact Framework

I have been talking about IoC containers on the Compact Framework lately and thought I'd show an example of implementing a simpler example of separating concerns. There is another common pattern to which IoC I believe was derived called the Plugin pattern.

The Plugin pattern is talked about by Martin Fowler in his Patterns Of Enterprise Application Architecture book (good book by the way). It is (in my opinion) a simpler solution to IoC but is a little more limited and doesn't usually involve a framework.

I involves using reflection and creating a factory to create a type usually specified in a configuration file using a common interface. This pattern promotes Aspect Oriented Programming.

As I am in the process of building a managed ORM for the Compact Framework, I decided to use the Plugin pattern for building the data context part of the API. I decided this because the Plugin is easy to implement and doesn't require any framework to implement. I wanted to keep the ORM as simple as possible while at the same time making the framework decoupled from the type of database desired.

As mentioned I am using this pattern for the data context part of my ORM and I have a configuration file used to specify the type of database. Doing this enables me to easily change my database without having to rewrite a vast majority of my application. I don't even need to recompile my app. I can simply change the config and re-run my app.

The configuration setting that specifies the database dialect looks like this:
<property name="datacontext" value="Mobile.DataMapper.Dialect.SqlServerCe35DataContext"/>
The SqlServerCe35DataContext looks like:
public class SqlServerCe35DataContext : DataContext
private SqlDatabase _database;
private readonly MsSqlCe35Dialect _dialect;

public SqlServerCe35DataContext()
_dialect = new MsSqlCe35Dialect();

internal override Database Database
if (_database == null) _database = new SqlDatabase(ConnectionString);
return _database;

internal override Dialect Dialect
get { return _dialect; }
The DataContext class contains the default implementation of SQL Server CE and is defined as an abstract class. It also implements the IDataContext interface which we use in our factory. This enables us to use the Plugin pattern successfully.

Part of the DataContext class looks like this:
public abstract class DataContext : IDataContext
private DbTransaction _transaction;
private string _connectionString;

public virtual void Commit()
if (_transaction.IsNull()) throw new InvalidOperationException("There is no transaction for this session.");

public virtual void BeginTransaction()
_transaction = Database.GetConnection().BeginTransaction();

public virtual void BeginTransaction(IsolationLevel isolationLevel)
_transaction = Database.GetConnection().BeginTransaction(isolationLevel);

internal abstract Database Database

internal abstract Dialect Dialect
I've omitted many memebers as it's not important what this class does. What is important is the implementation in order to implement this pattern for devices.

For those interested, this is based on the Mobile Client Software Factory. I will be publishing the source code to my ORM for Windows Mobile soon - once finished.

So as we saw, the DataContext is abstract and it contains an interface. Just so you can see, the interface looks like this:
public interface IDataContext : IDisposable
string ConnectionString { get; set; }

//Transaction management.
void Commit();
void Rollback();
bool IsInTransaction{ get;}
void BeginTransaction();
void BeginTransaction(IsolationLevel isolationLevel);

IList<TEntity> Read<TEntity>(QueryExpressionCollection queryExpressionCollection);
IList<TEntity> Read<TEntity>(QueryExpressionCollection
queryExpressionCollection, List<Func<ObjectProperty>> columnsInScope);
IList<TEntity> FindAll<TEntity>();
TEntity Read<TEntity>(object id);

int Delete<TEntity>(TEntity entity);
TEntity Save<TEntity>(TEntity entity);
string DatabaseName { get; set; }

As I said I omitted most of the above members from the DataContext class above for clarity as I want to focus on the architecture not implementation details for this post.

So now we have four things:

1. Configuration file that tells us what datacontext to use.
2. The datacontext implementation (SQL CE Server) to use.
3. The base datacontext class.
4. The datacontext implementation.

The only thing that is missing to put all this together so the consumer can just work with the interface (as the consumer doesn't care about where the data lives or how the data is retrieved) is the DataContextFactory.

The Factory is very simple. It looks like this:
public class DataContextFactory
private IDataContext _instance;

public DataContextFactory()

public DataContextFactory(IDataMapperConfiguration dataMapperConfiguration)

private void CreateInstance(IDataMapperConfiguration dataMapperConfiguration)
if (dataMapperConfiguration == null)
dataMapperConfiguration = MapperFactory.CreateDataMapperConfiguration();
var dataContext = dataMapperConfiguration.DataContext;
var asm = Assembly.GetExecutingAssembly();
_instance = (IDataContext)asm.CreateInstance(dataContext.Value);
if (dataMapperConfiguration.HasConnectionString)
_instance.ConnectionString = dataMapperConfiguration.ConnectionString.Value;

public IDataContext GetDataContext
return _instance;
Notice how we have another dependency the IDataMapperConfiguration. There's no need to document this code but quite simply it's a serialized object of the XML posted earlier. We get two things from this XML file 1. The ConnectionString and 2. The concrete DataContext class that implements DataContext. Notice how we set the ConnectionString property after the type has been created. We do this because the CF only supports one Assembly.CreateInstance method that accepts the type to create.

So using this code from the consumer looks like this:
IDataContext context = new DataContextFactory().GetDataContext;
then the consumer can work with this interface as opposed to the implementation. The consumer knows nothing about the underlying database or storage. If you changed the database from Sql CE to SQLLite for example, it is a simple case of changing the configuration file, then re-running the app.

You could implement this architecture with the IoC framework and using dependency injection pattern but the current one developed by the p&p team at Microsoft doesn't have support for configuration files. This means you'd have to recompile your app anytime you change the DataContext implementor. Now, no doubt Microsoft will roll out another version that supports configuration files in the future as the ContainerModel is a fairly early drop.

So the benefit with this implementation is, it's really really easy to implement and doesn't require any framework. If the implementors existed in another assembly, you could easily change the DataContextFactory to use the LoadFrom method to load a given assembly.

Wednesday, April 01, 2009

Dependency injection using the ContainerModel on the Compact Framework

I mentioned a few weeks ago about the availability of an IoC framework for the Compact Framework here.

But a question related to this is how do you implement the dependency injection pattern with this IoC framework as IoC (Inversion of Control) and dependency injection go hand in hand with one another.

The most common way to implement dependency injection is via the constructor. Sadley this container doesn't work like Castle Windsor where Castle resolves dependencies for you automatically without you having to define then when registering the class. However the class still needs to be defined by an interface! With the device Container model you have to explicitly define your dependencies at registration. I'm ok with this as I'm happy to have a half decent container model for the Compact Framework.

So we have our CustomerRepository class that has a dependency on some Adapter (I just made this adapter up, it could do anything). The class looks like this:
public class CustomerRepository : Repository<Customer, int>, ICustomerRepository
private IAdapter _adapter;

public CustomerRepository(IAdapter adapter)
if (adapter.IsNull()) throw new ArgumentNullException("adapter");
_adapter = adapter;
Now, there are no methods in this class but the point is to show the dependency because later, we want to use the adapter class to do some... adapting.

So how do we set up the container to inject the adapter. Something like the following should do the trick:
using Microsoft.Practices.Mobile.ContainerModel;
var builder = new ContainerBuilder();
builder.Register<IAdapter>(adapter => new Adapter());
builder.Register<ICustomerRepository>(repository => new CustomerRepository(Resolve<IAdapter>()));
Then from the consumer, we can code something like the following:
var customerRepository = ComponentContainer.Resolve<ICustomerRepository>();
We didn't have to declare our dependency, it was injected by the framework. We just resolved the adapter when we registered the repository. Of course you need to register this dependency with the framework first. You could use the concrete type here but this means if you change implementation details, you'd have to change the implementor in more than one place.

There we have it, dependency injection using an IoC container on the Compact Framework 3.5.