Microsoft Enterprise Library 2005

Published 8/16/2005 by Henry in EntLib

A sort off add-on for Visual Studio, this Application Blocks that are in the Library are released by the Patterns and Practices Group within Microsoft. They are reusable components that encapsulate Microsoft best practices in each area.

The Application blocks:

  • Caching
  • Configuration
  • Cryptography
  • Data Access
  • Exception Handling
  • Logging and Instrumentation
  • Security

The overall goals of the Enterprise Library are the following:

  • Consistency. All Enterprise Library application blocks feature consistent design patterns and implementation approaches.
  • Extensibility. All application blocks include defined extensibility points that allow developers to customize the behavior of the application blocks by adding in their own code.
  • Ease of use. Enterprise Library offers numerous usability improvements, including a graphical configuration tool, a simpler installation procedure, and clearer and more complete documentation and samples.
  • Integration. Enterprise Library application blocks are designed to work well together and are tested to make sure that they do. It is also possible to use the application blocks individually (except in cases where the blocks depend on each other, such as on the Configuration Application Block).

A graphical configuration tool (Enterprise Library Configuration Console), provides a way to change and validate application block settings without having to manually edit the XML configuration files where they are stored. The Configuration Console displays the settings and also supplies default values that you can change. Because the configuration settings are presented in a graphical tool, along with default values and information about what each setting means, the task of configuring the application blocks can be handled by developers and system administrators.

The Configuration Console 
The Configuration Console

Each block is well-documented and includes complete source code. In fact, when you download the library you will find that no compiled assemblies are included. In order to implement these products, you must compile each one from the included source code. Fortunately, there is an included batch file that will do all the work for you. In addition, the documentation clearly covers installation, implementation and deployment for all blocks.


Henry Cordes
My thoughts exactly...


Published 7/28/2005 by Henry
I'm proud to announce:
Saturday 23 july 2005 on 12:11 my son Puk was born.
He and his mother both are doing very well.
We are proud, tired and very happy!


Henry Cordes
My thoughts exactly...

Domain ''!

Published 7/18/2005 by Henry

Today the domain is officially claimed. In the next few days, this blog can be reached through:


Henry Cordes
My thoughts exactly...

TFSC or Team Foundation Source Control is built from ground up, Microsoft did not update Visual SourceSafe and call it TFSC. It is a multitiered architecture.
On the other hand, if your familiar with Visual SourceSafe, the look and feel is basically the same, there are just more features.
There are some new features in TFSC compared to Visual SourceSafe, there are:
  • Changesets
  • Branching
  • Merging
  • Shelving
TFSC introduces a concept called changeset. With Visual SourceSafe and other source control products, the files under source control had no linkage, they all where individual files.
Changesets describe a group of associated file modifications, each changeset is given a unique identifier for tracking and reporting.

Branching in TFSC is intelligently copying items from one project to another. The origin, context and history is maintained and future changes can be merged back into the original path. This allows multiple builds and releases to be maintained efficiently. Another benefit of branching is storage space efficiency. The source control server minimizes the required storage by maintaining one copy of the content.

Merging (in CVS this process exists for a long time already) reconciles all the changes from branched code (“the source”) with the original code (“the target”). This is more than blending text, it will merge additions, deletions, undeletions and renames from the source to the target.

Multiple checkout
Team System projects can be configured for multiple checkout . this feature allows more than one user to edit the same file simultaneously. The same engine that merges changes from branched projects merges changes from two or more checked out projects back to the source (people working with CVS know this feature is nothing to be afraid of).

Shelving is another new key concept to TFSC. Shelving allows a developer to store pending changes to the server without checking them in (in the form of a shelveset).
A shelveset is similar to a changeset, except the files are stored on personal space on the server.
Reasons for shelving:
  • Switching to another project with higher priority;
  • Code fails a check in policy and can’t be fixed immediately;
  • Code is not complete enough to be shared
  • Developer needs to leave and wants to keep his code safe

Visual SourceSafe
SourceSafe continues to be available, it will have some new features also:
HTTP access through a Web Service interface
Copy, modify, merge model
A LAN performance booster
Asynchronous file opening, start working before loading is complete
Better support for projects in multiple timezones and multiple languages and Unicode

Henry Cordes
My thoughts exactly...

Cross-page postback is a feature that makes it possible to post values from one page to another, without Server.Transfer or other far fetched techniques. We all know that in ASP.NET 1.xx you could only post a page back to itself, which was pretty annoying.

What do we do?

The way it works is that all controls that implement the new System.Web.UI.WebControls.IButtonControl got a property called:PostBackUrl

When we have a Button on a WebForm (a Button implements IButtonControl), we set the PostBackUrl to the Webform we want to postback to.

What we get is:


How does it work?

When the PostBackUrl property of the 'IButtonControl' is set, the ASP.NET framework binds the corresponding HTML element to new JavaScript function named 'WebForm_DoPostBackWithOptions'. The corresponding HTML rendered by the ASP.NET 2.0 will look like this:



One problem with cross-page posting is the new page presumably needs the view state of the page posted from. The view state is page specific; it contains information, for example, about controls embedded on the particular page. ASP.NET 2.0 resolves this by embedding a hidden input field name, '__POSTBACK' . This field is embedded only when there is an 'IButtonControl' on the page and its 'PostBackUrl' property is set to a non-null value. This field contains the view state information of the poster page. To access the view state of the poster page, you can use the new PreviousPage property of the page:




And with:




We can find all controls on the posting (previous) page and read it's state.

Henry Cordes
My thoughts exactly...