Three month ago OzCode launched it’s new version 3.0, that introduced the new LINQ Debugging feature. This was a breakthrough in the LINQ debugging experience, and we’ve been hearing feedback from customers who tell us that it’s been a life-changing feature to them – allowing C# devs to visually break down and understand each and every
LINQ is amazing, it give C# developers the ability to write readable, concise, declarative code. Since it was introduced into the C# language LINQ has become widely used and loved. Unfortunately, there’s one issues when using LINQ as anyone who ever tried to debug LINQ knows – it’s hard, sometimes impossible, to effectively debug LINQ
Introduction At some time of the day, you are bored and the procrastination demon takes care of you. You go to Facebook (or Twitter, you can choose :-)) and start taking a look at the updates. After some time, you have checked all new posts and start to press F5 to refresh the page and
It’s official – the next version of OzCode, the coveted v3.0, will be shipped simultaneously with Visual Studio 2017 on March 7th, 2017. Our new version contains a lot of goodies that reinforces the Visual Studio debugging experience! Check out these amazing new features that give you phenomenal debugging power. So, what have we got?
A quick recap – we’ve written a small application to analyze how C# developers are using LINQ. if you haven’t read the first part and want to learn about how we did it go to the previous blog post: Analyzing GitHub LINQ usage – Introducing LinqAnalyzer. But before we begin let’s discuss what exactly happened once
Are you a C# developer? If you are reading this blog, we bet you are. Do you use LINQ? If you do, you know that while LINQ’s declarative nature makes very readable code – it’s almost impossible to debug. That’s why we felt that no debugging tool (e.g. OzCode) will be complete without the ability to
There are 10 types of developers; those who work in a higher level and depend on abstractions, and those who work with the bits and bytes alongside the bare metal. As a C# developer, I am one of the former, and I usually try to abstract everything I do. A few weeks ago, I figured
How many times has your “mission in life” been to continue a project that another company, client or some other colleague programmer wrote? My guess is… a lot! But, before you can start fixing the code or writing some new stuff, you probably need to understand exactly what is going on and this can frequently be