Performance Implications of try/catch/finally

The accepted wisdom regarding performance of try/catch|finally in C# has normally been: try has no performance side-effects unless an exception is thrown.A discussion I was involved in recently caused me to discover some performance implications of try/catch blocks. The discussion revolved around protecting the volatility of certain members and the cross-thread memory ordering rules during run-time and during just-in-time compilation.  As it turns out, Microsoft’s x86 .NET 2.0 just-in-time compiler disables optimizations that would affect the CIL order of read/writes in protected blocks (AKA “protected regions”, “guarded blocks”, or “try blocks”).  As a result no optimizations are performed in try blocks. … Continue reading Performance Implications of try/catch/finally

.NET Framework 2.0 Service Pack 1

I noticed mention of .NET Framework 2.0 Service Pack 1 on a Microsoft site today. The BCL Team’s latest blog entry mentions a fix that will make it into the .NET Framework 2.0 SP 1.  Seems an inevitable release of SP1 for .NET Framework 2.0 is pretty official.

Changing TextBox Text as an Undo-able Action

The TextBox class supports undoing the last action–inherited from TextBoxBase.  Normally the user does this by pressing the undo key (Ctrl-Z if your keyboard doesn’t have a specific Undo key) or by selecting “Undo” from the context menu.  The last action can also be undone programmatically by calling TextBoxBase.Undo() (after calling CanUndo() to see if Undo() will work). Changing the text in a TextBox so that the change can be undone is not so obvious though.  Changing the Text property or the SelectedText property is not undo-able.  .NET 2.0 added TextBox.Paste(String) (not inherited from TextBoxBase, it’s inherent to TextBox) that … Continue reading Changing TextBox Text as an Undo-able Action

Protecting intellectual properties in .NET, Part 1.

One thing that bothers many people and organizations about .NET is the ease of which IL code can be re-hydrated into source code (C#/VB/etc.).  While this has always been a problem with binaries, IL code is a much smaller set of instructions compared to the instruction sets of today's processors and is designed around accommodating high-level-language usage patterns–making it easier to translate into high-level source code.  Native binaries could always be disassembled and the assembler code be reassembled into another, new, application.  But, it was assembler code, and optimized–nearly impossible to translate into a high-level-language, let alone similar to the original code .  … Continue reading Protecting intellectual properties in .NET, Part 1.