Well, I've decided to move my blogs back to Google's Blogger and wait for Microsoft catching up.  The new link is http://yangcao88.blogspot.com/.

From Microsoft Secrets - by Micchael A Cusumano and Richard W. Selby:

Many firms hire or promote people based solely on their managerial skills, not necessarily on how well they can combine their technical knowledge with an understanding of business and strategy.  Microsoft puts knowledge of the technology and how to make money with this knowledge first in choosing managers.  While this results in a shortage of middle managers with good people management skills, it has served Microsoft well in the highly technical world of developing computer software.  At the same time, through new hires and acquisitions, Micorosft continually broadens its existing skill base such as by adding new groups for consumer software and information-highway products and services.

My coworkers and friends, Ronnie Brown and Jerry Dennany, pointed it to me that static method Process.GetProcessesByName may return empty on Windows 2000 if the processName is longer than 15 characters.  The appeared reason is that both Windows Task Manager and Performance Monitor on Windows 2000 can only display the first 15 characters of a process.  But there are some exceptions to that rule that GetProcessesByName can find some of the processes with the name longer than 15.  So what's going on?

I opened Reflactor to check out how GetProcessesByName method is implemented in Porcess class.  Here is the part in my interest:

ProcessInfo info1 = infoArray1[num1];
bool flag1 = false;
if ((processName.Length < 15) || !ProcessManager.IsNt) {
    flag1 = string.Compare(processName, info1.processName, true, CultureInfo.InvariantCulture) == 0;
}
else if (string.Compare(processName, 0, info1.processName, 0, 15, true, CultureInfo.InvariantCulture) == 0) {
    try {
        using (Process process1 = Process.GetProcessById(info1.processId, machineName)) {
            string text1 = process1.MainModule.ModuleName.ToLower(CultureInfo.InvariantCulture);
            if (text1.EndsWith(".exe")) {
                text1 = text1.Substring(0, text1.Length - 4);
            }
            flag1 = string.Compare(processName, text1, true, CultureInfo.InvariantCulture) == 0;
        }
    }
    catch (Exception) {
         flag1 = true;
    }
}

Obviously on NT platform, the method compares the 1st 15 characters using the process name, and then turns around to compares the full name using process main module's name (without the last ".exe").  The most interesting part is the try/catch block that makes the logic become something like: "as long as the first 15 characters matches, it's still considered match even there is something wrong trying to retrieve the module's name."

So I cranked up an app to perform some tests on Windows 2003 and 2000.  Here is my coclusions:

• GetProcessesByName works correctly on Windows 2003 with processName longer than 15 characters.
• It works correctly on 2000 with processName longer than 15 characters as long as the 15th (base 1) character is not a "." (dot).

For example, if an executable is named "Company.Prodct.App.exe" (the 15th character is "."), the test results are:

• If processName = "Company.Prodct.App" (18 characters), GetProcessesByName returns empty.
• If processName = "Company.Product" (14 characters), GetProcessesByName returns the process.  This should fall into the 1st if block which compares the whole string.

Does that mean that on Windows 2000 the process name is only 14 character long?  Watch the following test.

Now rename the executable to "CompanyProdctApp.exe" (removing the first 2 dots, but still contains 16 characters before the extention.  Here we go:

• If processName = "CompanyProdctApp", GetProcessesByName returns the correct process.  This should fall into the else if block with the comparison of the 1st 15 characters.

So it seems that on Windows 2000 platform:

• The process name is (at least) 15 character long if the 15th character is NOT a dot (".").
• Otherwise, the process name is 14 character long if the 15th character is a dot.  Ironically both Windows Task Manager and Performance Monitor displays the 15th character (".").

It's really nice to read someone from the development team of Enterprise Library blogs about it, like Scott Densmore.  He has several blogs about Configuration Application Block, like this one: "Enterprise Library : Configuration Part 1.1.1 - Storage Provider".  They give an easy introduction on how it works, which makes me feel more confortable to work with the product, besides just reading the documentation and over simplified code samples.

However, I always think the major difference between a sales person and a developer is the former always tells you what works, the latter, on the other hand, reminds you what doesn't.  I'm pretty sure I'm a developer, a die hard kind.

It brought to my attention when I saw IConfigurationChangeWatcher interface.  I was hoping to read something about the default implementation from the blogs.  Unfortunately, I didn't see any.

It took me about 15 seconds to figure out what is dirty out there.  Here it is: ConfigurationChangeFileWatcher class.  It creates a dedicated thread to poll the the configure file, check its LastWriteTime, and fire a ConfigurationChanged event.  The default polling interval is set to 15 seconds.

This is something shocked me but I'd like to hear the reason that it's implemented this way, without using System.IO.FileSystemWatcher class provided by .NET Framework which in my opinion is a far more scalable solution than polling.  If my application has 3 configuration files need to be watched, the last thing I want to see is having 3 dedicated threads sit there doing nothing but polling.  In most cases, configure files are rarely changed at runtime and polling is almost always one of the worst waste of system resources.  If you really have to poll, use System.Threading.Timer class which uses System.Threading.ThreadPool thread for timing and is much scalable.

I also happened to notice that the private DateTime field ConfigurationChangeFileWatcher.lastWriteTime is only used in private thread start method ConfigurationChangeFileWatcher.Poller, which means the field should really be only a local variable to the method.  This type of evidences led me doubt how much serious effort Microsoft patterns & practices group has made to refactory their code.

Knowing what can and can't do is vital important in today's development world to use someone's solution in your application.  You won't have many chances going back and forth on different solutions.  Don't wait until your customers wake you up at 3:00 AM and ask you why their production server's CPU has peaked every 15 seconds which has resulted in the functional failure of another application because it sleeps until system has been idle for at least 30 seconds.

Don't give me wrong.  I am not trying to complain about some bad implementation here.  I believe every implementation has its reason behind it and can be improved later on.  I just want to mark clearly what's the catch before I jump in.  I hope those who know details about EntLib blog more about what doesn't work and why it doesn't.  To see something working is way too obvious.  However, to figure out its bondary can cost you lots of sleepless nights and beautiful weekends, and bring you painful experience, hopefully not too late.

Thanks to scottden's post at GotDotNet on "Can the configuraton be modified throgh code?", which has saved me a lot of time to dig it out.  Here I've corrected errors in his code and posted the complete code sample on how to create a Database object programmatically (without reading configuration files) in Enterprise Library: