Hack to enforce the cache of an XmlDataSource to invalidate

• Download soure code - 6.9 KB

Introduction

We often use the XmlDataSource control together with the TreeView control.

If the data source is static, it works quite well. But, when the data source needs to be dynamic, there seems to be some problems. This article will introduce one such problem and give you a hack solution.

Symptoms

If the data source needs to be dynamic, you may choose to:

1. Put several XmlDataSource controls on the web form, and switch it by setting different DataSourceIDs.
2. Put only one XmlDataSource control and change the value of the DataFile or Data property of it, when necessary.

Obviously, the first way is more limited and only applicable for some special situations. It's not a good idea to put a lot of data source controls on one form and, more importantly, the count of the data source controls must be a fixed number.

But, what will happen when you change the value of the DataFile or Data property of the XmlDataSource control? From Microsoft's documentations, you may find the following information:

If you change the value of the DataFile/Data property, the DataSourceChanged event is raised. If caching is enabled and you change the value of DataFile/Data, the cache is invalidated.

Unfortunately, in my test (you may download the samples to see it yourself), I found that, the cache will not be automatically invalidated when you change the value of the Data property of the XmlDataSource control, although DataFile makes no trouble.

Workaround

First, you may choose to change the value of the DataFile property of the XmlDataSource, instead of Data. This is an easy solution.

Otherwise, if you stick to changing the property of Data for some reason (for example, your data source is not a real XML file, but just a dynamically-populated string), you may try the following hack method:

public static void XmlDataSourceCacheHack(XmlDataSource dataSource)
{
    try
    {
        Type t = typeof(XmlDataSource);
        MethodInfo m = t.GetMethod("CreateCacheKey", 
                       BindingFlags.Instance | BindingFlags.NonPublic);
        string key = (string)m.Invoke(dataSource, null);
        PropertyInfo p = t.GetProperty("Cache", 
                         BindingFlags.Instance | BindingFlags.NonPublic);
        object cache = p.GetValue(dataSource, null);

        Type t2 = t.Assembly.GetType("System.Web.UI.DataSourceCache");
        MethodInfo m2 = t2.GetMethod("Invalidate", 
                        BindingFlags.Instance | BindingFlags.Public);
        m2.Invoke(cache, new object[] { key });
    }
    catch
    {
    }
}

(It's sure that "using System.Reflection;" is required at the beginning of the file.)

This is just a hack for this problem. I spent more than one day on debugging to find the source of this strange problem.

(P.S.: If you find a more perfect way to solve it, avoiding Reflection, do tell me. Thanks!)

Thanks for PlamenLeykov

You may surely entirely disable the cache feature of the XmlDataSource. It also works fine. This is another easy solution.

But, if your situation is just like mine: the change possibilities are lower than other postback possibilities (for example, the TreeView is quite big and always triggers postbacks more frequently than data sources change), you will prefer using Reflection than disabling the cache.

Is it a bug from Microsoft?

I'm not sure whether this is a bug from Microsoft, or if it is just applied to the design specification. But, either the implementation is wrong, or the documentation is wrong.