Monthly Archives: April 2015

Unable to install Microsoft ASP.NET 2.0 AJAX Extensions

The full error message is:

Microsoft ASP.NET 2.0 AJAX Extensions 1.0 requires the .NET Framework 2.0 of .NET Framework 3.0 The .NET Framework installed can be found on the website ( = 76097). Please install a compatible version of the framework and try again.

Yes, this is outdated stuff but when working on legacy ASP.NET applications, you may be required to install ASP.NET 2.0 AJAX Extensions.

If you are working on Windows 7 x64 or later, this is probably a permissions issues. You are probably not logged in to your box as Administrator. You will, therefore, have to run the ASPAJAXExtSetup.msi as Administrator as follows:

  1. Start a command prompt as administrator.
  2. CD to the directory containing the installer
  3. Type the command msiexec /i ASPAJAXExtSetup.msi to run the installer.

This should run the installer, adding a folder C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET 2.0 AJAX Extensions\v1.0.61025 with associated libraries.

Credit to some answers to this question from here.

Factories or Providers: what is your chosen terminology?

The Factory pattern in plain language is about encapsulating an entity that is responsible for creating stuff provided with a given context. For example, say I wanted to create such an entity responsible for created different implementations of an ILoggerFacade interface defined as such:

public interface ILoggerFacade
void Error(object error);
void Info(object info);

I could define an ILoggerFacadeFactory interface as follows:

public interface ILoggerFacadeFactory
ILoggerFacade CreateLogger(object owner);

and have an implementation for Console, log4Net or other logging libraries as follows:

public class ConsoleLoggerFacadeFactory : ILoggerFacadeFactory
public ILoggerFacade CreateLogger(object owner)
return new ConsoleLoggerFacade(owner);

public class Log4NetLoggerFacadeFactory : ILoggerFacadeFactory
public ILoggerFacade CreateLogger(object owner)
return new Log4NetLoggerFacade(owner);

Then this becomes a matter of registering the appropriate factory in an IoC container, such as Unity, to create the logger as desired:

   ioc.Register<ILoggerFacadeFactory, Log4NetLoggerFacadeFactory>();

This way, I can easily change the type of logger I use in my application via configuration. I use this pattern extensively, especially with 3rd party libraries. I have used this to abstract message queue implementations for MSMQ, RabbitMQ and ZeroMQ, logging and even for UI elements such as DataGrids, DataCharts and Docking containers, without thinking much about the nomenclature.

Recently, however, this terminology has caused some excitement in my professional circles. Others will rather call these types of entity factories, entity providers for good cause. After all, a provider provides stuff. Factories or Providers sort of provide similar responsibilities even though I would argue that factories create stuff while providers do not necessary do so. Either way, there is no right or wrong answer here although I tend to lean toward calling entity creators, factories, for the very reason that the create stuff by typically calling some sort of constructor on the object class.

Just like an automobile factory manufactures cars, an entity factory instantiates new objects. An automotive dealer, on the otherhand, is an auto provider but cannot be considered an automobile factory. This is the way I distinguish these responsibilities. In fact, a provider can be given reference to a factory that will create stuff that is requested of it, it not in its inventory. Distinct responsibilities.

This is the way I see it. What are your thoughts?

Some defensive coding practices against environmetal uncertainties – part 1

1. Always consider Environment.CurrentDirectory as opposed to Assembly.GetExecutingAssembly().Location, when getting current working directory.

This innocent looking line of code causes grief.

var pathToSqliteDatabase = Path.Combine(Assembly.GetExecutingAssembly().Location, "SqliteDb.db3");


Let’s just first ignore the fact that a test harness should be going directly to a database since this is part of the problem. But if you are running a test harness that has to resolve a location to an SQLite database instance you will get interesting results.

If using MSTest, the above line of code resolves to the current test project’s working folder. So if your test project was in c:\dev\SQliteAdventures, pathToSqliteDatabase to be


However, if you decided to change to NUnit and have ReShaper installed, the same above line of code now resolves to some random location:

In my case, it looked like this:


Changing the above line of code to

var pathToSqliteDatabase = Path.Combine(Environment.CurrentDirectory, "SqliteDb.db3");

will return the current result regardless of the operating environment. So this is preferable here.

2. Carefully consider using x86 vs x64 versions of 3rd party dependencies.

The System.Data.SQLite.dll .NET connector for SQLite, for example comes, with an x86 and x64 version. When executing tests using MSTest, x86 version of the is required since the MStest runner executes within the 32 bit Visual Studio process. However, if you are running NUnit via ReSharper, which executes within its own 64 bit process called JetBrains.ReSharper.TaskRunner.CLR45.x64.exe, you need the x64 bit version of this dll otherwise you get image loading exception. Besides testing against abstractions or fakes, I do not yet know to automate this. Ideas always welcomed.

To be continued…..

The perils of ignoring compiler warnings

Do not ignore compiler warnings. Simply do not. Not only should you be looking out for compiler errors, you should also be addressing all compiler warnings that are generated when building your solution.

Listed below is a relatively simply method that provides a user source implementation based on the provided name:

	public IUserSource GetUserSource(string name)
            foreach (var userSource in _userSources)
                if (userSource.Alias == name);
                    return userSource;

            return null;

Although simple, this little method contains an subtle typo that caused myself and the team quite some grief. Since the method is simple enough, I did not bother to write any unit test, which also would have brought the problem to fore. Some of you may immediately identify the problem without even attempting to run the code. Others like myself, required an additional set of eyes to scan through each line to find the problem.

The error is on this line:

                if (userSource.Alias == name);

The innocent looking semi-colon at the end of the line short-circuits the entire if condition, effectively always returning the first element in the _userSources list. Therefore, the returned userSource is not neccesarily the one with an Alias which equals to the supplied name.

Interestingly enough, the compiler created the following warning:

Warning	41	Possible mistaken empty statement	C:\dev\src\TestProject\UserSourceProvider.cs	104	47	TestProject

Also, Resharper provided the following additional warning:

"Possibly mistaken empty statement"

which I strangely ignored, since I am usually very particular on ensuring my code is clean and blessed by ReSharper, usually through the green checkbox located at the top right corner of your Visual Studio editor as indicated here clean code indicator.

While I have since corrected the implementation to use a dictionary and added the corresponding unit test, there was a lesson learned here about the perils of ignoring compiler warnings.