First, this builds on concepts about Strong Names and PublicKeyTokens.  You may need to add a strong name to the EntLib blocks if you include it in a project that already uses strong names (because this requires that all assemblies being referenced also have strong names).

To add a strong name, you'll need to create a key and reference it in the AssemblyInfo.cs file.

Strong Names and Versioning Tips

0 - You will need to add the key to the source code. Microsoft gives us the source code partially so that we can do things like this.

1 - Put properties (like strong-naming) in the GlobalAssemblyInfo.cs. This requires you to remove (or comment out) the key from the other 38 AssemblyInfo files, however it lets you change it in one place.

2 - Note that there are two places that DLLs are stored.

• C:\Program Files\Microsoft Enterprise Library\bin
• C:\Program Files\Microsoft Enterprise Library\src\<variousFolder>\bin

Opening the EntLib solution and compiling creates copies in the \src dir. You still need to copy these to the \bin
Make sure to run the "Copy Assemblies to Bin Directory" script included in the EntLib start menu. If you're not putting DLLs in the GAC,  EntLib's config tool pulls DLLs from the \bin dir. So you'll notice strong-name nightmares if you don't do this. It will set the assembly name (like PublicKeyToken) from those DLLs, not merely the ones used in your project. For example, check the version of the DLLs loaded by the config tool, and make sure that they include the strong name.

• Includes all source code
• An auto-config tool to handle the Xml config files.
• 38 projects of well written code - i.e. a good example to learn from
• Full documentation
• A huge community supporting it.

You can download it here. Be sure to check the official blogs:

• Tom Hollander
• Scott Densmore

When I first was playing around with it, I had trouble with creating strong names and config files.

Configuration Tips

1. A single application can have multiple physical config files:

• CachingQuickStart.exe.config (app)
• cachingConfiguration.config (other block)
• dataconfiguration.config (other block)

Furthermore, you'll need to make sure that the correct file is copied to the app's bin. Merely rebuilding or using EntLib's config tool doesn't copy all configs.

2 - For the data access block config, you'll need to set both the connection string as well as the individual params. Config looks like:

3 - For the Caching Block's Data Provider:

• "PartitionName" does not correspond to actual database partitions, but rather a value in the Caching.CachData.PartitionName column. This means that you don't need to create a DB partition for the DB cache to work.
• Make sure that you run the script to create the Caching DB ('Caching').
• Make sure that user has access to the 'Caching' database, and can insert into the CacheData table. Merely running the create script doesn't provide access to custom users.

4 - For the Caching Block's Isolated Storage, this uses System.IO.IsolatedStorage. You do not provide a physical file path name. Partition Name is a folder name like "MyApp".

I'll discuss Strong Names in my next post.

For constructors, the base member is always called first. For methods, the question is really not-applicable because when there is a base and derived method both with the same name, the base member is only called if the the developer explicitly calls it with the base keyword. Let's flush this out.

Constructors

Given the classes:

Running MyDerived d = new MyDerived("name",5); will display:

Mybase()
MyDerived(string strName)
MyDerived(string strName, int intId)

As we walk through with the debugger, before executing any code, it will start at the overloaded MyDerived and walk down to the MyBase constructor. Once there, it executes the base constructor and walks back up to the calling point - executing MyDerived(string), and fthen finally MyDerived(string,int).

This makes sense - the base object should be instantiated first because we need to build the individual parts before building the whole.

Methods

Given that base class constructors are executed, many people subconsciously think that in cases where the base and derived methods have the same name, that base methods are executed too. However, this only occurs if the developer explicitly makes it that way, by using the "base" keyword (note that the derived can only call the immediate base, i.e. base.base would return an error):

If "base.MyMethod(strName)" is omitted, then MyMethod will not be called - not with inheritance, polymorphism, or anything else. As we look at the keywords used in OOP, we see that this makes sense in each individual case:

1. What is the difference between using virtual/override and new?
2. What is the difference between virtual and abstract?

While there are certainly smarter people then myself who have thoroughly explained every inch of OOP, I'll give it my two cents anyway. (For those interested in other resources, I personally like Deitel and Microsoft's C# Spec).

What is the difference between using virtual and new?

The Virtual keyword (used in the base class) lets a method be overridden (by using override in the derived class) such that if you declare an object of a base type, and instantiate it of a derived type, then calling the virtual method will call the derived type's method, not the base type. This is polymorphism.

The new keyword (used in the derived class) lets you hide the implementation of a base method such that when you declare and instantiate an object of the same type, the method of that type is called. There is no polymorphism here.

I think the best way to explain this is via a code sample that shows the different effects of using virtual vs. new. Say you have the following two classes:

This has two classes, MyBase and MyDerived. For illustration, the classes each only have two methods. For comparison, MyBase has one method virtual, and one not. Likewise, MyDerived overrides the virtual method and hides the non-virtual. The following code snippet shows three separate cases. Note that the virtual-new keywords affect the value of MyNonVirtualMethod based on whether the object is declared as type MyBase or MyDerived.

Note that in the first case, where we declare the object of type MyBase yet instantiate it to type MyDerived, calling MyNonVirtual method is called on the declared type. In the second case, it is called on the Instantiated type.

These concepts are very common when declaring an array of base objects, and then cycling through the array and calling virtual members. A classic example is making an array of Shape objects, calling the GetArea() method on each one, and it correctly returning the area for that shape.

What is the difference between virtual and abstract?

These two keywords are sometimes confused because both can be over-ridden. However, unlike Virtual members, Abstract members have no implementation. As Deitel puts it, "Abstract base classes are too generic to define real world objects" (C# How to Program, pg 392). The Abstract keyword can be applied to either members or the class as a whole. Note that if a class has an abstract member, then that class must itself be abstract (There is no such thing as a "virtual" class).

In the following code snippet below (from Deitel, pg. 394), the abstract class shape has two virtual methods: Area and Double, and one abstract property Name. Note that both virtual members have a concrete implementation. If you create a derived class "Point", and call its Area method, it will return 0.

The following table highlights these differences:

Common Abstract classes in the .Net framework include System.Xml.XmlNode and System.IO.Stream. Perhaps the most common virtual method is System.Object.ToString().

In my experience, many .Net developers have never needed to consciously use patterns because .Net is simple yet powerful enough to get away with it. However, as clients demand better applications, design patterns are becoming almost required.

The groundwork for design patterns is the 23 described in Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (the "Gang of Four" GOF). data & object factory provides a convenient, online, C#, reference for these on their website: http://www.dofactory.com/Patterns/Patterns.aspx. Steven John Metsker also wrote the book Design Patterns in C#, which covers these standard patterns using C#.

Moving beyond the GOF patterns, Microsoft’s Architecture website provides many enterprise patterns for enterprise applications: http://msdn.microsoft.com/architecture/patterns/default.aspx?pull=/library/en-us/dnpatterns/html/ESP.asp

The more I use patterns, the more I like them.