1:  public string LogEmailAddress { get; set; }

   2:  public string LogFilePath { get; set; }

   3:  public bool LogToDb { get; set; }

   4:  public bool LogToEmail { get; set; }

   5:  public bool LogToFile { get; set; }

3 of these will just control where we’re going to log to and the other two just control to what file or email address we log to.  We’ll also add those fields into all of the load and build xml methods in our BlogConfig class.  Once that’s done, we’ll add a new Logging Handler class into our Business Layer.  The first thing we need is a property to check and see if each type of logging is enabled.  These getters will just reach into our BlogConfig to see if the property above is set to true or false:

   1:  public static bool IsDbLoggingEnabled

   2:  {

   3:       get

   4:       {

   5:            return CacheHandler.GetBlogConfig().LogToDb;

   6:       }

   7:  }

We’re going to create two methods for each type of logging.  One that takes in an exception and one that takes in individual details (in case we’re not logging a specific exception).  Both of these methods will also take in the “logging source” (the method or file calling the logging method).  Before we create those, we’ll create our helper methods to take in those details and create a BlogLog object:

   1:  private static BlogLog GetBlogLog(string message, string details, string level, string logger)

   2:  {

   3:      BlogLog log = new BlogLog()

   4:      {

   5:          BlogConfigId = CacheHandler.BlogConfigId,

   6:          CreateDate = DateTime.Now,

   7:          EventLevel = level,

   8:          Exception = details,

   9:          Message = message,

  10:          Url = HttpContext.Current.Request.Url.ToString(),

  11:          Logger = logger

  12:      };

  13:      return log;

  14:  }

  15:   

  16:  private static BlogLog GetBlogLog(Exception ex, string logger)

  17:  {

  18:      BlogLog log = new BlogLog()

  19:      {

  20:          BlogConfigId = CacheHandler.BlogConfigId,

  21:          CreateDate = DateTime.Now,

  22:          EventLevel = "Error",

  23:          Exception = GetInfoFromException(ex),

  24:          Message = ex.Message,

  25:          Url = HttpContext.Current.Request.Url.ToString(),

  26:          Logger = logger

  27:      };

  28:      return log;

  29:  }

One last item before we get to the logging methods is the GetInfoFromException method we see called above.  It will simply concatenate a few of the details of the exception:

   1:  private static string GetInfoFromException(Exception ex)

   2:  {

   3:      string stackTrace = ex.StackTrace + "\n\n";

   4:      if (ex.InnerException != null)

   5:          stackTrace += LoggingHandler.GetInfoFromException(ex.InnerException);

   6:      return stackTrace;

   7:  }

Finally we’ll create our two actual logging methods.  As you’ll see, these will both make use of our GetBlogLog methods above:

   1:  public static void LogToDb(string message, string details, string level, string logger)

   2:  {

   3:      if (LoggingHandler.IsDbLoggingEnabled)

   4:      {

   5:          BlogLog log = LoggingHandler.GetBlogLog(message, details, level, logger);

   6:   

   7:          var repo = VeritasRepository.GetInstance();

   8:          repo.Add(log);

   9:          repo.Save();

  10:      }

  11:  }

  12:   

  13:  public static void LogToDb(Exception ex, string logger)

  14:  {

  15:      if (LoggingHandler.IsDbLoggingEnabled)

  16:      {

  17:          BlogLog log = LoggingHandler.GetBlogLog(ex, logger);

  18:   

  19:          var repo = VeritasRepository.GetInstance();

  20:          repo.Add(log);

  21:          repo.Save();

  22:      }

  23:  }

That’s it for logging to the database.  We've got two additional methods that will log to email and log to a file but we won’t show those for brevity’s sake.  If you want, you can check out the code attached to see what those look like.  We’re now able to log any errors or information we might want to from anywhere else in the code and we can do it in several different ways.  However, we need a method that will handle figuring out where and what to log to so we don’t have to pick and choose in other locations:

   1:  public static void Log(string message, string details, string level, string logger)

   2:  {

   3:      if (LoggingHandler.IsDbLoggingEnabled)

   4:          LogToDb(message, details, level, logger);

   5:      if (LoggingHandler.IsEmailLoggingEnabled)

   6:          LogToEmail(message, details, level, logger);

   7:      if (LoggingHandler.IsFileLoggingEnabled)

   8:          LogToFile(message, details, level, logger);

   9:  }

  10:   

  11:  public static void Log(Exception ex, string logger)

  12:  {

  13:      if (LoggingHandler.IsDbLoggingEnabled)

  14:          LogToDb(ex, logger);

  15:      if (LoggingHandler.IsEmailLoggingEnabled)

  16:          LogToEmail(ex, logger);

  17:      if (LoggingHandler.IsFileLoggingEnabled)

  18:          LogToFile(ex, logger);

  19:  }

I think we’ve all been touched by Cancer in one way or another.  Even if not a direct relative, you probably know someone that’s had it or have a friend that’s known someone that does.  Every little bit helps as we try to find a cure.  As of writing this, I’ve raised $100 and need to hit at least $500.  If you’d like to donate (and any donation would be greatly appreciated by both myself and ACS) you can do so here.

First and foremost, he doesn’t put any money in the middle.  No $500 to start and no tax money or money from Chance or Community Chest.  Growing up, I always put a fresh $500 in there and replaced that every time someone landed on Free Parking (who then took all the money).  I was ok with this one but the next one was just ridiculous.  If you have multiple railroads and someone lands on one of them, even if the others are mortgaged, you still collect the amount for having that many railroads.  This is just crazy.  He was pretty adamant that this was “the rule” but I had to overrule and call a “House Rule” to block him.  In my mind, if you have two railroads and someone lands on one, they owe you $50.  If however, the other railroad is mortgaged, it’s $25.  Period.  There’s no way around this one.  Thankfully, Hasbro’s official rules agree with me! 

So the question is, how do you play Monopoly?  Are there any weird rules you follow in your house?  Any idea why you have these rules?

   1:  namespace Veritas.DataLayer.Models

   2:  {

   3:      public partial class BlogConfig

   4:      {

   5:          

   6:      }

   7:  }

We’re probably going to end up with dozens of settings (at least) but we’re only going to handle three of them for now.  We’ll add a boolean that will control if comments are allowed on the site, a string to contain the “about” information of the blog, and an int to store the number of posts:

   1:  namespace Veritas.DataLayer.Models

   2:  {

   3:      public partial class BlogConfig

   4:      {

   5:          public bool AllowComments { get; set; }

   6:          public string BlogAbout { get; set; }        

   7:          public int PostCount { get; set; }

   8:      }

   9:  }

Now, since we’re not making columns for any of these, we’re going to need to load them from the xml column whenever we load our BlogConfig object and pull them into the xml when we save it.  Lastly we’ll add methods to load our xml from the properties and to load the properties from the xml:

   1:  public void LoadConfigFromXml()

   2:  {

   3:      XmlDocument doc = new XmlDocument();

   4:      doc.LoadXml(this.ConfigXml);            

   5:      if (doc.DocumentElement["AllowComments"] != null)

   6:          this.AllowComments = Convert.ToBoolean(doc.DocumentElement["AllowComments"].InnerText);

   7:      if (doc.DocumentElement["BlogAbout"] != null)

   8:          this.BlogAbout = doc.DocumentElement["BlogAbout"].InnerText;

   9:      if (doc.DocumentElement["PostCount"] != null)

  10:          this.PostCount = Convert.ToInt32(doc.DocumentElement["PostCount"].InnerText);

  11:  }

  12:   

  13:  public void BuildXmlFromConfig()

  14:  {

  15:      XElement blogConfigXml = 

  16:          new XElement("BlogConfig",

  17:              new XElement("AllowComments", this.AllowComments),

  18:              new XElement("BlogAbout", this.BlogAbout),

  19:              new XElement("PostCount", this.PostCount)

  20:              );            

  21:      this.ConfigXml = blogConfigXml.ToString().Replace("\r\n  ", "").Replace("\r\n", "");            

  22:  }

As we add (many) more config settings, we’ll have to alter these methods but you get the basic idea of how we’re storing and reading our configuration xml.  I added in unit tests for both of these methods as well.  You can get the latest here.

First things first, if you haven’t already done so, add a Models folder to your DataLayer project.  All of our database objects and any extensions will sit in this folder and namespace.  After that, we’ll add a “ADO .Net Entity Data Model” which is the Entity Framework file that we generate all of our database classes and connections in.  Like every past version of Microsoft’s “This is the way to do database access”, we get to generate the majority of our code straight from the database.  Included in this is the same functionality we had with the Linq2Sql generator for pluralizing / singularizing object names (though now it’s optional) as well as including foreign key columns in the models (which will hopefully fix the FK problems that plagued 3.5 (seriously it was like they designed it to be hard to have foreign key constraints).  Once we’ve selected all of our tables and tell it to generate we’re given an EDMX file and presented with a fantastic database diagram view.  Now, technically, we’ve generated our database access.  We could call it a day.  However, since we’re using the repository pattern and we want all of our data access methods to be in one place, we’ll go ahead and create all of those methods in the repository class we made in the last entry.

Before we can add any data access methods we need to add a instance of our Entities object (EDMX) to our repository like so:

private VeritasBlogDBV3Entities db = new VeritasBlogDBV3Entities();

So inside of our repository class we’ll use db. to do all our database interaction.  The first method we’ll create is our Save method.  This method handles saving any inserts, updates, and deletes after they’re done:

   1:  /// <summary>

   2:  /// Saves all DB changes and then accepts the changes.

   3:  /// </summary>

   4:  public void Save()

   5:  {

   6:      db.SaveChanges(System.Data.Objects.SaveOptions.AcceptAllChangesAfterSave);

   7:  }

We’ll call this method after doing any DB changes (or after any group of DB changes if we’re not doing them individually).  After this, we’ll add entries (separated out into regions) for each of our objects for adding and deleting.  So for example, here are the methods for the BlogConfig object:

   1:  #region BlogConfig

   2:   

   3:  public void Add(BlogConfig blogConfig)

   4:  {

   5:      db.BlogConfigs.AddObject(blogConfig);

   6:  }

   7:   

   8:  public void Delete(BlogConfig blogConfig)

   9:  {

  10:      db.BlogConfigs.DeleteObject(blogConfig);

  11:  }

  12:   

  13:  #endregion

These are pretty simple methods and just handle telling our entity object that we want to insert or delete something.  The Save method still has to be called after each of these.  A quick note on the delete methods:  we may or may not end up ever using them.  Typically I don’t like deleting data as much as “marking it inactive” for historical purposes.  We’re going to write some unit tests in a second so we’re going to write a method to pull all our BlogConfigs from the DB.  We won’t end up using this anywhere but in our unit test.

   1:  public IEnumerable<BlogConfig> GetAllBlogConfigs()

   2:  {

   3:       return db.BlogConfigs;

   4:  }

Now, before we can actually write some unit tests, we need to implement the StartTransaction and RollbackTransaction methods we made in the last entry.  These methods will be called before and after any unit tests so we’re not actually putting anything in the database. 

   1:  public DbTransaction Transaction { get; set; }

   2:  /// <summary>

   3:  /// Will create a new transation.  

   4:  /// </summary>

   5:  public void StartTransaction()

   6:  {

   7:      db.Connection.Open();

   8:      DbTransaction trans = db.Connection.BeginTransaction();

   9:      this.Transaction = trans;

  10:  }

  11:   

  12:  /// <summary>

  13:  /// Rolls back a transation. 

  14:  /// </summary>

  15:  public void RollbackTransaction()

  16:  {

  17:      this.Transaction.Rollback();

  18:  }

Now that these methods are implemented, we just need to make a base test class to handle calling these.

   1:  [TestClass()]

   2:  public class TestBase

   3:  {

   4:      public VeritasRepository repo = VeritasRepository.GetInstance();

   5:   

   6:      //Use TestInitialize to run code before running each test

   7:      [TestInitialize()]

   8:      public void MyTestInitialize()

   9:      {

  10:          repo.StartTransaction();

  11:          repo.Save();

  12:      }

  13:   

  14:      //Use TestCleanup to run code after each test has run

  15:      [TestCleanup()]

  16:      public void MyTestCleanup()

  17:      {

  18:          repo.RollbackTransaction();

  19:      }

  20:  }

Now we have everything we need to actually write a unit test to test adding a new BlogConfig:

   1:  /// <summary>

   2:  ///A test for Add BlogConfig

   3:  ///</summary>

   4:  [TestMethod()]

   5:  public void AddBlogConfigTest()

   6:  {

   7:      BlogConfig blogConfig = new BlogConfig()

   8:      {

   9:          Host = "test.com",

  10:          LastUpdateDate = DateTime.Now,

  11:          CreateDate = DateTime.Now,

  12:          ConfigXml = "<BlogConfig></BlogConfig>"

  13:      };

  14:      repo.Add(blogConfig);

  15:      repo.Save();

  16:      //Check the db for changes

  17:      var configs = repo.GetAllBlogConfigs().ToArray();

  18:      var testConfig = configs.Where(p => p.Host == "test.com").SingleOrDefault();

  19:      Assert.IsNotNull(testConfig);            

  20:  }

Since this class implements our TestBase class, before this unit test is called, we’re getting a new instance of VeritasRepository and calling StartTransaction on it.  When the test is done, it will call the RollbackTransaction method on the repo.  If everything goes well, it will create a new config object, insert it into the database, save that change, pull it back, and make sure it comes back from the DB.  Since most of our tests (such as our DeleteConfig test) will rely on having a BlogConfig and a BlogUser (if not many more things) to already be in the DB, we’ll eventually insert all of these in the test initialize but for now, we can add all of our Add / Delete methods and create tests for them.  Since we need to be able to pull records back from the database to make sure our tests are working, we’ll need to add more methods like the GetAllBlogConfigs seen above.  There are a lot of methods that we’ll in our repository that we’re not going to list here so if you want to see them all, download the files and check out the repo.  As of now, we’ve got what should be all the data access methods we’ll need as well as the unit tests for all of them.  As always, you can download the latest here.

The first thing we’ll create is our repository class that' we’ll be using for Data Access.  We won’t actually handle our data access quite yet, but we’re going to create our interface for accessing that data.  We’ll add a new class to the DataLayer named “VeritasRepository”.  For now, we’ll just implement the repository pattern inside this class:

   1:  public class VeritasRepository

   2:      {

   3:          internal const string CACHE_KEY = "_VeritasRepository_Cache_Key";

   4:   

   5:          private VeritasRepository() { }

   6:   

   7:          /// <summary>

   8:          /// Static method to get an instance of our Veritas Repostiory.  

   9:          /// Checks to see if we have a context in case we're using 

  10:          /// this in a unit test.

  11:          /// </summary>

  12:          /// <returns></returns>

  13:          public static VeritasRepository GetInstance()

  14:          {

  15:              if (HttpContext.Current == null)

  16:                  return new VeritasRepository();

  17:   

  18:              if (HttpContext.Current.Items.Contains(CACHE_KEY))

  19:                  return (VeritasRepository)HttpContext.Current.Items[CACHE_KEY];

  20:   

  21:              VeritasRepository repo = new VeritasRepository();

  22:              HttpContext.Current.Items[CACHE_KEY] = repo;

  23:              return repo;

  24:          }

  25:   

  26:          /// <summary>

  27:          /// Forces us to get a new instace for testing purposes

  28:          /// </summary>

  29:          /// <returns></returns>

  30:          public static VeritasRepository ForceNewInstance()

  31:          {

  32:              VeritasRepository repo = new VeritasRepository();

  33:              if (HttpContext.Current.Items.Contains(CACHE_KEY))

  34:                  HttpContext.Current.Items[CACHE_KEY] = repo;

  35:              else

  36:                  HttpContext.Current.Items.Add(CACHE_KEY, repo);

  37:              return repo;

  38:          }

  39:   

  40:          /// <summary>

  41:          /// Will create a new transation.  Not implemented now but will be later.

  42:          /// </summary>

  43:          public void StartTransaction()

  44:          {

  45:              throw new NotImplementedException();

  46:          }

  47:   

  48:          /// <summary>

  49:          /// Rolls back a transation.  Not implemented now but will be later.

  50:          /// </summary>

  51:          public void RollbackTransaction()

  52:          {

  53:              throw new NotImplementedException();

  54:          }

  55:      }

That’s pretty much it for our data layer for now.  No we’ll do a couple things in our Business Layer.  We’ll start by adding a new folder named “Screens”.  To that folder we’ll add a new class named “ScreenBase”.  For all of our views (to be created later) we’ll create a strongly typed Screen that we’ll tie to that view. Our ScreenBase is going to be an abstract class that will contain an instance of our repository class (so all of our child Screens will have access to it) and a few abstract properties and methods:

   1:  public abstract class ScreenBase

   2:      {

   3:          protected VeritasRepository repo = VeritasRepository.GetInstance();

   4:   

   5:          public ScreenBase()  {  }

   6:   

   7:          /// <summary>

   8:          /// Determines if the entites associated with the view 

   9:          /// are valid or not.

  10:          /// </summary>

  11:          public abstract bool IsValid { get; }

  12:   

  13:          /// <summary>

  14:          /// Loads up whatever entities this screen may need.

  15:          /// </summary>

  16:          protected abstract void LoadScreen();        

  17:      }

The last thing we’ll create today are some base objects in our UI project.  Specifically we’ll create a Form class (to override some of the functionality of the html helpers) and some overrides of the ViewPages, ViewUserControl, and ViewMasterPage.  We’ll start by adding a new class named “VeritasForm” to the Views folder:

   1:  public class VeritasForm

   2:      {

   3:          private VeritasRepository repo = VeritasRepository.GetInstance();

   4:          internal const string CACHE_KEY = "_VeritasForm_Cache_Key";

   5:          internal HtmlHelper Helper { get; set; }

   6:   

   7:          /// <summary>

   8:          /// Our static accessor so we can easily access this from the views.

   9:          /// </summary>

  10:          /// <param name="helper"></param>

  11:          /// <returns></returns>

  12:          public static VeritasForm GetInstance(HtmlHelper helper)

  13:          {

  14:              if (helper.ViewContext.HttpContext.Items.Contains(CACHE_KEY))

  15:                  return (VeritasForm)helper.ViewContext.HttpContext.Items[CACHE_KEY];

  16:              VeritasForm form = new VeritasForm(helper);

  17:              helper.ViewContext.HttpContext.Items.Add(CACHE_KEY, form);

  18:              return form;

  19:          }

  20:         

  21:          private VeritasForm(HtmlHelper helper)

  22:          {

  23:              Helper = helper;

  24:          }

  25:      }

Later on we’ll put overrides on helper methods like ActionLink, DropdownList, and more here.  Moving along, we’ll override the ViewMasterPage and create the “VeritasViewMasterPage”:

   1:  public class VeritasViewMasterPage : ViewMasterPage

   2:      {

   3:          public VeritasForm VeritasForm

   4:          {

   5:              get

   6:              {

   7:                  return VeritasForm.GetInstance(Html);

   8:              }

   9:          }

  10:      }

We’re just adding the VeritasForm as a member of our overridden Master Page.   The reason for this is so that later on when we have master pages, we’ll change what they inherit to the VeritasViewMasterPage and we’ll have easy access to VeritasForm.  We’re going to do the same thing for the ViewPage and the ViewUserControl, though one thing to note is that for both of these, we have to override both the version that takes in a templated type and the version that does not.

   1:  public class VeritasViewPage<T> : ViewPage<T> where T : class

   2:      {

   3:          public VeritasForm VeritasForm

   4:          {

   5:              get

   6:              {

   7:                  return VeritasForm.GetInstance(Html);

   8:              }

   9:          }

  10:      }

  11:   

  12:      public class VeritasViewPage : ViewPage

  13:      {

  14:          public VeritasForm VeritasForm

  15:          {

  16:              get

  17:              {

  18:                  return VeritasForm.GetInstance(Html);

  19:              }

  20:          }

  21:      }

And here’s the VeritasViewUserControl:

   1:  public class VeritasViewUserControl<T> : ViewUserControl<T> where T : class

   2:      {

   3:          public VeritasForm VeritasForm

   4:          {

   5:              get

   6:              {

   7:                  return VeritasForm.GetInstance(Html);

   8:              }

   9:          }

  10:      }

  11:   

  12:      public class VeritasViewUserControl : ViewUserControl

  13:      {

  14:          public VeritasForm VeritasForm

  15:          {

  16:              get

  17:              {

  18:                  return VeritasForm.GetInstance(Html);

  19:              }

  20:          }

  21:      }

Because we want strict control over our project names, we’re going to create our Solution file separate from everything else.  So in Visual Studio, go to New and then Project.  Under “Other Project Types” (this won’t be beneath “Visual C#”) we’re going to select “Visual Studio Solutions” and then “Blank Solution”.  This is going to give us a solution with no precreated projects inside of it which is just what we want.  You might have a naming convention you want to follow but we’re just going to use “Veritas” for the name of our solution.  Once that is done we can create our projects.

Anyone familiar with an N-tier architecture will understand why we’re going to add 4 different projects to our solution. First we’ll create our UI project.  After going into “Add New Project” we’re going to choose a “ASP .Net MVC 2 Empty Web Application”.  If you haven’t used the MVC project template before, I strongly suggest creating a “ASP .Net MVC 2 Web Application” and understandubg how things work before proceeding.  We’ll name our project “Veritas.UI.Web”. 

Next we need to create our Business Layer and our Data Layer projects.  So go to “Add New Project” and under “Windows” add a “Class Library” named “Veritas.BusinessLayer” and “Veritas.DataLayer”.  After we’ve created these, we can go and add some references we’ll need later.  The BusinessLayer project should reference the DataLayer.  The UI should reference both the BusinessLayer and the DataLayer.  Lastly, we need to add a “Test Project” (located under “Test”) which we’ll use for all of our unit and integration tests.  Go ahead and name it “Veritas.Tests”.

The last thing we’ll do for today is remove some of the default files that were created that we don’t need.  In the business and data layer projects, there will be a “Class1.cs” file that is generated.  Go ahead and delete that.  Once you’re done with that, do the same thing with “UnitTest1.cs” in the tests project.

So now we’re done with our solution and projects.  In the next entry we’ll actually start doing some coding.  If you’d like a look at the project structure as it should be so far, you can download what we’ve done here.

This table will contain the details specific to an entry.  So Text will be the html or the text for the post.  Keywords will fill the meta keywords for the entry.  Short will be used if we only want to display a shortened version of the html (in order to get more click throughs on RSS feeds for example).  Our entry name will match our title with the exception that it will be HTML encoded (mostly).  Lastly, the BlogAuthorId has a Foreign Key (FK) constraint to the BlogUser table (as mentioned in the previous post).  In addition, BlogConfigId is a FK back to the BlogConfig table as per usual.  Finally, PostType is a value we might use down the road to distinguish between live posts, drafts, or anything else we might store in the table.  Moving along, we’ll look at the BlogViewEntryCount table:

For now the only real point of this table is the WebCount column.  This table just keeps track of the number of times this entry has been loaded via the web.  Down the road, we might add additional columns to see how many times the entry was loaded from an RSS feed or linked from Facebook, or anything else we might want to track.  Each entry will (hopefully) get some comments or feedback but before we can store the feedback, we need a table to store the author of each comment.  Since we’ll likely have repeat commentators we don’t want to have to store their info for every comment, so we’ll have a BlogFeedbackAuthor table:

This table will store the name, email, URL fields that we’ll ask for in every comment.  Then we’ll store a total number of feedbacks for the people that enter the same info repeatedly.  Simple enough.  Now we’ll go to the BlogFeedback table:

First we have FKs to the BlogEntry table and the BlogFeedbackAuthor table.  From there we are storing details on the actual feedback such as the body, the IP address of the user that entered it, the status it’s in (we’ll tie this to an enum in the code), the title of the feedback, and the user agent of the user.  The NotifyAuthorOnFeedback column will be used to figure out if we should email the feedback author when someone comments after them on the same entry.  Lastly we have Feedback Type which we might use down the road to distinguish between types of feedback.   Only 4 tables left (for now) so let’s go to the BlogCategory:

Nothing really special here.  The important things are the Title and the IsActive field.  Now we have our BlogEntryCategory table to tie entries to categories:

This table is straight FKs.  Now we’ll get to BlogPage:

This table will be used to store pages we might want to host on our site with any sort of static comment.  In the PageContent column we can put any html or javascript we want.  Late we’ll make a way to render this so the user can add any static pages they want without having to get into code or anything like that.  We’re also allowing the user to enter the Meta Keywords and Description.  Finally we’ve got the Page Title (what we’ll actually put in the Title tag) and the Encoded Title (what we’ll use for the URL).  Our last table (for now) will be the Blacklist table:

This table will just be used to store the addresses of anyone that wants to opt out of emails.  So if someone comments with a bad address and says they want to be emailed when someone comments after them, the original person has the ability to say “I don’t want these emails!”.  So we’re done (again for now) with our Database Schema.  WOOT!   Coming up we’ll go over the base project structure.  So that you don’t have to go and create all of these tables yourself, you can download a SQL script to create all of these tables here (the SQL file is in a ZIP).

Update 6-27-2010:
BlogCategory's IsActive field should have been a bit field but was incorrectly shown as a nvarchar.

To begin with, I wanted to put the projector on the middle floor (I have a tri-level) of my house.  While this would have provided the widest viewing area, there would have been no way to contain and block the light in the room on the main floor.  Outside of making the floor hideous with blackout curtains hanging everywhere, there wasn’t a way to make it work.  Much to Erin’s pleasure, this meant I was back to putting the projector downstairs.  Sadly this didn’t eliminate all of my problems.

Wanting to stream a lot of video, wireless wasn’t really an option.  Unfortunately this meant I would need to run some network cable into the downstairs (to where the projector would be), to the main floor (where I would move the TV and Media Center), as well as into the bedroom so I could eventually stream to there.  After ordering wire from Monoprice I drilled some holes and climbed up into the attic.  Running the wires ended up being almost too easy with the exception of one place.  Downstairs, I needed to run the wires from the living room, into the ceiling, through a shaft about 6” tall (from the ceiling of bottom floor to the bottom of the top floor) and into the laundry room.  I solved this problem by taping together about 8 wire hangers (after straightening them) and taping one wire to that hanger.  After running that through the floorboards, I taped the other 5 wires (I was running some speaker wire as well) to the wire that had already been run through and pulled them back to the laundry room where all my wires would meet.  After this I just had to splice and test the wires I’d already pulled through the walls to make sure they were working and then put some nice looking plates in front of them.  The last step prior to mounting the projector was to move a light switch that would be right in the projector screens path on the wall downstairs.  Despite having to cut our a gang box and having to connect and extend actual power lines, this step ended up being not too difficult.

After all this, I just needed to unbox the projector.  Once that was done, Atomic and the Senator again helped me to drill in the projector mount and hang the projector downstairs.  When all was said and done, I cleaned up a few things and was left with a pretty good looking projector hanging from the ceiling.  I moved from a 42” screen up to a 106”.  Quite the improvement and one hell of a way to watch movies and play video games.

• It’s cheap but offers the options I need
  For less than $80 I got a .Net hosting account that offered unlimited disk space, unlimited band width, hosting of unlimited domains, and unlimited SQL databases.  Now I’m not a complete idiot.  I’m aware that there is a point where “unlimited” isn’t unlimited.  However, none of the sites I host will ever approach that limit.
• Upgrades quickly
  When I first signed up, Arvixe wasn’t supporting .Net 4.0 yet (it wasn’t out yet) but they assured me that once it dropped they would start.  Days after .Net 4.0 was released, they were already supporting it. 
• Great service
  This is where Arvixe has really shined so far (and I hope continues to do so).  They have a web based support chat on their site that you can use to ask questions prior to ordering or support questions after you already have something.  I’ve never waited more than a few minutes to talk to someone and they’re always helpful with problems.  Instead of “some hosts” where they blame everything on your code and are unwilling to attempt to work with you, Arvixe is willing to do whatever they can to help you solve your problems.

The only negative point I could make about Arvixe is that some of the initial set up (restoring a database from a different host / your own server) and setting up your config file could be easier.  That being said, under both of these circumstances, the support people were a great help with solving these problems.  While I’ve only been using them for 2 months so far, they are already as easy (if not easier to use) than my previous host and their support is amazingly better.  If you’re in the market for a new host or if you’re fed up with getting crappy support, I’d recommend taking a look at Arvixe.