There is a another option, which is to enable software rendering in code. If you are working on .NET 3.5 framework, there’s a way to set that up..unfortunately you have to set that up per window or per target control. But might be useful for those that want to selectively tweak rendering mode for each window.

private void ConfigureSoftwareRendering()
{
    if (shouldEnableSoftwareRendering)
    {
        HwndSource hwndSource = PresentationSource.FromVisual(this) as HwndSource;
        HwndTarget hwndTarget = hwndSource.CompositionTarget;
        hwndTarget.RenderMode = RenderMode.SoftwarewareOnly;
    }
}

If you’re developing in .NET 4 framework, then you have another option, which is to set up software rendering per process….like so.

public partial class App : Application
{
    protected override void OnStartup(StartupEventArgs e)
    {
         if (shouldEnableSoftwareRendering)
            RenderOptions.ProcessRenderMode = RenderMode.SoftwareOnly;
    }
}

You might be wondering why we should use software rendering for WPF applications. It depends on the end-user hardware configuration which might have “WPF-unfriendly” drivers, or just no graphics card. In some situations software rendering might be faster than hardware rendering … hope this helps.

Share this post :

In order to troubleshoot if it’s a hardware problem, or your code, I find that the simplest approach is to first disable hardware rendering on your machine, by modifying a registry key. That registry key might not be on your machine, so add it if it isn’t.  By default if that key is absent, WPF assumes hardware rendering should be enabled.

After you reboot, and the graphic problem has disappeared because your PC is now using software rendering, you know for sure that your code is fine. Next you will have to update your graphics card driver, computer bios, and make sure you have at least .NET Framework 3.5 SP1 installed.

Here’s a link for Guidelines for troubleshooting graphic issues on WPF. It’s quite useful, and covers what I discussed above. Give this a go, it has helped identified our graphics problem very swiftly.

Procedural code can be hard to read, which makes code hard to maintain. To be declarative is to write code in a way that declares your intention fluidly using fluent interfaces. I’ve come up with an example that illustrates this.

In methods, it’s very common to write guard conditions against method parameters, be it value types or reference types. An example below illustrates this.

public double Divide(int top, int bottom)
{
    if (bottom == 0)
    {
        throw new MyBusinessException("Cannot divide by zero");
    }
    return top / bottom;
}

You may be thinking, why don’t we just let .NET throw a DivideByZeroException. I tend to disagree with this approach, because I feel that it is much more appropriate for an application to throw and handle it’s own category of exceptions….but that in itself is another can of worms.

If you have lots of parameters, and you have to guard against them, and these checks get pretty large very quickly, which makes it hard to read. Of course if you’re developing in .NET 4, there’s Code Contracts, but if you’re not, here’s my version of making it declarative.

public double Divide(int top, int bottom)
{
    Verify.ThatValue(bottom).WhenEqualsTo(0).WillThrowException<MyBusinessException>("Cannot divide by zero");
    return top / bottom;
}

I’ve created a Verify library for this purpose, and it understands reference and value types. The fluency with the method chaining allows one to easily understand what that line of code is doing, somewhat like reading a sentence….Verify that the value ‘bottom’, when equals to zero will throw a MyBusinessException with message “Cannot divide by zero”.

Here’s another example. When someClass is null, we write a warning to Trace, and throw an exception.

public void SomeMethod(SomeClass someClass)
{
    Verify.ThatClass(someClass).WhenIsNull()
        .WillExecuteAction(() => Trace.TraceWarning("some class is null"))
        .WillThrowException<MyBusinessException>("some class is null");
    // do something here.
}

There are quite a number of useful checks, and here’s the interface for Verify for reference type.

public interface IVerifyClassCondition<T> where T : class
{
    IVerifyExceptionThrower WhenIsNull();

    IVerifyExceptionThrower WhenIsNotNull();

    IVerifyExceptionThrower WhenEqualTo(T obj);

    IVerifyExceptionThrower WhenNotEqualTo(T obj);

    IVerifyExceptionThrower WhenMeetsCondition(Func<T, bool> condition);
}

Here’s the interface for Verify for value types.

public interface IVerifyStructCondition<T>  where T : struct, IComparable<T>, IEquatable<T>
{

    IVerifyExceptionThrower WhenGreaterThan(T obj);

    IVerifyExceptionThrower WhenLessThan(T obj);

    IVerifyExceptionThrower WhenEqualsTo(T obj);

    IVerifyExceptionThrower WhenNotEqualsTo(T obj);

    IVerifyExceptionThrower WhenGreaterThanEqualTo(T obj);

    IVerifyExceptionThrower WhenLessThanEqualTo(T obj);

    IVerifyExceptionThrower WhenIsDefault();

    IVerifyExceptionThrower WhenIsNotDefault();

    IVerifyExceptionThrower WhenMeetsCondition(Func<T, bool> condition);
}

I guess you get the idea. It’s simple and straightforward, but how often do we bother to write fluent interfaces like this…..I hope this has helped you gain a new appreciation for declarative style and it’s readability. You can download the sample solution below, and I’ve included a whole bunch of unit tests.

Download this library for VS 2010 here.

Download this library for VS 2008 here. (I modified the csproj and solution files from vs2010, hope it works)

Share this post :

Scott Hanselman has 2 great articles on this. He explains how to incorporate parallel builds into Visual Studio, and also talks about how to run parallel build in your build process and scripts.

Take note that it’s not a guarantee that it is always going to make your solution build faster, it also depends on your machine specifications as well as how your project dependency structure. If that structures is linear rather than a tree structure, there would not be much benefit running parallel builds. Also take care about how your project references are used, because running parallel build might cause some unexpected locking problems.

On a more positive note, I’m working on a solution with around 57 projects, and using an 8 core PC. Running parallel build, it shaved off 25 seconds off the usual 2 minutes build. For argument’s sake, if I build my solution say 50 times a time (which is a very optimistic value in my opinion),  I save about  20 minutes a day from compiling (assuming you have an 8 hour work day). That’s a big savings, and that benefit grows over the weeks and months for every developer on your team. Don’t forget your build scripts and automated builds too!

Consider an UserControl that references a ResourceDictionary in it’s MergedDictionaries. Consider that the referenced ResourceDictionary references other ResourceDictionaries, and so on. Now consider that you render 30 of these user controls on a window, each user control creates a unique instance of the same ResourceDictionary, plus much more. Now you suddenly have heaps of memory being allocated, unnecessary memory for that matter. Apparently this occurs in .NET 3.5 only, not 4.0.

In order to resolve this, the simple resolution I can think of is to reference all the Resource Dictionaries you need in your App.xaml, and remove the user control’s Resource Dictionaries. However it might not always be possible, so I had to look for another approach.

Fortunately I came across an excellent article that has a nice solution for this problem by Christian Mosers.

I added a tweak to that solution, which is to use a WeakReference. In theory, this should allow the controls referencing the cached Resource Dictionaries to be garbage collected since we are using Weak References. I have not had the opportunity to verify this yet, so if you do please let me know.

public class CachedResourceDictionary : ResourceDictionary
{
    private static Dictionary<Uri, WeakReference> _cache;

    static CachedResourceDictionary()
    {
        _cache = new Dictionary<Uri, WeakReference>();
    }

    private Uri _source;

    public new Uri Source
    {
        get { return _source; }
        set
        {
            _source = value;
            if (!_cache.ContainsKey(_source))
            {
                AddToCache();
            }
            else
            {
                WeakReference weakReference = _cache[_source];
                if (weakReference != null && weakReference.IsAlive)
                {
                    MergedDictionaries.Add((ResourceDictionary)weakReference.Target);
                }
                else
                {
                    AddToCache();
                }
            }

        }
    }

    private void AddToCache()
    {
        base.Source = _source;
        if (_cache.ContainsKey(_source))
        {
            _cache.Remove(_source);
        }
        _cache.Add(_source, new WeakReference(this, false));
    }
}

In my opinion, this solution is the means to an end, and one should re-think and re-work how resources are being used. In the short run to reduce memory footprint, this is a good fix. One potential problem I experience with this is that Expression Blend 2 does not like derived Resource Dictionary. Expression Blend 4 can work around this problem with the new Design Time Resource Dictionary feature. If you don’t have Blend 4 (like us), consider other poor man’s approach. My approach was to write  two Nant scripts to find and replace Resource Dictionaries to make it Blend friendly, the other to reverse it back.

Happy coding!

Share this post :

If you’re developing in Silverlight, no issue as there’s no DynamicResource. If you’re developing in WPF, I urge you to consider if there’s a need at all to use DynamicResource. If you’re not using SystemColors, SystemFonts or themes in your application, StaticResource should be considered because DynamicResource are re-evaluated at runtime whenever the resource is requested which is an overhead. If you’re not familiar about their usages, you can read more about them here.

So what do I mean by “data-binding not done properly? Apparently if your DataContext does not implement INotifyPropertyChanged, you’re in big trouble!! Here’s a link from Microsoft that explains the phenomenon….

After much research, I came across a fantastic article explaining all the possible errors one can make to cause a memory leak. Some of these are not WPF inherent problems, they are just typical memory leak culprits dominant in all .NET applications, e.g. failure to unsubscribe an event handler; while some are just obscure and weird. But rest assured that some of the weird ones are fixed in .NET Framework 3.5 SP1 and .NET Framework 4…. So if you develop in WPF, this article is a MUST READ!!!!!

Lastly, a word of caution. Remember to start performance testing and memory profiling quite early in the stages of development. It’s a misconception that these activities can be put off until the late stages. If you do that, you have to bear the consequence of not being able to fix these problems because it becomes too hard to change code and change design…you have been warned.

Share this post :

It was doing my head in, I went through the code and database creation scripts, and finally managed to find the problem. Apparently in the database scripts, there was a line ‘SET ANSI_PADDING OFF‘. This tells SQL Server to truncate off trailing zeros for varbinary and trailing spaces for varchar types. This setting takes into effect during table creation, so whatever you specified stays in effect after. In order to change “setting” for that table, you have to drop the table and re-create it with new setting, like so..

DROP TABLE T1;

SET ANSI_PADDING ON;
GO

CREATE TABLE Table1
-- and so on

SET ANSI_PADDING OFF;
GO

MSDN has recommended that you leave the setting to ON, and for very good reason. I doubt you would want things to auto-magically disappear or be modified without your knowledge, but should be should be made explicit and known. It would have saved me hours of troubleshooting, and I hope it will save hours for you too! Please see the ANSI_PADDING MSDN page for more info.

Share this post :

Today I’m going to talk about using the Strategy and Decorator Pattern together, as it turns out they work pretty well together. Strategy pattern is a good way to encapsulate your algorithms, or in my case I want to use it to encapsulate reusable code, following the principle to keep it DRY. With the introduction of Action and Func classes in .NET framework, I have found that writing callbacks to be so much more accessible. For instance, you may sometimes need to repeat lots of Try…Catch statements in your code, and find that hard to keep DRY. This is where using callbacks are useful, like so…

private void ExecuteSomeMethod()
{
    SomeManager someManager = new SomeManager();
    WithExeptionHandling(someManager.Execute);
}

private void WithExeptionHandling(Action callback)
{
    try
    {
        callback();
    }
    catch(Exception e)
    {
        Logger.Log(e.Message);
        throw;
    }
}

This block of code becomes a good candidate for re-usability, and there are heaps of such blocks of code. For instance, logging code to log start and end perhaps for performance monitoring. Another example is transaction scopes, as well as opening and closing of database connections. Another advantage of using these “strategies” is that it coerces the developer to use these conventions and learn good habits.

First of all, I create an interface and a abstract base class to encapsulate the common behavior, as well as to construct the decorator behavior for my strategies.

public interface IStrategy
{
    StrategyResult Execute();
}

public abstract class BaseStrategy
{
    private readonly Func function;
    private readonly IStrategy strategy;

    protected BaseStrategy(Func func)
    {
        function = func;
    }

    protected BaseStrategy(IStrategy strategy)
    {
        this.strategy = strategy;
    }

    protected StrategyResult InternalExecute()
    {
        if (function != null)
        {
            return new StrategyResult(function());
        }
        return strategy.Execute();
    }
}

I’ve create three strategies for this exercise, namely exception handling, transaction scope and logging. Here’s the exception handling strategy.

public class ExceptionHandlingStrategy : BaseStrategy, IStrategy
{
    public ExceptionHandlingStrategy(Func func)
        : base(func)
    {
    }

    public ExceptionHandlingStrategy(IStrategystrategy)
        :base(strategy)
    {
    }

    public StrategyResultExecute()
    {
        StrategyResult result;
        try
        {
            result = InternalExecute();
        }
        catch (Exception e)
        {
            result = new StrategyResult(e);
        }
        return result;
    }
}

Here comes the decorator pattern. If you have notices in the abstract base class earlier on, I have 2 constructors, one which takes an IStrategy<TResult>.  This allows me to wrap many strategies together, essentially getting a chaining effect. For instance, I could easily construct a strategy that logs my method start and end, that handles exception as well as wrap a transaction scope around the call. The possibilities are endless!

To make it easier to construct these decorated chaining effect, I created a factory as well as Extension Methods to make it much sweeter to construct.

public class StrategyFactory
{
    public IStrategy CreateExceptionHandlingStrategy(Func func)
    {
        return new ExceptionHandlingStrategy(func);
    }

    public IStrategy CreateTransactionScopeStrategy(Func func)
    {
        return new TransactionScopeStrategy(func);
    }

    public IStrategy CreateLoggingStrategy(Func func)
    {
        return new LoggingStrategy(func);
    }
}

public static class StrategyExtensions
{
    public static IStrategy WithExceptionHandling(this IStrategy strategy)
    {
        return new ExceptionHandlingStrategy(strategy);
    }

    public static IStrategy WithTransactionScope(this IStrategy strategy)
    {
        return new TransactionScopeStrategy(strategy);
    }

    public static IStrategyWithLogging(this IStrategy strategy)
    {
        return new LoggingStrategy(strategy);
    }
}

So now to wrap it all up with sample code that makes use of all these.

int top = 1;
int bottom = 0;
var factory = new StrategyFactory();

var strategy =
    factory.CreateExceptionHandlingStrategy(() => top / bottom)
        .WithLogging().WithTransactionScope();

StrategyResult result = strategy.Execute();

Console.WriteLine("Result Has Error: {0}", result.HasError);

As you can see, it’s easy now to chain your strategies together. From the sample, I will get an exception for dividing one by zero, but handled by the exception handling strategy.

I hope this entry has given you some good ideas toward maintaining your code base. Download this sample here.

Share this post :

If you have VS 2010 beta installed, you can play around with SL4.

Read more about it here.