JetBrains dotPeek

redgate‘s decision to start charging for their Reflector .NET decompiler sent ripples through the .NET development community. Personally, while I do not think that the 25-69 EUR price is outrageous, I must agree with many people – redgate promised to keep Reflector free after the acquisition.

But, whatever happens, happens for the best. New decompilers started appearing like mushrooms after the rain, and JetBrains, the famous maker of e.g. ReSharper and TeamCity, came with its own free dotPeek decompiler, which is in the EAP or Early Access Program stage now. Knowing and using JetBrains’ products, I believe that dotPeek has all chances to become the de-facto standard for a .NET decompiler eventually, so I will keep an eye on it.

Task Parallel Library / TPL

It has been very long since my last post here – I was really busy at work. But I will try to “fix it”! :)

I don’t know where Sacha Barber finds time for all his articles and “hobby” projects, but I am glad he does! One of the latest subjects of his investigations is Task Parallel Library (or TPL in short), one of the new parts of .NET 4:

  1. Part 1: Starting Tasks / Trigger Operations / Exception Handling / Cancelling / UI Synchronization
  2. Part 2: Continuations / Cancelling Chained Tasks
  3. Part 3: Parallel For / Custom Partioner / Aggregate Operations
  4. Part 4: Parallel LINQ
  5. Part 5: Pipelines
  6. Part 6: Advanced Scenarios / v.Next for Tasks

Managed/Native Debugging in C#/C++

I had a problem debugging my solution consisting of C#, C++/CLI, and native C++ projects. I was not able to get breakpoints working in the native C++ parts – after running the solution with breakpoints set, they were turning gray with warning sign, and their tooltip stated that “The breakpoint will not currently be hit. No symbols have been loaded for this document.” despite all debug properties were set right on those projects and all debugging symbols existed. After fighting it for a few hours and almost giving up, I started to think that the problem might not be with the native C++ projects, but rather somewhere else, e.g. in the StartUp project, which is C#. Checked that project’s properties, and guess what! Debug > Enable unmanged code debugging option was off!!! Switched it on, and voila – breakpoints work fine in native C++ DLL now!!! :)

How to Enable Using the Binding Builder in WPF and Silverlight Applications

In VS2010, when the Data Sources Window is used to generate the UI, the generated XAML injects design-time information so that the Binding Builder can be used to create bindings for the UI controls. But if your application was written in Visual Studio 2005 or 2008, or you used the XAML Editor, the Designer or Expression Blend without the Data Sources Window, your coding style is to assign the DataContext in code and not data bind to CollectionViewSources in your XAML, then you won’t be able to take advantage of the new Binding Builder. How to Enable Using the Binding Builder in WPF and Silverlight Applications by Karl Shifflett to the rescue – it demonstrates the simple requirements to enable you to use the new Binding Builder in a variety of scenarios like the ones mentioned above.

Threading in C#

Joseph Albahari, the author of C# 3.0 in a Nutshell, C# 3.0 Pocket Reference, and LINQ Pocket Reference as well as LINQPad, has very nice Threading in C# article (well, it is 77 pages long and available in PDF format as well). As the author says, “[it] tackles difficult issues such as thread safety, when to use Abort, Wait Handles vs Wait and Pulse, the implications of Apartment Threading in Windows Forms, using Thread Pooling, Synchronization Contexts, Memory Barriers and non-blocking synchronization constructs.”

Exceptions in C++

In Google C++ Style Guide they state that they are not using exceptions in C++ code at Google. They have reasons for it (“historical” mostly, as usual), but I do not necessarily agree with their view on it. Anyway, exceptions are quite a controversial topic in C++ community, and a must-read C++ Exceptions: Pros and Cons article at CodeProject goes deeper into the subject.

Personally I think that exceptions are really great, although I see how people can get things messy/wrong when using exceptions in inappropriate contexts and/or in inappropriate ways. Recipe to avoid problems? My own short list:

.NET Events: Multithreading Issues

Threadsafe Events article at CodeProject explains problems one might encounter with .NET events in a multithreaded environment (not necessarily stating the absolute truth but still). Unfortunately, no-one has figured out the perfect solution, and we will have to choose “the best from all bad solutions” for some time still.

Asynchronous Callback Contexts article by the same author shows possible solution for event cancellation, particularly during object disposal: end-users do not expect components to raise events after they have been disposed or after they have unsubscribed from these events. The author refers to his Nito Asynchronous Library as a way to solve this issue.

Unattended .NET Installation

We needed to do unattended .NET 3.5 SP1 installation for our project, and at the same time we wanted to reduce the hard disk image size, so, after some Internet “crawling”, we found Silent .NET Maker synthesized[a] script [that] builds custom .NET unattended, switchless, multimode installers/nLite addons, supporting all latest .NET framework versions, all its hotfixes and langpacks for win 2K/XP/2K3 x86 up to date. The thing really works, and we managed to get the size of full .NET 3.5 SP1 installer with all hotfixes down to something like 43MB (packed with 7-Zip) for 32-bit Windows XP. Not bad reduction! Aaron Stebner has also something to say about this topic.

Today’s Sites/Blogs

  • Started to “bump” into the Smashing Magazine quite often nowadays. Usually it collects interesting Internet resources related to web development (notably CSS, HTML, AJAX, etc.) and design (user interfaces, fonts, new ideas, etc.), and also has some tutorial-like or how-to-like posts (e.g. about PNG optimization, common mistakes, etc.). Really nice! Webdesigner Depot, Line25 Web Design Blog, and Presidia Creative all have similar concept.
  • Windows Presentation Foundation SDK by Windows Presentation Foundation SDK writers and editors. Might be more interesting, but OK nevertheless.
  • Expression Blend and Design – The team blog of the Expression Blend and Design products

“Bit Twiddling”

Needed to do some “weird” things recently that involved bit operations, e.g. to create masks with certain number of bits set. During my “research” I found few interesting places:

WPF Video Playback Problems

There is one severe problem with video playback in WPF/Silverlight that, for some reasons unknown to me, is getting very little (almost none) attention from both the community and Microsoft. Basically, it boils down to WPF being absolutely unable to properly play video content. Let me explain by using the following diagram:

WPF Video Playback Poblems

First line shows video frames as they are in the video content. Second line depicts variable frame rate of the WPF renderer – as you know, WPF is changing the frame rate dynamically, and CPU load will affect frame rate too. There are two possible outcomes:

  1. WPF is using vsync (version 1), i.e. it synchronizing rendering to the screen with the screen refresh frequency. This is what you will get on Vista, and sometimes on XP (normally XP video drivers are not using vsync). The resulting video shown on the screen will have variable duration of frames, and the viewer will be present with artifacts like skipped video frames, “jerky” playback, where motion is not “smooth”/uniform, etc.
  2. WPF is not using vsync (version 2). It is the case normally seen on XP. The resulting video is even worse, as there is the tearing effect present now – upper and lower parts of the displayed video frame are not matching. This problem is not present on some XP machines, e.g. I do not see it on my home PC, while it is present on 100% of other machines.

This is a bit oversimplified picture, but good enough for our purpose. In reality, the resulting on-screen picture will depend also on the screen refresh frequency, but artifacts will be more or less the same. In both cases the video playback it totally unacceptable though.

The issue is very serious, and, unfortunately, it is unsolvable in terms of today’s WPF. I think it will be not solved in the near future either, as solving it would require WPF to adopt constant-frame rate rendering paradigm, and synchronizing it with the display refresh rate. This is not likely to happen, as it is a drastic change to the fundamentals of WPF, and, at the same time, it will waste resources in non-video related applications (now WPF can decide what frame rate it will use, and can dynamically change it, e.g. dropping frame rate for “still” scenes and increasing it when animations start).

In our software we had to go through a lot of extra pain to “overcome” this issue – we render video using DirectShow by incorporating Win32 host into our WPF application and implement all kinds of “tricks” to allow WPF content to get into the video window airspace (to display OSD’s, menus, etc.) by using e.g. clipping regions (say Goodbye! to transparency though). There are a few third party projects out there (WPF MediaKit by Jeremiah Morrill is an excellent example) that allow one to mix DirectShow and WPF, but none of them will fix the above mentioned issues, as the resulting picture is rendered by WPF renderer and all the artifacts will be there still.

Probably, for majority of people this is not really an issue (at least until you point them to it; after that they can see it on their own and they become very annoyed), especially if you are playing some kind of home-made content from the YouTube (although YouTube has HD content nowadays too), but it is completely unacceptable for people at least somehow concerned about the video playback quality. DVD/DivX player costing $30 will not have these problems, so it is difficult to explain why $1000 machine (33 times more expensive!!!) cannot produce even remotely as good video playback on $2000 HD TV set.

In addition to these video playback problems, WPF on XP suffers from the tearing issue not only during video playback, but also during “normal” WPF animations. And this has even more profound effect, as it makes it impossible to implement animated WPF applications on XP.

Microsoft’s reaction to the tearing issue on XP is problematic. We have tried to approach them via all possible channels – Microsoft Connect program, Microsoft Metro program, newsgroups, personal contacts, everything. They either deny the issue, or say that it is unsolvable for XP in general case, so they are not going to solve it (but they could easily solve it for something like 95% of all XP installations by solving it at least for ATI and Nvidia cards), or they say that they will not solve it for XP anymore, as XP is not available so nobody cares. And this last reaction is problematic again, as the issue is present not only on Windows XP Home/Pro, but on Windows XP Embedded and Windows Embedded Standard as well. These OS’s will be around for some time still, and Windows 7 Embedded will not come before 2010 and, being Vista-based, will be a resource hog – something not necessarily good for embedded system.