DataDirectory is a RAD developer specific tag that is set by ASP.NET applications, in order to allow developers to get up and go.

It was developed and became a standard element within a developer's toolbox before IT:AD:Code First existed.

It has issues one needs to know about.


  • Advantages:
    • It allows for faster get up and go for developers.
  • Considerations:
    • It is set in the AppDomain by ASP.NET – specifically, the executable that is running the website.
  • Disadvantages:
    • It is not configured by Powershell and therefore is not available when update-database is invoked. This is a crucial issue.

Solutions have been offered on the net are to the following:

internal sealed class Configuration : DbMigrationsConfiguration<FooDemoServer.ProjectDbContext>
  public Configuration()
    //Needed to setup for var used in app.config.
    string executable = System.Reflection.Assembly.GetExecutingAssembly().Location;
    string path = (System.IO.Path.GetDirectoryName(executable));
    AppDomain.CurrentDomain.SetData("DataDirectory", Path.Combine(path, "App_Data"));

Although it was stated that it works 1), I tried over and over, it did not work for me, whether I tried it in the Main() (not referenced), in the DbContext constructor (too late?), in the Configuration constructor (too late?).

The reason is when update-datebase is run under PowerShell, it has no idea as to the location of the solution (it thinks it's running elsewhere):

Directory lookup for the file "C:\Users\me\AppData\Local\assembly\dl3\QHNMHQXZ.369\Y6WZT39Y.AN4\ac074754\24d86983_d7bed201\App_Data\FFooProjectDb.mdf" failed with the operating system error 2(The system cannot find the file specified.).

In addition, when I thought about it more, I determined that hard coding the path in the app startup or Configuration file – as done above – was not the thing to do.

This is a dev-only problem we're trying to solve. When you move to prod, you want the source to come only from app.config's connection string, which will not be relative to the application's root. So you must not solve it this way.

The cumbersome, but correct answer is to invoke update-database with the correct path2):