Convention Over Configuration

The Decorator Pattern with Ninject

2011-08-10T22:32:00.000-04:00

The Decorator Pattern is an excellent way to add functionality to existing objects at run time while honoring the open/closed principle. I decided to put together a sample project demonstrating this pattern in C# along with the DI container Ninject.

Git Workflow With Submodules

2011-08-03T15:42:00.002-04:00

This quick and raw post describes the typical workflow of using Git with submodules...

When a submodule is updated within the scope of the same project (and you want the latest submodule changes)

git pull (in the root)
git submodule update (in the root)

When a submodule is updated in the scope of another project (and you want those changes in another project which references the submodule)

git checkout branchname (in the submodule directory)
git pull origin branchname (in the submodule directory)
git add -A (in the root)
git commit (in the root)

Git Cheatsheet 1.1

2011-07-28T10:18:00.004-04:00

Rob Conery created an excellent Git Cheatsheet as a part of his Mastering Git video series on his training site TekPub. I decided to tweak this cheat sheet (just a touch) with a few handy git commands:

Git Cheatsheet 1.1

Common Commands
git init (creates a new repo in the current directory)
git init --shared --bare - create a repo on a share

Checkin
git add . (add's all unstaged files to staging)
git commit -m "Message" (commits all unstaged files)

Checkin all changes to tracked files
git commit -am "Message"

Mistakes
git checkout -f (undo local changes)
git reset HEAD - points the head to a previous commit, removing all commits inbetween
git revert HEAD - resets the HEAD to the last commit and reverses everything from the
previous commit. It also adds a commit which details the stuff removed, etc.
git reset --hard (in an emergency break glass)

Configuration
git config --global user.name (sets your username)
git config --global user.email (sets your email)
git config --core.editor (sets your preferred text editor. We suggest "write" - notepad)

Branching
git checkout -b branchname (creates a branch and switches to it)
git branch branchname (creates a branch)
git branch -D branchname (deletes a branch)

Viewing History
gitk (brings up the repo viewer for the current branch)
gitk --all (brings up the repo viewer for all branches)

Merge
git mergetool

Diff/Merge tools (add to .gitconfig)
This section assumes p4Merge which you can get from Perforce.com for free. Add your
favorite below as needed, and make sure to order the arguments as needed.

[diff]
external = "c:/users/username/difftool.sh"

[merge]
tool = p4merge

[mergetool "p4merge"]
cmd = "p4merge.exe" "$BASE" "$LOCAL" "$REMOTE" "$MERGED"

Difftool.sh
#!/bin/sh
p4merge "$2" "$5"

Standard Git Ignore
*resharper.user
[Dd]ebug/
[Rr]elease/
build/
[Bb]in/
[Oo]bj/
*.suo
*.sln.cache
_ReSharper.*/
AssemblyInfo.cs

Git Hub
git pull origin branchname
git push origin branchname
git clone githubrepourl

Using a Connection String Name with Log4Net AdoNetAppender

2011-03-26T17:06:00.004-04:00

Log4Net is a great tool to quickly add logging to a .Net application. However one feature that has been missing is the ability to provide a connection string name in the configuration for the AdoNetAppender. Currently out of the box you have to provide the full connection string in the AdoNetAppender configuration settings. This can violate the DRY principle if the same connection string is already set up in the connectionStrings section of the configuration.

So the question is: How can we enhance the Log4Net AdoNetAppender to have the ability to refer to an already existing connection string defined in the connectionStrings section of the configuration?

The good news is that the team behind Log4Net is already working on this feature. The bad news is that as of now* this feature has not yet been released. This article describes how we can implement a simple solution ourselves.

1) Create a class that inherits from AdoNetAppender.
2) Next create a ConnectionStringName property that will set the Log4Net ConnectionString property to a connection string that is retrieved by the .Net ConfigurationManager.
3) Create a ConnectionStringName entry in the AdoNetAppender section of your config file which maps to an existing connectionString in the connectionStrings section of your config file.

Sample Custom AdoNetAppender Class:

using System.Configuration;
using log4net.Appender;

namespace WebUI.Infrastructure
{
    public class MyCustomAdoNetAppender : AdoNetAppender
    {
        public string ConnectionStringName
        {
            set { ConnectionString = ConfigurationManager.ConnectionStrings[value].ToString(); }
        }
    }
}

Sample Configuration File:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
   <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
  </configSections>
  <log4net>
   <appender name="AdoNetAppender" type="WebUI.Infrastructure.MyCustomAdoNetAppender">
   <bufferSize value="1" />
   <connectionType value="System.Data.SqlClient.SqlConnection, System.Data, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
   <ConnectionStringName value="MyConnectionName"/>
   
   </appender>
   <root>
   <level value="All"/>
   <appender-ref ref="AdoNetAppender" />
   </root>
  </log4net>
  <connectionStrings>
   <add name="MyConnectionName"
   providerName="System.Data.ProviderName"
   connectionString="Valid Connection String;" />
  </connectionStrings>
</configuration>

* 03/26/2011

ASP.Net MVC 3 Logging

2011-03-25T11:17:00.001-04:00

Some useful links to implement ELMAH & Log4Net in an ASP.Net MVC 3 app:

Logging Errors with ELMAH in ASP.NET MVC 3

Logging in MVC

Well Sometimes You Need Configuration

2011-01-13T08:10:00.009-05:00

This post describes how to use configSource in .Net to split up config file settings for developers. This allows us to have standard common config settings in the main web.config or app.config and then have developer specific values in another file.

This example shows how a developer can set up their own connection strings in a seperate config file that won't affect other developers:

In the main web.config file replace your regular connectionStrings section with the following:

Create a file at the same level in the project as the Web.config file and call it Web.LocalDeveloper.config (or any other standard name your team wishes to use).
In the new Web.LocalDeveloper.config enter your specific settings for your local developer workstation:

Note: The best practice is to make sure to use .config as the extension of your files so they cannot be served to the browser. Avoid .xml for example or your files can be available to prying eyes.

Next in our config transform files we can add Xpath expressions to remove the "configSource" entry and add the appropriate configuration entries based on the environment.

In the following example we remove the configSource and add the DBConnection connection string: