While developing OzCode, we work with multiple class types that represent a parsed C# code file: objects that represent things such as if statements, while loops, assignment expressions, and so forth. As you can imagine, the class hierarchy of these objects is quite complex and large – Underneath the base type there are dozens of
Search Results for:
OzCode is free for non-commercial open source projects!
<p>We here at OzCode Software are really big fans of the .NET open source community.</p> <p>From NuGet to NHibernate to NUnit, you can hardly do any serious .NET development work today without coming to rely on these great collaborations between people from different countries, working together to create quality software for the benefit of us
Top 3 Memory Leak Inducing Pitfalls of WPF Programming
Recently, while fixing a few memory leaks, I was surprised at just how easy it is to unknowingly cause a serious memory leak by doing simple, mundane things in WPF. In this post, I will summarize the most common pitfalls to look out for. Be careful when binding to a regular property This is probably
Using OzCode to flatten class hierarchies while debugging
While debugging deep class hierarchies in Visual Studio, I was often annoyed by having to constantly expand the “base” nodes to get to see the members I wanted to see. This happens because Visual Studio only shows fields and properties declared on the given type, and tucks all the members of the base classes under
Painlessly debugging the WPF Visual Tree in a MVVM-heavy app
By Tamir Dresher Visual Studio comes with a built-in Visual Tree Visualizer which is really useful, but in order to start using it you have to find a reference to the instance of the FrameworkElement (i.e. UserControl, Window etc.) that you want to visualize. Getting the reference to the desired FrameworkElement is especially hard if