OzCode

Debugging Complex code

Mon, 19 Sep 2016 16:56:00 GMT

OzCode Webinar - Debugging Complex Code

Understanding the state of your system is an important part of every debugging session. We want to know what the current values are, how they have changed over time and the difference between the existing state and the expected state.

Finding and fixing bugs becomes more and more challenging as the data becomes more complex and harder to understand, until we reach a point in which finding a single value is like finding a needle in a haystack.

Omer Raviv	Dror Helper

CTO & co-founder	Dev Evangelist
OzCode	OzCode
@omerraviv	@dhelper

OzCode allows you to easily find, compare and extract data to help you better understand how the system behaves, and quickly find and fix bugs – no matter how complex.

During this webinar, Omer and Dror will use OzCode’s intuitive features to handle some real-world problems, and show you how easy it is to get started and become a debugging magician!

Thursday
September 29th 2016

	Los Angeles	8 am
	New York	11 am
	London	4 pm
	Berlin	5 pm

Even more powerful LINQ debugging, now with Query Syntax support!

Wed, 20 Jul 2016 08:12:00 GMT

When we set our sights on improving LINQ debugging, we assumed that supporting LINQ's method-based Fluent API would be enough to please almost everybody.

Since we believe in creating features that our users actually want, we wanted to hear from actual, living, breathing, users. We gave our team this new version and sent them out into the world to show and demo the new feature, and gather feedback from C# developers. We gave our brilliantly insightful OzCode Magicians community a peek too. After a few weeks we felt good enough about the new LINQ debugging feature, and decided to launch our public Early Access Program so more developers (that means you) could tell us what they like and (more importantly) what they dislike about it.

We received excellent feedback from our users, and a lot of interesting ideas for improvements. One bit of feedback that kept on surfacing was the need to support the SQL-style LINQ queries - the so-called (at least by language geeks) "Query Comprehension" syntax.

And so we'd like to present you with the new version of OzCode EAP (v2.0.0.1826), which now also supports debugging the LINQ Query Comprehension syntax.

► Sign up for the Early Access Program and grab this latest build

To query or not to query, that is the question

When using LINQ to query, filter and transform collections, a developer has a choice between two flavours - the Lambda-filled Fluent API expressions, or SQL-like query expressions. A good example of the differences is shown in a post by Yan Cui, who is a functional programming expert:

Func<int, bool> isEven = i => i % 2 == 0;
int[] ints = new int[] { 1, 2, 3, 4, 5, 6, 7, 8, 9 };

// using Query expression
var evensQuery = from i in ints where isEven(i) select i;
// using Lambda expression
var evensLambda = ints.Where(isEven);

The choice of which flavour of LINQ to use depends on the developer's preference, as well as the nature of the problem. The fluent syntax is more terse, and tends to be preferable when the query is simple. However, some more complicated queries are much more easily expressed with the query syntax.

Consider the following code:

var aboveAverageStudents = 
    from department in StudentRepository.GetAllDepartments()
    let departmentAverage = department.Students.Average(student => student.Grade)
    from student in department.Students
    where student.Grade > departmentAverage
    select student.Name;

This calculates each department's average grade, and then returns the names of students with grades higher than the average - simple and readable.

Using the fluent API, the same functionality would look something like this:

var aboveAverageStudents =
    StudentRepository.GetAllDepartments()
        .Select(department =>
            new
            {
                Department = department,
                Average = department.Students.Average(student => student.Grade)
            })
        .SelectMany(arg =>
            arg.Department.Students.Where(
                student => student.Grade >= arg.Average));

Not as readable, now is it?

This is a good example of how the compiler is doing some fairly complicated magic behind the scenes to allow you to express certain ideas with the Query Syntax that would be a lot more difficult to express with the fluent API. For a full list of these transformations, check out this post by Bart De Smet of Rx fame.

With the new OzCode EAP, you can easily visualize the flow the LINQ query, using code annotations and the LINQ Analysis window:

► Sign up for the Early Access Program and grab the latest build

Which LINQ syntax is better?

There are scenarios which benefit more from using the query syntax, such as when working with join, multiple from clauses or (our personal favorite) using the let keyword. On the other hand, there are operations which only exist in the method-based API - Count, Distinct, First, Take to name a few. And of course some developers feel more comfortable with methods, while others who may come from the relational database world naturally prefer their queries to look more like SQL.

To get more information, one of our interns wrote a utility which scans GitHub projects and gathers statistics about LINQ usage (more on that in a future blog post!). Our intern found that both APIs were widely used, and in fact many projects used both, in many cases even within the same LINQ clause. The point is that you do not have to choose, since the two are not mutually exclusive and work well together.

So in summary, you can have both cakes and eat them too!

Download the latest OzCode EAP which supports both ways of debugging LINQ queries, try it out and let us know what you think!

Enter the era of LINQ debugging with the OzCode Early Access Program

Wed, 01 Jun 2016 21:11:00 GMT

Untitled Document.md

LINQ is awesome. It allows us to write powerful, succinct, and expressive code that’s a pleasure to read and maintain. When LINQ was first introduced, way back when in the days of yore (circa 2007), it ushered in a new day in C# development and opened up the new and exciting world of functional constructs to the unsuspecting masses of imperative C# programmers. Nine-ish years later, and you’ll be hard pressed to find a modern C# code-base that doesn’t use LINQ all over the place, and with good reason: LINQ code tells you the story of what we’re doing, instead of telling you the nuts and bolts of how we’re doing it. It’s the essence of clean code.

Debugging LINQ queries, on the other hand, is a completely different story. When you’re using LINQ, you’re essentially sacrificing the debuggability of your code for the readability of your code. If you F10 over a line of code that’s using LINQ - you’ve just performed a whole bunch of complicated logic, but the debugger won’t be helping you figure out what actually happened.

Over the years, developers have come up with a myriad of tricks to make debugging LINQ queries workable. Sometimes they put a breakpoint inside of a lambda expression and hit F5 repeatedly until the breakpoint hit is on the right item (or until their finger gets sore, whichever comes first). Sometimes they split a big query into several smaller queries to make things more workable. In some cases, they end up completely re-writing their LINQ query as imperative code (a bunch of foreach loops) to be able to figure out where things went wrong.

For the past several months, the OzCode team has been fully dedicated to changing the current state of LINQ debugging: our vision is that the more you use LINQ and the functional and beautiful declarative style of programming it enables, your code will actually become easier to debug and maintain.

Today, we’re excited to announce a new way to debug LINQ statements and we’d like to offer you a chance to try it out, by entering the OzCode Early Access Program.

Getting started

► Click here to sign up for the Early Access Program and grab the latest build

As a quick example, we’ve used a LINQ query to generate a FizzBuzz sequence.

Once you reach a line of code that contains a LINQ query, you’ll notice the new numeric indicators:

These indicators show you the number of items returned by each operator. Clicking on one of the numbers will open the LINQ DataTip, which will show you all the items that the LINQ operator produced, or all the items the operator consumed:

When we select an item from the list, the annotations on top of code will update to show us how that specific item “travelled” through the LINQ pipeline, showing us exactly what each lambda expression returned. This powerful visualization will help you instantly understand the flow of your LINQ query. For example, if we select the 3rd item, we can see how it fizzed:

You can quickly run through the different items by using your mouse wheel while hovering over the numeric indicator, like so:

You can also use the OzCode Search functionality to find a specific item in the list.

Get Ready to Fizz and Buzz

But that’s not all!

We’ve also added a new Tool Window that allows you to move through the query pipeline and see exactly what happened in each stage. On the left hand side, you’ll see all the items that came into the operator, and on the right hand side, you’ll see the items that came out of it.

Consider the following query:

var fizzy = Enumerable.Range(1, max)
    .Select(i => $"{i} -> {ToFizzBuzz(i)}")
    .Where(s => s.Contains("Fizz"))
    .ToList();

Opening the new tool window will show us exactly what items passed through the Where predicate and which items were rejected:

Debugging Exceptions in LINQ Queries

Some of the hardest bugs to tackle are when one of the items inside of a LINQ query causes an exception to be thrown…

Not anymore! OzCode will warn about the exception before it’s thrown, and show you what item caused the exception, enabling you to drill down and find all the information you need to make sure the bug won’t happen again.

In this example, OzCode is showing us that a NullReferenceException is about to occur inside the Where predicate, and we can quickly see that what's causing the issue here is that the Info Property of one specific Student object is null:

Wait, there’s more

As part of the Early Access Preview you’ll also get to see some of the new features that we’re going to introduce in OzCode 2.1:

For example, the new & improved Compare, which shows the differences between two (or three, or four) instances, or the same instance over time:

and Export, which enables you to create a textual representation of an object as C# code, Json or XML - this is super-useful when you integrate this new tooling into your Unit Testing workflow.

Found a bug in your debugging session? Spent 10 long minutes just tracking it down, and don’t feel like doing it all over again? Simply Export the faulty object which caused the error, copy-paste the exported output into a new Unit Test, and voilà! Instant regression test.

A few known limitations to LINQ Debugging

The LINQ feature only works in VS2015.
The feature works only with the Fluent Syntax of LINQ, and does not work with the Query Comprehension Syntax (The SQL-esque syntax).
When using a user-defined LINQ operator (meaning one that isn’t a part of Microsoft’s System.Linq), the feature does not show the links between the before and after of that operator (the purple lines in the above figure).
When the query needs to process a large set of data, the numeric indicators will show a question mark instead of the actual numbers, and only after clicking them to go into LINQ Analysis Mode the real numbers will be revealed.

Keep in mind that this is still an Early-Access-Preview release and as such may contain bugs. If you do find a bug, please let us know - we would like to fix it. Same goes with any thoughts you have on how we could improve the cool new LINQ visualization to better fit your needs!

That’s it for now, so go ahead, download the newly LINQified version of OzCode and let us know what you think!

Announcing the OzCode Magician Program

Tue, 17 May 2016 17:50:00 GMT

Meet the OzCode Magicians!

Since the very early days of OzCode, the developer community has been showering us with love and support, and we couldn’t possibly imagine being where we are today without your invaluable input.

Today, we are proud to announce the OzCode Magician (OCM) program, recognizing those individuals who, through their ongoing contribution and support, have helped us take debugging in Visual Studio to new heights.

OzCode magicians will receive exclusive access to new OzCode features and releases, and through their feedback they'll help shape the future of OzCode. As OzCode experts, they will also be our ambassadors, and use their expertise to help spread the word of Magical Debugging.

We hope this is just the beginning of a long lasting tradition of giving back to the community, and we look forward to an even more Magical future together!

Magically yours,
The OzCode Team

Announcing OzCode EAP - already supports VS15 Preview!

Fri, 01 Apr 2016 17:39:00 GMT

Hello from sunny San Francisco!

We are posting this entry straight from our expo booth at //build 2016, where our team is drawing quite a lot of attention and excitement, showing off OzCode’s capabilities and a snippet of what’s in store for the future of debugging in C#!

Since Microsoft released Visual Studio "15" Preview two days ago, our team has been frantically testing the latest build of OzCode, and we are more than happy to announce the release of OzCode EAP, which already supports VS15 Preview!

We are very excited about this new version, and the fact we’re able to put this beta in your hands less than 48 hours after Microsoft released their Preview.

Please note that this version of OzCode does not yet support the "Bootstrap Installer", but only the full VS15 Preview Enterprise edition.

And lastly, since this is an EAP (Early Access Preview), there might be a few wrinkles that we haven’t found yet, so please let us know if you run into any annoyances.

So, isn't it time to take it for a spin?

► Click here to Download the Early Access Preview bits, you'll find these and other new magic tricks inside:

Improved compare

Compare was always one of our favorite features and we wanted to improve its functionality and ease of use.

Once you choose an object, all comparable objects will be highlighted.

When comparing two strings, Compare will now launch your favorite external Diff tool, or Visual Studio's internal Diff tool, making it super easy to spot the difference between long strings, like two XML documents.

Currently supported options include Beyond Compare (v3 or v4), KDiff, WinMerge, Araxis Merge, and Tortoise. Don't see your favorite Diff viewer on the list? Let us know!

We've made it super-easy to compare different items inside collection(s). We've also added the ability to see the differences between up to 5 items, all at once!

Another improvement is that when you save a snapshot of a given object, it will now persist across debugging sessions! You can save a snapshot of an object, stop your debugging session and close down Visual Studio, and then come back the next day and compare a live object to the snapshot you had saved!

Export

This is another feature that we've been wanting to build for a long time and now it's finally here, allowing you to export objects to the format of your choice!

You can even export an object to C# code and easily create a Unit Test using the values from your last debug run!

We currently support JSON / XML / C#, and we’d love to hear what other formats you'd like to see supported.

For the JSON output, we’re using Newtonsoft.Json, the Json serializer everyone and their mother is using, which makes it super easy to work with.

Export to Excel

Another cool Export capability that’s limited to collections is the ability to Export to Excel. Want to figure out some irregularity in the List<T> that you’re looking at? You can now open up an Excel worksheet with all your data right from the debugger, in a single click, and easily take advantage of every tool Excel has to offer for analyzing it!

Even better Exception Highlighting

In OzCode v2.0, we’ve added some support for highlighting meaningful information about exceptions, such as highlighting which part of a statement was null when a NullReferenceException occurs. In v2.1, we’ve made a few very noticeable improvements.

First off, when an exception is thrown by a call to 3^rd party code, OzCode will highlight the name of the method in red! Additionally, if the exception is an ArgumentException, the problematic argument is highlighted in red as well. Here’s a real world example:

Or, if you break inside the method that just threw an ArgumentException, the parameter declaration itself will light up in Red:

Vector icons

In this version, we invested in making OzCode more high-DPI friendly. You’ll notice that all of the icons OzCode uses have been switched to a much-nicer-looking vector-graphics version! Note however, that in the Early-Access-Preview, the OzCode ToolBar itself is still not High-DPI compliant, but every other thing in OzCode should be. If you have any issues or notice any bad-looking visuals while using OzCode on a High-DPI environment, please let us know!

As with each release, this revision also includes a bunch of UI tweaks and improvements, as well as a general bump to the overall performance of OzCode. We are eagerly awaiting your feedback on these new features, and look forward to an even more exciting future for OzCode and Debugging!

Magically Yours,

The OzCode Team

OzCode v2.0 Webinar in German!

Mon, 22 Feb 2016 17:08:00 GMT

OzCode v2.0 - Zurück in die Zukunft!

We are happy to collaborate again with our good friend Philipp Dolder from bbv Software Services, and bring you a special OzCode v2.0 Webinar in German!

Read Phillip's announcement:

Hallo, ich bin Ihr Gastgeber, Philipp Dolder, Software Architekt bei der bbv Software Services. bbv Software Services ist ein Schweizer Software- und Beratungsunternehmen. bbv steht für Top-Qualität im Software Engineering und für viel Erfahrung in der Umsetzung. Mit den Niederlassungen in München und Berlin ist bbv auch in Deutschland zu Hause.

Philipp Dolder

Software Architect, bbv

@philippdolder

Mit OzCode v2.0 wurden viele neue Features entwickelt, welche die Produktivität der Entwickler weiter steigern.

Unsere Mission ist es, Entwickler darin zu unterstützen Bugs schneller und effizienter zu finden. Deshalb haben wir das Konzept eines "Head-Up Display" für den Debugger eingeführt, und mit vorausschauenden "Wahrsager" Fähigkeiten ausgestattet.

Diese Features stellen Entwicklern Echtzeit-Feedback über ihre Änderungen während des Debuggens zur Verfügung. Dauernde Neustarts des Debuggers werden damit überflüssig!

In diesem Webinar zeigt Ihnen Philipp Dolder, wie OzCode's "Predict" Funktionalität Sie in die Zukunft blicken lässt, und wie Sie mit "Magic Glance" die Vergangenheit erforschen.

Zu guter Letzt enthüllt er einen Prototypen eines neuen Features an dem das OzCode Team gerade intensiv arbeitet:

Eine völlig neue Art LINQ zu debuggen!

Freitag

26. februar, 2016

4:00 pm CET

OzCode v2.0 Webinar

Wed, 10 Feb 2016 16:06:00 GMT

Back to the Future Webinar

With OzCode v2.0, we’ve added many features that boost developers’ productivity.

Our mission is to to help developers find bugs quicker and more efficiently, and so we introduced the concept of a “Head-Up Display” for the debugger, and added predictive “fortune telling” capabilities.

These features give developers live feedback on the changes they make while debugging, eliminating the need to restart the debugger over and over again!

Omer Raviv	Dror Helper

CTO & co-founder	Dev Evangelist
OzCode	OzCode
@omerraviv	@dhelper

In this Webinar, Omer Raviv and Dror Helper will show you how OzCode's Predict lets you look into the future, and Magic Glance helps you investigate the past.

To wrap up, they will unveil a prototype of a new feature the OzCode team is working on:

A re-imagined LINQ debugging experience!

Wednesday
February 17th 2016

Check your timezone!
PST 8 am
ET 11 am
GMT 4 pm

Sweden here we come!

Tue, 25 Aug 2015 14:03:00 GMT

Attention magicians! OzCode is going on an extensive tour of Sweden, and you can catch us live in several locations!

The release of OzCode v2.0 is now behind us, and we figured this is a great time to take OzCode on the road.

The awesome guys at the Swedish .NET User Group (swenug) have invited our Chief Architect and Microsoft Regional Director, Alon Fliess, to speak at several of their meetups. In the talk, Alon will take a deep dive into the Visual Studio debugger, and share from his vast experience. Alon will also demonstrate how OzCode saves time and effort while actually making debugging (almost!) fun. You don't want to miss it!

So if you are in Sweden this coming September, here is when and where you can catch us exactly:

City	Venue (click for event page)	Date	Time
Gothenburg	WCOM AB	September 7th, 2015	17:30
Linköping	Combitech	September 8th, 2015	17:30
Örebro	Kvadrat	September 9th, 2015	17:30
Stockholm	Softronic	September 10th, 2015	17:30

Magically yours,

-The OzCode Team

OzCode v2.0 is released (Sim-shipped with Visual Studio 2015) !

Mon, 20 Jul 2015 18:59:00 GMT

It's been just over a year since v1.0 of OzCode was released, and we have come a very very long way since. Our team has been working around the clock to make v2.0 a huge step forward, significantly improving performance and adding some truly remarkable new features! As part of these improvements, we made the brave choice to re-write OzCode's core to use the new Roslyn compiler-as-a-service platform, and this decision has opened up countless ways in which we can make OzCode better.

Once again, if you already own a license to OzCode v1.0 – check your email. You’re going to find a really nice surprise waiting for you.

Big News for Visual Studio 2015 Users

Today is the day we’ve all been waiting for – Visual Studio 2015 RTM has finally arrived. And… OzCode v2.0 is released right along with it, with full support for the VS2015 RTM.

If you’re currently using the VS2015 RC, you’ll have to upgrade to the RTM before you can use the version we released today.

Once you do, you’ll notice this very pleasant surprise: In VS2015 RTM, OzCode’s Predict will work in situations it never worked before, and will be able to predict results of 3rd party methods, such as LINQ operators:

So, let’s recap. Here are some of the main highlights in v2.0:

Magic Glance

Our most revolutionary feature for v2.0 is definitely Magic Glance which can be toggled by clicking the icon (or by pressing the + + shortcut).

Magic Glance gives a new meaning to the term Live Coding by showing you a summary of each line as you step through the code. It makes fixing small silly mistakes extremely intuitive, by pointing them out before they cause a problem!

Simplify 2.0

Following your feedback, we've given the Simplify feature a major face-lift, making it more intuitive and accessible. You can now use the arrow keys to navigate Simplify, and a red/green color coding will tell you exactly which expressions returned false/true, respectively. The red or green indicate the result of the entire expression.

Moreover, Simplify will now show you a historical view, as you step through the code. No longer will you have to restart debugging if you've stepped over too far, simply click the icon, and OzCode will show you what has happened in previous steps.

If you're a keyboard person, we've made some useful shortcuts for you to time travel without lifting your palms: Hit + to visualize the current line and then use + or + to navigate between the different lines of code.You can also hold down the key while debugging and then tap a digit ( - ) to directly pick the statement to visualize.

Predict

With v2.0, we've added Predictive analysis of code execution (or as we prefer to call it: Fortune telling!) to OzCode's capabilities. The predict feature can tell you what's about to happen in the debugger.

In the following switch statement, you can see the arrow pointing to where we're going to go when we hit F10, and irrelevant code paths are made semi-transparent.

So what are you waiting for? Start your free and fully functional 30 day trial now!

Let us know what you think by leaving a message on our UserEcho page, sending us an email or contacting us through twitter or facebook.

Magically yours,

- The OzCode Team

A new v2.0 beta is out, and it's the most exciting one yet!

Thu, 09 Jul 2015 17:19:00 GMT

We are extremely thrilled to announce a new version of OzCode v2.0 beta!

In this version, we are finally unveiling the final piece of the OzCode v2.0 puzzle, with two fabulous new features, Historical Simplify and Magic Glance, which work together to give you a whole new experience of debugging and live-editing your code!

These features are only supported on VS2013 and VS2015.

OzCode’s HUD Gets a Makeover

We went ahead and gave our UI a nice little make-over, for a more minimalistic look and feel. We think it looks awesome, what do you think? Sound off in the comments below.

Historical Simplify

We've all been there. You find the bit of code you want to debug, put a breakpoint, start debugging it, and suddently get a sharp pain in your neck when you realize you stepped over too far, and now you’re going to have to restart the whole thing.

Never again!

With this update, as you step through code, OzCode will remember what happened in each step, and by clicking the glasses icon, it will show you a historical view:

Don’t want to use the mouse? You can use a set of keyboard shortcuts to travel through time and see what happened! Hit Alt+Q to visualize the current line of code. Or, hold down the alt key while debugging, and then tap a digit (1 – 9) to pick the statement you want to visualize, 1 being the most recent.
Alternatively, you can just use the Alt+Up Arrow or Alt+Down Arrow to navigate between the different lines of code!

Magic Glance

When you turn on Magic Glance, OzCode will show you a summary of each line as you step through code:

The Magic Glance feature brings a whole new meaning to the term “Live Coding”. This makes fixing “stupid little programming mistakes”, like forgetting to add a null-check, really intuitive. In the next example, we accidentally put a larger-than instead of smaller-than. The Magic Glance makes this very easy to see, and Edit & Continue lets us fix this on the fly:

These are very exciting times for us at OzCode, and we can't wait to hear your thoughts on this latest release. As we near the full release of v2.0, which will be Sim-shipped with VS2015, we would really appreciate any feedback you could give us.

So what are you waiting for? grab the new v2.0 beta, and let us know what you think!

Magically yours,
The OzCode Team

OzCode is heading to Florida, catch us live!

Wed, 08 Jul 2015 16:01:00 GMT

We are on tour again!

The last several months have been hectic here at OzCode, as we near the full release of v2.0, which will be sim-shipped to support Visual Studio 2015 RTM upon release. We have some more magic up our sleeves which we are dying to share with you - do stay tuned!

In the mean time, we are excited to be attending this year's Microsoft Worldwide Partner Conference, which will take place in Orlando, Florida, between the 12th and 16th of July. If you are attending the conference and still haven't heard of OzCode, or did not have the chance to see it all of its features in action, we'd love to give you a grand tour! Simply sign-up here and we'll get back to you with a time and a place for the demo.

If you are in Florida but can't attend the conference, our Chief Architect and Microsoft Regional Director, Alon Fliess, has been invited to speak at several User Groups in the Sunshine state. During the talk, Alon will take a deep dive into the Visual Studio debugger as it applies to .NET programs, and give an in-depth demo of OzCode, showing all of the game-changing features we've added towards v2.0. You don't want to miss it!.

Here is your chance to catch this great talk live (hurry, spots may be limited!)

Where?	User Group (click to register at the event page)	Date	Time
Deerfield Beach	Fladotnet	Monday, July 13th	6:30 PM
Jacksonville	Microsoft Developers User Group	Tuesday, July 14th	6:00 PM
Tampa	Tampa - C# and .NET	Wednesday, July 15th	7:00 PM
Orlando	ONETUG	Thursday, July 16th	6:00 PM

Stay tuned for a lot more exciting news to come in the next weeks, we can't wait!

Magically yours,
-The OzCode Team

Great news: OzCode v2.0 beta now supports VS2015 RC!

Fri, 01 May 2015 14:52:00 GMT

We are very happy to announce a new v2.0 beta release, which now includes support for Visual Studio 2015 Release Candidate! It has been a race against the clock to finish up this release before catching a flight to San Francisco, where our team is now proudly showing off OzCode's latest and greatest at Microsoft //Build Developer Conference 2015.

You will notice that the Reveal feature is not yet supported in VS2015, but we are working on this with the debugger team at Microsoft. We promise to bring it back as soon as we can, and guarantee that it will be fixed in time for the Visual Studio 2015 RTM release. The other features are all working great in VS2015, but don't take it from me: Try v2.0 beta for yourself :)

This version also fixes some conflicts we had with other 3rd party extensions (e.g. CodeMaid) in the previous update. If you've had an issue where you installed or updated the beta and none of the features worked, it was probably caused by this conflict. Please do try again with the new bits!

And now for the real icing on the cake: We can proudly announce that for the first time in our history, we will be sim-shipping a version of OzCode v2.0 that fully supports the Visual Studio 2015 RTM when it comes out. This is a great milestone for us, and we hope it sets a standard of ensuring support for new versions of Visual Studio as they are officially released.

Check out the News section on our site for more exciting things to come, or even better - follow us on twitter to see what our team is up to :)

Magically yours,
-The OzCode Team

OzCode v2.0 Beta is out!

Thu, 26 Mar 2015 19:31:40 GMT

Wow. We’re finally here.

It’s been a long time coming, since the release of OzCode v1.0 last June, but the OzCode v2.0 beta is finally out!

First, an announcement: if you already own a license to OzCode v1.0, check your email. You’re going to find a very pleasant surprise :)

If you don’t own a license but want to buy OzCode v1.0 now, don’t worry - you will get a free upgrade to v2.0 when it comes out!

Now that that’s out of the way:

Oh, what a long and winding journey it has been. Our development cycle for v2.0 began with a hard choice we had to make. In order to support the upcoming C# 6 language features, we knew we had to either upgrade our existing parsing and semantic analysis facilities (which were based on an old version of the open source NRefactory library), or take the plunge and re-write OzCode to use the new Roslyn compiler-as-a-service platform from Microsoft (which would be a huge undertaking, made even harder by the fact that Roslyn officially only supports VS2015, but we still needed to support VS2010, VS2012 and VS2013).

This wasn’t an easy decision to make. In fact, it was probably the toughest call we’ve made since we started OzCode. On the one hand, we knew the rewrite would take a lot of time, meaning we couldn’t keep up with the regular pace of releases we wanted to (until now, that we’ve finally reached the other end of the tunnel). On the other hand, we knew that ultimately, betting our future on Roslyn will lead to huge wins down the line – in terms of performance, reliability, and extensibility.

We reasoned through every possible alternative, thought about every technical problem we’re going to face, made pros and cons matrices befitting a NASA space exploration mission. Finally, we made a strategic decision to rewrite the internal workings of OzCode to take advantage of Roslyn. The decision has more than paid off. We even had a few surprises along the way – at one point, we found out that some behavior we needed to get out of Roslyn was not there. After a discussion with the Roslyn team, we asked for a not-so-trivial change, and then plunged into the Roslyn codebase and sent them a Pull Request. Our request was accepted, and the experience made it very clear to us that there is indeed a completely new and transformed Microsoft.

So, here we are, and here is a small taste of the new features we’ve added in v2.0:

Heads-Up-Display for the Debugger

Hit the new “Toggle Head Up Display” button to lighten up your Visual Studio code editor with useful information.

For example, you’ll see a HUD visualization on top of method parameters:

The Foresee feature has also been transformed into a HUD which shows you not only what iteration we are at, but what the current value in the loop is:

Predict – Predictive Analysis of Code Execution

With this feature, OzCode has now become a full-fledged fortune teller. “Predict” can tell you what’s about to happen in the debugger.

For example, in this switch statement, the arrow tells us where we’re going to be when we hit F10, and the irrelevant code paths are made semi-transparent:

Predict also works on ‘if’ statements, showing us what the condition is going be ahead of time, where possible. This works great with Edit and Continue, creating an awesome experience of instant feedback while you’re fixing buggy code.

Ahead-of-time warning on imminent exceptions

A picture’s worth a thousand words:

After you step over the line, and the exception actually happens, you’ll see this:

Want to just keep going and ignore this exception for now? Hit the downward-arrow button to revert the exception and skip to the next line!

Simplify, Simplified:

We’ve heard your feedback that Simplify is sometimes hard to navigate, and gone the extra step for you: you can now use the arrow keys to navigate Simplify much more intuitively than you could before.

We’ve also added super-useful red/green color-coding which tells you exactly what expressions returned true/false, respectively:

No More Enhanced Mode in VS2013 and upwards

Historically, one of the biggest pain points for OzCode users has been “Enhanced Mode”, which had to be enabled in order to take advantage of Simplify and Foresee, but caused performance degradation in some cases. In v2.0, if you’re using Visual Studio 2013 or higher, Enhanced Mode is no longer required, and it’s gone! From now on, Enhanced Mode is only a legacy mode that exists in VS2010 and VS2012.

Break whenever a value of a property changes (C# ‘Data Breakpoints’)

Ever wanted to tell the debugger, “Break when this value changes?” Now you can! Introducing Setter Breakpoints:

As you can probably tell from the pictures, Setter Breakpoints work on every property, even auto-properties, and even properties in 3rd-party libraries for which you don’t have the source code! Go to the “Magic Wand”, and choose “When Set… –> Break” to get started!

Dark Theme Support

Yes, we know. OzCode has been kind of a sore sight in Dark Theme in v1.0. That’s no longer an issue in v2.0. Here’s proof:

Visual Studio 2015 Support is Coming Soon

While not included in this initial beta, Visual Studio 2015 support is coming very soon! We’ll be keeping you updated via the News section on our site, Twitter and Facebook.

So, what are you waiting for? Go and grab the v2.0 Beta bits from our homepage!

OzCode Webinar in German!

Tue, 15 Jul 2014 14:41:37 GMT

We are happy to announce that, in co-operation with bbv, we will be hosting a Webinar on OzCode v1.0 in German, presented by our friend Philipp Dolder.

Here is the full announcement from Philipp:

Hallo, ich bin Ihr Gastgeber, Philipp Dolder, Software Architekt bei der bbv Software Services. bbv Software Services ist ein Schweizer Software- und Beratungsunternehmen. bbv steht für Top-Qualität im Software Engineering und für viel Erfahrung in der Umsetzung. Mit der Münchner Niederlassung ist bbv auch in Deutschland zu Hause.

Seien Sie dabei, am Mittwoch, dem 30. Juli um 17:00-18:00 CEST, am allerersten deutschsprachigen Live Webinar zu OzCode.

In diesem Webinar zeige ich Ihnen einige der besten Features von OzCode v1.0. Sie lernen, wie Sie mit OzCode alltägliches Debugging effizienter und effektiver gestalten und so Fehler schneller finden und korrigieren können.

Das Zielpublikum sind alle .NET Entwickler, die schon einmal Zeit im Debugger verbracht haben, also Sie.

Bei Fragen wenden Sie sich bitte direkt via Twitter oder E-Mail an mich.

Beeilen Sie sich, die Anzahl der Plätze ist beschränkt. Melden Sie sich jetzt fürs Webinar an.

OzCode v1.0 is Released!

Tue, 24 Jun 2014 13:16:19 GMT

Following a great effort from both the product team and early adopters, we’re excited to finally announce that OzCode v1.0 is officially released and available for download!

It’s been a long journey for us! We’ve been working tirelessly to bring you a rock-solid debugging experience in Visual Studio, and now we’re at the finish line!

We would like to sincerely thank each and every one of you – our early adopters, people who tried our beta releases and submitted feedback – you made this possible, we couldn’t have done it without you!

Special Early Adopters Discount

To express our gratitude, we would like to announce that the first 5000 buyers will get a 30% OFF on their purchase of a personal or corporate licenses! Hurry up, and purchase a license now!

OzCode Instructional Videos

One of the difficulties in creating a tool that challenges and improves the way you are used to do things is to make the changes subtle, yet visible enough, so they become a part of your everyday use. OzCode has lots of great features, and we wanted to have you start using them immediately! This is why we teamed up with Mark Rendle of zud.io, a Microsoft MVP, public speaker, and creator of the open source Simple.Web and Simple.Data frameworks, to record a series of instructional videos, demonstrating various OzCode features, and showing you how to get started quickly. Mark was one of our earliest adopters and has been putting OzCode through its paces on all his projects since the first beta release!

For a sneak peek of some of the videos, check out or Videos page. More videos coming soon!

What’s new in OzCode?

If you’d like to see some of the new OzCode features in action, watch the recording of our very first webinar, where we show you OzCode’s Magical Debugging experience in Visual Studio.

You must be itching to try out the new version. Go ahead, download OzCode v1.0 now!

Magical Debugging,
–The OzCode Team

Live Webinar: Magical Debugging with OzCode

Sun, 01 Jun 2014 14:28:33 GMT

Hello, I’m your host, Igal Tabachnik, one of the OzCode developers, here to tell you what we’ve been doing lately. Join us Thursday, June 19th, 15:00 – 16:00 GMT for our very first live webinar, where we’re unveiling OzCode v1.0!

In this webinar I will show you for the first time some of the coolest features we’ve been working on. You will learn how OzCode helps you to turn everyday debugging tasks into a pleasurable experience, how to find and fix bugs faster than ever before!

The intended audience are all .NET developers who have ever spent inordinate amount of time debugging their code, which means you!

Please contact me directly via twitter or email if you have any questions, or contact us directly at support@oz-code.com!

Hurry up, space is limited; please sign up for the webinar now!

Simplify, simplified!

Wed, 28 May 2014 10:45:44 GMT

We’ve just released a new update of OzCode, which includes a multitude of bug fixes, and also:

Keyboard Shortcut Galore

‘Simplify’ now lets you use the debugger to inspect variables and method return values comfortably without constantly dragging the mouse to hover over the variables (or glimpsing at the Autos/Watch window).

As you Step Over code, hit Alt+J to start viewing the values. Once the Simplify visualization appears, use Alt+J to go one level down, Alt+K to go one level up through the visualization. If you’re looking at a long expression that spans several lines of code, hit Alt+Shift+J to go one line downwards, and Alt+Shift+K to go one line upwards.

Check out this video and start practicing the new keyboard shortcuts!

Furthermore, as you can see in the video, Simplify annotations now automagically expand the code slightly to let you see the full value of the expression.

Keyboard Bindings

We Just Phoned This In

OzCode now supported debugging Windows Phone 8.1 apps! We’ve added Simplify support when debugging both Windows Phone 8.1 and Windows Phone 8.0, you’ll just need to install Visual Studio 2013 Update 2 to see it!

As usual, we’re eager to hear what you think about new updates!

Magical Debugging,

- The OzCode Team

New OzCode 1.0 Beta Release: UX Makeover Galore!

Tue, 13 May 2014 11:48:36 GMT

The wait is over! New OzCode 1.0 Beta release is here!

We’ve been hard at work on OzCode as we’re nearing the v1.0 Release, and one of the most pressing issues we faced was to streamline the user experience. One of the most important things for us is stay out of your way as much as possible, yet be there to provide you with most contextual assistance. We’ve done a lot of work analyzing and improving the OzCode experience, based on your feedback, and we believe we’ve managed to blend usefulness with simplicity!

Here’s what’s new in this version:

Magic Wand

The Magic Wand becomes available when hovering over any field or property within the DataTip, and it allows you to quickly perform most contextual operations that are available, without ever leaving the DataTip! Things like Showing all instances of the variable’s type, creating a Conditional Breakpoint on its value or tracing a value are now all conveniently available in one place.

One of the property values looks strange? Want to see how it’s calculated? You can Go to Definition of that property, and it will take you to the place in code where this property is defined!

If the value is a collection, you can create a filter to select only the items you want to see:

QuickActions Improvements

We’ve received a lot of feedback about OzCode’s QuickActions, and made numerous improvements!

First, QuickActions now live in their own margin on the left side, never obstructing any code from view:

Selecting any one of the more contextual actions will underline the expression it applies to.

Next, we’ve added a new class-level QuickAction, to allow you to quickly add (or remove) breakpoints in every member in class!

In addition, new margin items now appear on fields, properties, and methods and classes and offer useful QuickActions.

Finally, we made most of those QuickActions visible to you by default during debugging (break mode), and they will not appear while you’re editing code (design mode), however even when writing code, QuickActions are still available to you by pressing the QuickActions shortcut Ctrl-Alt-D.

Search Improvements

We’ve made lots of improvements with the Search, Compare and Show all Instances features, by allowing you to cancel the search (if it takes too long), or skip any property which takes too long to evaluate, to avoid a time-out.

Miscellaneous

Many more bug fixes and improvements added, too numerous to mention! As always, you can read the latest Version History.

We Want You! (to tell us what you think)

As we’re nearing our first public release, we’d like to remind you that OzCode is FREE while in Beta, which means you can use it without a license key, until OzCode v1.0 is released. During this period, we urge you to contact us via UserEcho, Twitter or Facebook to let us know if you have any issues or suggestions!

Magical Debugging!
-The OzCode Team

New Beta release: Big news for Visual Studio 2013 users, tons of improvements!

Mon, 03 Mar 2014 08:56:00 GMT

We have just released a fresh beta release, with tons of improvements! You can find the complete changelog here, and download the new version from our website.

With this out of the way, let us tell you about the incredible news we have for our Visual Studio 2013 users: Simplify now works in Standard Mode!

One of the first features we’ve ever implemented in OzCode (back when it was called BugAid) was the ability to visualize method return values. We wanted to know what value the function returned, but without messing up the code by creating temporary variables or adding things to the Watch window. Simplify allows the user to see the return values of all method calls that were executed during a step-over, along with the value of every calculation or sub-expression. However, until now, Simplify required our profiler-assisted Enhanced Mode to operate. This meant a slight performance hit, no Edit and Continue, and an inability to work side-by-side with IntelliTrace.

Visual Studio 2013 introduced a new feature, allowing you to see function return values in the Autos window. We decided to take advantage of this new API, and we’re happy to report that starting from Visual Studio 2013, our Simplify feature no longer requires the profiler-assisted Enhanced Mode, and works by default in Standard Mode! This means that there are:

No performance penalty since we no longer need to use the profiling API for this
Edit and Continue now works hand-in-hand with Simplify (where supported)
Simplify now works in Windows Store apps too!
No compatibility issues with IntelliTrace
Lots of other improvements:

Working with Simplified results

The first improvement, is we are now able to display the ToString() value of the returned expression. This means that in case of this LINQ statement, instead of the ugly LINQ enumerator type name, you can now see useful data! You can choose to focus on any part of the statement using the up/down arrows (or by pressing the Numeric +or - keys):

Next, we made it possible to interact with the displayed values, by allowing the user to drill-into and explore the results. Hovering over any part of the visualized results can show you a DataTip. You can use all the familiar features, such as Reveal or Search, to narrow down the results and find the value you’re looking for faster:

See it in action:

In addition, we’re can now show you the values of ref/out parameters:

A few caveats: this is only supported for .NET 4 and above. In addition, Simplify doesn’t currently work in Silverlight apps (in Standard Mode) or Windows Phone apps (neither in Standard nor Enhanced mode). Lastly, Simplify in Standard Mode doesn’t currently display return values of structs, this is due to a limitation in Visual Studio. Please vote on this issue and ask Microsoft to fix this limitation!

Show Runtime Value

We’ve added a new way of showing you the runtime values of a property or a field in all instances of an object! To get started, while in break mode, navigate to the property you’re interested in, and using the QuickActions menu, select the Show Values of X in All Instances menu:

This will open the Show All Instances dialog, displaying the selected property value of all instances of the object. In addition, it will show any Revealed properties:

Add Conditional Breakpoint

Now you can also create a conditional breakpoint straight from the debugged value – simply right click on the value inside our DataTip, and select Create Conditional Breakpoint:

This will open the Visual Studio’s Breakpoint Condition dialog with a pre-defined condition, which you can further refine it to suit your needs:

Your Feedback Wanted!

We wish to remind you that OzCode is FREE while in Beta, meaning you can use it without a license key. During this period, we urge you to contact us via UserEcho, Twitter or Facebook to let us know if you have any issues or suggestions!

Magical debugging!
-The OzCode Team

4 Common .NET Debugging Mistakes You Should Really Stop Making

Wed, 29 Jan 2014 16:13:17 GMT

By Michael Parshin

The goal of this post is to give a short overview of common mistakes we, .NET devs, tend to make over and over again while debugging our beloved products, day in, day out.

Debugging the whole system instead of using unit tests

Reproduce, debug, fix, debug, fix, … start the whole system and try to reproduce the buggy behavior, wait until that happens, and then the debugger crashes exactly when you try to check the value of the third element in the array… Sounds familiar? It is a tough and time consuming process, and unfortunately we all go through this vicious cycle, so what could be a solution?

I believe most of us are familiar with Unit Tests and Test Driven Development concepts, however there are lots of projects out there without even a single test! If your team culture does not allow you to write tests before your write any production code, or even write tests right after you finished writing it – then start writing tests for debugging purposes! When it’s time to fix the next bug, do not step in into debugger, do not prepare some side console app, just open a new test project and start writing unit tests that isolates the issue. Then, you can debug those tests with much less effort and most importantly, the tests you wrote will be yours to keep, and protect you from regressions. When you or your coworker make some unrelated change that re-introduces the same nasty bug all-over again, you’ll know about it!

As you write more tests, you’ll notice that tests are actually valuable in many other ways – they help you express what your code does (or at least, what it ought to do), they serve as documentation for others, showing them how to use your code, and they help verify the SOLIDness of your design.

Jumping right into the debugger before checking logs

Concurrency issues are hard to reproduce and even harder to debug. While most of the work should be done upfront, making sure that our architecture and design do not lend themselves to concurrency mayhem, we may still find ourselves struggling with concurrency related errors. Stepping through a multi-threaded app is like juggling 10 balls at once. What’s worse is that having a debugger attached will definitely impact each thread’s execution time. One of the best solutions for debugging concurrency-related issues is logging. Nothing beats reading through a linear, step-by-step account of the events that lead up to the software failure. There are plenty logging platforms out there (like NLog and log4net) which can be easily incorporated into any .NET application. However, adding lots of logging statements for the purpose of making the application more easily debuggable often becomes a maintenance nightmare, and many times programs become overflowing with context-less and confusing logs.

In some cases it is handy to use additional tracing mechanisms like Trace Points in OzCode.

Lets consider typical race condition scenario:

class Program
{
    private static int _counter;

    static void Main(string[] args)
    {
        Parallel.For(1, 300, IncreaseCounter);

        Console.WriteLine(_counter);

        Console.ReadKey(true);
    }

    private static void IncreaseCounter(int i)
    {
        Thread.Sleep(5);

        _counter++;
    }
}

In some cases the output of this program will be a number that is less than 300. Since we’re not really sure why this might be the case, Trace Points can help us investigate! So lets put one in the beginning of the method, by using the Trace every entry… Quick Action:

…and then once the program reaches the call to the WriteLine method we can check the “Trace Points Viewer”, which is essentially a fully-featured log-viewer that’s built into Visual Studio:

Here we can see how many times the function was actually executed and in which thread, look at call stack, execution time-stamp and the trace message. You could also export the data as .CSV and open it in Excel, for instance. Double-clicking on one of the messages takes us right to the line of code from which it was written!

Trying to fix performance related issues without metrics

Another area that is hard to debug is performance. Some programs have specific performance requirements, such as: “The application needs to process 100 orders per second”. OK, so we write the program that can process orders, we test it (hopefully with unit tests) and make sure that the core logic works, and then… then it is necessary to perform good stress tests and demonstrate that it can indeed do a hundred orders per second over time. In most cases we’ll end up needing to set up monitoring in production, to see that there is no other activities on the OS which steal our app’s resources.

Logs or traces may not be a good diagnostic tool in this case, since there is nothing (out of the box) which can take a log file and tell us what the performance rates and metrics are right now. In addition, adding excessive logging to the app can in itself have a non-negligible overhead on performance.

So what’s the solution? Performance counters can be a big help. I would recommend you use them during development, testing, and production monitoring. Add custom performance counters to your application which describes what your application does and how well it performs.

Often times, it is not trivial to define a comprehensive set of performance counters upfront. Continuous investigation and improvement are the way to go. It is a good idea to leave these counters on after development is finished, because your application will not live in a vacuum; there are tons of things which may impact performance, and thus your custom counters will do a great job for maintenance and on-going monitoring.

The nicest thing about performance counters is that they enable you to easily monitor your own application-specific and business-centric counters against the built in counters, such as those that relate to GC, Exceptions, Threading, etc, and they give you all this rich information with only a minimal impact on your application.

Losing valuable information whenever the application crashes

I guess you had a chance to see this message box come up once or twice . If it happens on a developer machine we will have the option of debugging the app to find out what happened. But what if the crash happens in a QA environment, or worse – in production? The most important thing is not to lose the data and find out the reason of the crash. Post mortem debugging can help us investigate the crash after it actually happened. The only thing you need is a dump file. Unfortunately dump files are not created automatically and some configuration needs to be done in order to make this happen. There are number of tools that can produce dump files, my favorite is ProcDump - it is small and easy to use. To register ProcDump and start gathering dumps you have to call this command:

C:\>procdump mp -i c:\dumps

Next time any program will crash, a mini dump will be created under C:\dumps [make sure the folder exists before you begin].

Now that we have dump file, what next?

If WinDbg is still not installed on your computer, this is the time to do it. It is an outstanding tool which gives you a lot of power. I am not going to cover WinDbg in this post (which would be impossible even if I tried), but I really suggest you go and learn abut this tool. There are many good guides and technical information around.

Lets write a simple program that will generate a second chance exception:

class Program
{
    static void Main()
    {
        int a = Compute(100, 10);

        a = Compute(a, 0);

        Console.WriteLine(a);
    }

    static int Compute(int a, int b)
    {
        return a/b;
    }
}

Once the program executes, a dump file will be created under c:\dumps. Lets open it and investigate it in WinDbg.

First we need to load the SOS extension, as it helps a lot in debugging managed applications. Use .loadby sos clr if you app is x64 or .loadby sos mscorwks for x86.

With WinDbg, we can do a million and one things, but to get started, we can print out the exception details:

0:000> !pe

Exception object: 0000000002ea2e78
Exception type:   System.DivideByZeroException
Message:          Attempted to divide by zero.
InnerException:   <none>
StackTrace (generated):
    SP               IP               Function
    0000000000CCEED0 000007FE087C0150 Crash!Crash.Program.Compute(Int32, Int32)+0x40
    0000000000CCEF10 000007FE087C00D8 Crash!Crash.Program.Main()+0x48

StackTraceString: <none>
HResult: 80020012see the call stack with function properties values:0:000> !CLRStack -a
OS Thread Id: 0x720 (0)
        Child SP               IP Call Site
0000000000cce980 000007fe7886319b [FaultingExceptionFrame: 0000000000cce980] 
0000000000cceed0 000007fe087c0150 *** WARNING: Unable to verify checksum for Crash.exe
Crash.Program.Compute(Int32, Int32) [C:\Users\MichaelP\Projects\ConcurencyErrors\Crash\Program.cs @ 18]
    PARAMETERS:
        a (0x0000000000ccef10) = 0x000000000000000a
        b (0x0000000000ccef18) = 0x0000000000000000
    LOCALS:
        0x0000000000cceef0 = 0x0000000000000000

0000000000ccef10 000007fe087c00d8 Crash.Program.Main() [C:\Users\MichaelP\Projects\ConcurencyErrors\Crash\Program.cs @ 11]
    LOCALS:
        0x0000000000ccef30 = 0x000000000000000a

0000000000ccf230 000007fe67e77d93 [GCFrame: 0000000000ccf230]

I highly suggest you configure your QA lab’s computers with ProcDump to collect dumps, so that the next time there is a crash you will have data to work with and so you’ll be able to solve the problem much faster. In addition, many time crashes are not easily reproducible, so it will save QA efforts as well. Dumps can also be opened in Visual Studio, which can be very useful, but mastering WinDbg gives you unprecedented powers of introspection.

Conclusion

While having unit tests may save you some time in debugging, there are still plenty of possible issues we may encounter during an application’s lifecycle, which can hardly be covered by unit tests. Performance issues, memory/resource leaks, crashes and hangs – all of these are the sort of bugs where the plain old debugger is not the best way to go. Do not step-in into the debugger as a knee-jerk reaction, just because you can, but choose the right tool for each job.

Happy debugging!

Michael Parshin is a Senior Consultant at CodeValue.

Michael specializes in enterprise system architecture, software design and development methodologies. He has in-depth knowledge in the .NET framework, C#, WCF and other technologies and development environments. Michael holds an MSc degree in Applied Mathematics from BIU (Bar Ilan University, Israel).

Blog: http://michaelparshin.blogspot.co.il/
LinkedIn: http://www.linkedin.com/in/michaelparshin