Enterprise Library and the Config File

The enterprise library needs to have configuration settings defined in the config file or the machine config of the application you've built

Exception management and Upgrading from the old "microsoft application
block" to the new "enterprise library"

When Enterprise Library was called Microsoft Application Blocks, if you wanted to log an Exception, you would write (assuming “ex” is an Exception):

ExceptionManager.Publish(ex);

And if you wanted to log some extended properties you could do something like this:

NameValueCollection customerInfo = new NameValueCollection();
customerInfo.Add("name","scott");
customerInfo.Add("email",blah@blah.com);
ExceptionManager.Publish(ex,customerInfo);

Now that I am upgrading all legacy code to Enterprise Library 2006 for .NET 2.0, I couldn’t find a way to do this since the only way to log an error is:

ExceptionPolicy.HandleException(ex, "General Policy");

where “General Policy” is the name of the Exception Policy in the config file telling the Block what to do with the exception.

Looking in the config file, I noticed a formatter template with the following at the tail end of the template attribute, “…Extended Properties: {dictionary({key} - {value} )}". The formatter template is used to format the exception that is about to be logged somewhere. Looking through the code for where it loops through this Dictionary, I noticed it accessing an IDictionary of Exception.Data. Exception.Data? Where did that come from?

Data is a new .NET framework 2.0 property of the Exception class to allow you to add any user-defined information about the exception. Nothing more to it: Just a simple name/value dictionary for your enjoyment. As if you couldn’t figure it out, my new code would look like:

ex.Data.Add(“name”,”scott”);
ex.Data.Add(“email”,”blah@blah.com”);
ExceptionPolicy.HandleException(ex, "General Policy");

And as long as you use the default formatter, it will log this data at the end of the FormattedException field.

Generics - What i think it is "Shopping Cart Sample"

So today i begin my road to discovery regarding generics.

This article tells me the following regarding generics..

1. New feature introduced in .NET C# 2.0 and CLR 2.0.
2. It gives classes and methods the ability to defer the specification of one or more types until the class or method is-declared and instantiated by client code.

The following sample shows an example of generics ("in less than greater than signs")


namespace SampleShoppingApplication
{
---[Serializable]
---public class ShoppingCart
---{
------private List<item> _items = new List<item>();
------public Collection<item> Items {
---------get { return new Collection<item>(_items); }
------}
------public float TotalCost {
---------get {
------------float sum = 0F;
------------foreach (Item i in _items) sum += i.Cost;
------------return sum;
---------}
------}
---}

---[Serializable]
---public class Item {
------private string _description;
------private float _cost;
------public Item() : this("", 0F) { }
------public Item(string description, float cost) {
---------_description = description;
---------_cost = cost;
------}
------public string Description {
---------get { return _description; }
---------set { _description = value; }
------}
------public float Cost {
---------get { return _cost; }
---------set { _cost = value; }
------}
---}
}



Releasing COM components

Clean up after the use of com components ALLWAYS! Don't wait for the garbage collection to take action, free that memory asap. Ensure that the objects are released in a specific order.

To release use the Marshal.FinalReleaseComObject and pass the relevant RCW.

COM uses reference counting to determine when objects finally get released. RCW's cause the underlying COM object to hold onto the reference even when the object variable goes out of scope! The reference will be released only when the GC disposes of the RCW, thus you cannot control when or in what order COM objects are released from memory.

If there are several references held using Marshal.ReleaseComObject will need to be called several times. If you want to release them all in one go then use Marshal.FinalReleaseComObject this will set the reference count straight to zero.

Consume COM components in .NET

If theres a PIA (primary interop assembly) then use it otherwise generate a RCW (tuntime callable wrapper). Use the Type Library Importer (Tlbimp.exe) to do this.

RCW is a special .NET proxy class that sits between the .NET code and the COM component. It handles everything including the marshaling of data types, using COM interfaces and handling COM events.

For using RCW we have the following options:

1. Obtain it from the author of the original COM component. In microsoft offices case the RCW is created from a PIA provided by the publisher.
2. Generate the RCW via Tlbimp.exe or Visual Studio .NET. The later is simple in that we just reference the COM object in the project, the rest is done for you!
3. Create your own manually via types in the System.Runtime.InteropServices namespace. Very tedious and complicated.

Using Tlbimp.exe is simple [ Tlbimp ComComponent.dll ]

Use a PIA where possible, there more likely to work as expected because there created by the original component publisher. They also might include additional .NET refinements or enhancements.

If a PIA is registered for a dll then it will be used in preference to the creation of an RCW when referenced in VS.NET Studio.

Office has a PIA which you can download from http://msdn.microsoft.com/downloads/list/office.asp