This toolkit is intended to improve web apps performance by decreasing total page size. This page size reduction is achieved by decreasing control ClientID size.

It’s been a year since I first made the code available at code.msdn.microsoft.com and now I decided to migrate it  to CodePlex.

Try it !!!

In most common samples about faking static types, the type itself is public as the static methods are too.

Usually programmers tend to expose all members that going to be targeted by an Unit test. Well, that’s not how I see Unit tests.

I always try to produce code to keep the cyclomatic complexity lower, and If I succeeded I ended up with types that can be easily tested.

I won’t expose code simply to test it, code should always have the minimum visibility that it indeed requires.

Then I rely on tools to test all my type members, either private, internal or public.

Currently I use the Typemock Isolator and I must say that I’m completely satisfied.

So, here’s how I faked an internal static type and also override it’s GetString method to allow me test the first parameter value:

Type globalizationHelperType = Type.GetType("NG.Helper, NG", true);
Isolate.Fake.StaticMethods(globalizationHelperType);
Isolate.WhenCalled(() => globalizationHelperType.GetMethod("GetString", new Type[] { typeof(String) }).Invoke(null, new object[] { null })).DoInstead((callcontext) => { return callcontext.Parameters[0]; });

I’m not used to use Finalizers in my everyday job but I always thought that if I use it more frequently I could achieve some extra performance.

Well, I’m a natural lazy programmer and that prevents me from digging deeper and doing some tests to clarify this guess.

Thanks to community, there is always someone ready to share knowledge and help those lazy guys like me.

One of those guys were Andrew Hunter that posted an article named “Understanding Garbage Collection in .NET”.

In is article I found that:

• The Finalizer execution is non deterministic – it depends on GC and the way it’s operating: concurrent or synchronous.
• It requires two GC cycles to completely remove the object and memory footprint.
• Two many objects with Finalizers could slow down GC a lot

This don't mean that we shouldn’t use Finalizers, but we must take same care when we create Finalizers. The simplified way to Finalizer usage is:

1. Implement System.IDisposable interface
2. move Finalizer code to Dispose method
3. Finish Dispose method execution with a GC.SupressFinalize() operation, this way the GC will know that this object wont need the Finalizer invocation and can be remove immediately.
4. Invoke Dispose method in Finalizer – this way we ensure that external resources were always removed.

A deeper understand on this procedure, also known as the IDisposable Pattern, can be acquired by reading this article (kindly pointed by Luis Abreu).

Conclusion

Using finalizers don't bring any performance improvement but it’s wrong use can be a vector for severe memory management problems.

When we have a class that own external reference not managed automatically by Runtime then the IDisposable Pattern should be used to ensure the correct memory cleanup.