Well, I have been kind of absent from the blog lately and that is for several reasons. One is that I have been waiting for some news that would determine my direction as a professional developer. The other is that I have re-acquired a passion for chess. So, between work at the office, watching chess videos, playing chess with my PDA and watching all seven seasons of Star Trek Deep Space 9, I haven't had much time for blogging.

Also, when you think about it, the last period of my programming life has been in some sort of a limbo: switched from ASP.Net to WPF, then to ASP.Net again (while being promised it would be temporary), then back to WPF (but in a mere executive position). Meanwhile, Microsoft didn't do much to help me, and thus saw their profits plummet. Well, maybe it was a coincidence, but what if it wasn't?

I am complaining about Microsoft because I was so sold into the whole WPF/Silverlight concept, while I was totally getting fed up with web work. Yet WPF is slow, with no clear development pathway when using it, while Silverlight is essentially something else, supported by only a few platforms, and I haven't even gotten around to use it yet. And now the Internet Explorer 9/Windows 8 duo come in force placing Javascript and HTML5 in the forefront again. Check out this cool ArsTechnica blog post about Microsoft's (re)new(ed) direction.

All of this, plus the mysterious news I have been waiting for that I won't detail (don't want to jinx it :-S), but which could throw me back into the web world, plus the insanity with the mobile everything that has only one common point: web. Add to it the not too enthusiastic reaction of my blog readers when starting talking about WPF. So the world either wants web or I just have been spouting one stupid thing after another and blew my readers away.

All these shining signs pointing me towards web development also say that I should be relearning web dev with ASP.Net MVC, getting serious about Javascript, relearning HTML in its 5th incarnation and finally making some sense of CSS. Exciting and crazy at the same time. Am I getting too old for this shit or am I ready for the challenge? We'll just have to see, won't we?

This is a case of a bug fix that I made work, but I can't understand why the solution works. Basically, the story was that some internal component of a third part control forced WPF to throw an exception on the UI thread. As it was impossible to plug the hole in the third party library, and since its next version is supposed to solve the issue, I've opted for a somewhat ugly hack: I've handled the DispatcherUnhandledException event of the Application class and I've basically said to it to ignore that specific UI error.

I will get into details of what the error and where it came from was and how to handle it, but I want to focus on the fact that, since this was a fix for a specific class, I've inherited from that class and used a static method in it to do the above handling of the event. Well, it worked most of the cases, but not all. Some code that involved moving the focus of WPF elements programmatically would cause the bug to reappear.

At first I thought it was a matter of a change in the policy of exception handling from .Net 1.0 to 2.0 and above. So I've set the <legacyUnhandledExceptionPolicy enabled="1"/> option in the app.config runtime section, but it didn't help.

I've tried everything, from using the control instance Dispatcher in the constructor or in the Loaded event, to moving the code directly to the point after the application was instantiated and before the application was run. Bingo, it worked! I thought that was it. I've again encapsulated the entire behavior in the inherited control and ... watched it fail.

Let me simplify the situation: static code that doesn't work when encapsulated in a static class works perfectly when the same code is inlined in the calling code. Can you explain that? I cannot!

The code is simple:

    application.DispatcherUnhandledException +=
      application_DispatcherUnhandledException;

    static void application_DispatcherUnhandledException
           (object sender, DispatcherUnhandledExceptionEventArgs e)
    {
      if (e.Exception.Message.Contains("Hover") 
          && e.Exception.Message
                 .Contains("System.Windows.Controls.ControlTemplate"))
      {
        e.Handled = true;
      }
    }

Move that in a static class and execute it as MyClass.RegisterFix(application); and it doesn't catch all the exceptions thrown, although it works in most cases.

Can anyone explain this to me? Why does it matter where the code is?

As I was blogging before, RedGate are assholes. They bought Reflector, promised to keep it free, then asked money for it. But every crisis can be turned into an opportunity. JetBrains promised a free decompiler tool and they have kept their word as they have released an early build. A total news to me, but not really a surprise, other software companies decided to build their own version in order to boost their visibility in the developer world. Telerik, for example, has just released JustDecompile, beta version.

It is no secret that JetBrains is a company that I respect a lot, as they made ReSharper, the coolest tool I've ever had the pleasure to work with, but I will try to be as unbiased as possible in comparing the options. I have tried dotPeek on WPF's PresentationFramework.dll from the .NET framework 4.0, as I often need to check the sources in order to understand functionality or bugs.

As a footnote, Reflector, just before it went commercial, could not decompile some of the code there. Not only it did not decompile it, but it presented empty methods like that was all there was in the code, with no warnings or errors or explicative comments. So, even if free, I bet Reflector would have sucked in the end, after getting into the money grabbing hands of RedGate.

dotPeek has seen and decompiled the code that Reflector did not. Also, I have to say that similar functionality like in ReSharper, finding usages, going to declaration, etc are making dotPeek a very nice tool to work with. What I did not quite like is that it doesn't have yet the functionality to save the sources to text files. But I am sure this is just a detail that was not implemented yet. Hopefully, they will provide a rich plugin model like old Reflector did.

Unfortunately, to download JustDecompile, they need you to have a Telerik login in order to download, which, as everyone knows, simply sucks. No one likes a registration form, folks! Especially one that presents you with wonderful prechecked checkboxes for permission for Telerik to send you all kind of stupid promotions and newsletters. Also, the download is of a .msi file. Most developers like to see what they are installing and preferably just copy it from a file archive. Running the .msi took forever, including the mandatory 100% CPU utilization bit that I will never understand in installation products. (coming from the .NET runtime optimization service, mscorsvw, called by ngen) But that's just the delivery system. Let's check out the actual thing.

JustDecompile starts reasonably fast and it also has a nice look, being build with Telerik controls and what not. The decompilation is a bit weird at first, since it shows only the method names and for a second there I thought it was as bad as Reflector was, but then I noticed the Expand All Members button. The context menu is not nearly as useful as dotPeek's, but there are a lot of options in the top toolbar and the navigation via links is fast and intuitive. It also has no text saving options yet.

As the decompiled sources were, I noticed these differences:

• JustDecompiler places inline member declarations in constructors, dotPeek shows it inline. It might not seem an important thing, but an internal class gains a weird public constructor in order to place the declaration there, instead of using the only internal constructor that the class had. It looks strange too as its last line is base(); which is not even legal.
• dotPeek seems to want to cast everything in the source code. For example List list = (List) null;
• JustDecompiler shows a Dictionary TryGetValue method with a ref parameter, dotPeek shows the correct out.
• dotPeek creates really simple names for local scope variables like listand list1, JustDecompiler seems to create more meaningful names like attachedAnnotations
• JustDecompiler shows a class internal as dotPeek shows it as internal abstract.
• JustDecompiler seems to fail to decompile correctly indexer access.
• JustDecompiler doesn't seem to handle explicit interface implementations.
• JustDecompiler doesn't seem to decompile readonly fields.
• JustDecompiler transforms a piece of code into an if with a return in it and then some other code, dotPeek decompiles it into an if/else.
• JustDecompiler doesn't seem to handle Unicode characters. dotPeek correctly encodes them in source like "\x001B".
• dotPeek seems to join nested ifs in a single one, as opposed to JustDecompiler.
• JustDecompiler uses base. in order to access members coming from base classes, while dotPeek uses this.

I will stop here. I am sure there are many other differences. My conclusion is that dotPeek could do with the naming algorithm JustDecompiler seems to use for local scope variables, but in most other ways is superior to JustDecompiler for now. As both programs are in beta, this could quickly change. I do hope that healthy competition between these two products (and, why not, shady developer meetings in bars over tons of beer and pizza, in order to compare ideas intercompanies) will result in great products. My only wish is that one of these products would become open source, but as both use proprietary bits from commercial products, I doubt it will happen.

Have fun, devs!

Update 23 Feb 2012:
Spurred by a comment from Telerik, I again tried a (quick and dirty, mind you) comparison of the two .Net decompilation tools: JetBrains dotPeek and Telerik JustDecompile. Here are my impressions:

First of all, the Telerik tool has a really cute installer. I am certainly annoyed with the default Windows one and its weird error codes and inexplicable crashes. Now, that doesn't mean the Telerik installer does better in the error section, since I had none, but how could it not? The problem with the installation of JustDecompile is that it also tried to install (option checkboxes set by default) JustCode and JustTrace. The checkboxes themselves were something really custom, graphically, so I almost let them checked, since they looked as part of the background picture. If it weren't for my brain spam detector which went all red lights and alarm bells when seeing a really beautiful installer for a free tool, I might have installed the two applications.

Now for the decompilation itself. I was trying to see what the VisualBasic Strings.FormatNumber method contained. The results:

• dotPeek showed xml documentation comments, JustDecompile did not
• dotPeek showed default values for method parameters, JustDecompile did not
• JustDecompile could decompile the source in C#, VB and IL, dotPeek did only C#
• JustDecompile showed the source closer to the original source (I can say this because it also shows VB, which is probably the language in which Microsoft.VisualBasic was written), dotPeek shows an equivalent source, but heavily optimized, with things like ternary operators, inversions of if blocks and even removals of else sections if the if block can directly return from the method
• There are some decorative attributes that dotPeek shows, while JustDecompile does not (like MethodImplAttribute)
• dotPeek has a tabbed interface that allows the opening of more than a single file, JustDecompile has only a code view window
• dotPeek shows the code of a class in a window, in order to see a method, it scrolls to where the method is; JustDecompile shows a class as a stub, one needs to click on a method to see the implementation of only that method in the code window

My conclusion remains that dotPeek is a lot more usable than JustDecompile. As a Resharper user, I can accept that I am biased, but one of the major functionalities of a .Net decompiler is to show you usable code. While I can take individual methods or properties with JustDecompile and paste them in my code, I can take entire classes with dotPeek, which makes me choose dotPeek for the moment, no matter all the other points above. Of course, if any of the two tools would give me a button that would allow me to take a dll and see it as a Visual Studio project, it would quickly rise to the top of my choices.

Update 26 Apr 2013:
I've again compared the two .Net decompilers. JustDecompile 1.404.2 versus dotPeek EAP 1.1.1.511. You might ask why I am comparing with the Early Access Program version. It is because JustDecompile now has the option to export the assembly to a Visual Studio project (yay!), but dotPeek only has this in the EAP version so far.
I have this to report:
Telerik's JustDecompile:

• the installer is just as cute as before, only it is for a suite called DevCraft, of which one of the products is JustDecompile
• something that seemed a bit careless is the "trial" keyword appearing in both download page and installer. If installing just JD, it is not trial
• again the checkboxes for JustCode and JustTrace are checked by default, but at least they are more visible in the list of products in the suite
• a Help Improve the Telerik Installer Privacy Policy checkbox checked by default appeared and it is not that visible
• the same need to have an account to Telerik in order to download JD
• when installing JD, it also installs the Telerik Control Panel a single place to download and manage Telerik products, which is not obvious from the installer
• the install takes about two minutes on my computer to a total size of 31MB, including the control panel
• if a class is in a multipart namespace like Net.Dns, it uses folders named Net.Dns if there is no class in the Net namespace
• not everything goes smoothly, sometimes the decompiler throws exceptions that are then logged in the code as comments, with the request to mail to JustDecompilePublicFeedback@telerik.com
• it creates the AssemblyInfo.cs file in a Properties folder, just like when creating a project
• resolves string concatenation with string.Concat, rather than using the '+' operator as in the original code
• resolves foreach loops into while(true) loops with breaks when a condition is met
• uses private static methods in a class with the qualified class name
• resolves inline variables, leaving the code readable
• overall it has a nicer decompiled code structure than dotPeek
• adds explicit default constructors to classes
• places generic class constraint at the end of constraints list, generating an exception
• it doesn't catch all reference assemblies, sometimes you have to manually add them to the list
• decompiles enum values to integer in method optional parameters default values, generating compilation errors
• decompiles default(T) to null in method optional parameters default values, generating compilation errors
• decompiles class destructors to Finalize methods which are not valid, generating compilation errors
• types of parameters in calls to base constructors are sometimes wrong
• places calls to base/this constructors at the end of constructor code blocks, which of course does not work, when you place more complex code in the calls
• doesn't understand cast to ValueType (which is somewhat obscure, I agree)
• really fucks up expressions trees like FluentNHibernate mapping classes, but I hate NHibernate anyway
• resolves if blocks with return in them to goto/label sometimes
• resolves readonly fields instantiated from a constructor to a mess that uses a local variable to set the field (which is not valid)
• doesn't resolve corectly a class name if it conflicts with the name of a local method or field
• inlines constants (although I don't think they can solve this)
• switch/case statements on Enum values sometimes gain weird extra case blocks
• sometimes it uses safe casting with value types (x as bool)

JetBrain's dotPeek:

• the EAP version has a standalone executable version which doesn't need installation
• the whole install is really fast and installs around 46MB
• as I said above, it does not have the Export to Project option until version 1.1
• the decompilation process is slower than JustDecompile's
• if a class is in a multipart namespace like Net.Dns, it uses a folder structure like Net/Dns
• sometimes things don't go well and it marks this with // ISSUE: comments, describing the problem. Note: these are not code exceptions, but issues with the decompiled code
• it inlines a lot of local variables, making the code more compact and less readable
• weird casting of items in string concatenations
• a tendency to strong typed casting, making the code less readable and generating compilation errors at times
• the AssemblyInfo.cs file is not created in a Properties folder
• when there are more classes in a single file, it creates a file for each, named as the original file, but prefixed with a number, instead of using the name of the class
• it has an option to create the solution for the project as well
• it creates types for anonymous types, and creates files with weird names for them, which are not really valid, screwing the project.
• it has problems with base constructor calls and constructor inheritance
• it has problems with out parameters, it makes a complete mess of them
• tries to create a type for Linq IQueryable results, badly
• it has problems with class names that are the same as names of namespaces (this is an issue of ReSharper as well, when it doesn't present the option to choose between a class name and a namespace name)
• resolves while(method) to invalid for loops
• it doesn't resolve corectly a class name if it conflicts with the name of a local method or field
• problems with explicit interface implementations: ISomething a=new Something(); a.Method(); (it declares a as Something, not ISomething)
• problems with decompiling linq method chains
• I found a situation where it resolved Decimal.op_Increment(d) for 1+d
• indirectly used assemblies are not added to the reference list
• it sometimes creates weird local variables like local_0, which are not declared, so not valid
• adds a weird [assembly: Extension] in the AssemblyInfo file, which is not valid
• a lot of messed up bool values resolved as (object) (bool) (value ? 1 : 0), which doesn't even work
• inlines constants (although I don't think they can solve this)
• __Null local1 = null; - really?

After decompiling, solving the issues and compiling again an assembly in the project I am working on I got these sizes:
JustDecompile: 409088
dotPeek: 395776
The original: 396288

Of course, this is not really a scientific comparison between the two. I was excited by the implementation of Export to Project in both products and I focused mainly on that. The navigation between types and methods is vastly improved in JustDecompile and, to my chagrin, I have to admit that it may be easier and safer to use than dotPeek at this time. Good job, Telerik! Oh, and no, they have NOT paid me to do this research :-)

People who know me also know about the Law of Siderite: never use any Microsoft product until it has reached a second service pack or release. That has been true for me, like a skewed Moore law, since Windows 95 OSR2 (also known as Windows 96). But I had to break my own legal advice and try to install Visual Studio 2010 Service Pack 1.

There are several reasons for this, one of them being that VS2010 had a few relatively important bugs and I am using the tool at work every day and at home when I get the time. So not only did I not wait for a Service Pack 2, I've gone and installed the beta version! And guess what? It installed without any problems and fixed most of the bugs that annoyed me, if not all. Yay, for Microsoft! But then I had to install ASP.Net MVC, which needed as a prerequisite VS2010 SP1 and so I went and installed the Release Candidate. That is, the version that should be like the beta, only better. This is the story of that fateful decision:

• Step 1: Start ASP.Net MVC3 installer. Result: Fail!
• Step 2: Start Visual Studio 2010 Service Pack 1 installer, the small 500kb version. Result: fail.
• Step 3: Download the .iso version and run. Result: fail.
  
• Step 4: Reinstall Visual Studio 2010 Ultimate
  a) Uninstall Visual Studio 2010. Result: fail.
  b) Use Microsoft Installer Cleanup Utility on Visual Studio. Install VS2010 (without VB or VC++). Result: Success!
• Step 5: Install VS2010 SP1
  a) .iso version. Result: fail!
  b) Web Platform Installer version (new fancy Microsoft tech). Result: fail!
  
• Step 6: Install Web Developer Express (free) + VS2010 SP1 from Web Platform Installer. Result: SP1 core fail! SP1 Asp.net success!?!

Bottom line: Now ASP.Net MVC seems to be working, with Razor syntax highlighting and intellisense, but the SP1 core is not installed. Visual Studio help window shows me that I have the Rel(ease) version, not SP1. I don't know what will blow up when I try it. Luckily, all this happened at home, not at work, therefore I haven't broken my main working tool.

My conclusion is that somehow you need to install the (useless, if you have Visual Studio) Visual Web Developer Express in order for the ASP.Net SP1 to work. This allows for different web engines, like Razor. SP1 doesn't work though. If you have the beta installed, try to use the Web Platform Installer to install Web Developer Express as well as the Visual Studio SP1. If it fails, look at the last section and see what got installed. Maybe you get the best of both worlds. I will be trying another Visual Studio version, but as the whole process takes ages, be warned.

Let me say that again, so it's perfectly clear: the install process of Visual Studio 2010 Service Pack 1 plus Visual Web Developer Express via the Web Platform Installer tool took me 12 hours! I did not have to press anything, it wasn't a case of trial and error, I just ran it, it said "installing 2 out of 12" for 12 hours in a row, then it partially failed. And the Web Platform Installer seems the best solution so far!

As usual when I stumble into a problem that I can't solve only to see that it has a simple explanation and that I am not sufficiently informed on the matter, I had some misgivings on blogging about it. But these are the best possible blog entries, the "Oh, I am so stupid!" moments, because other people are sure to make the same mistake and you wouldn't wish for them the same humiliation, would you? Well, I wouldn't :-P

So here it is: I was having a ToggleButton and a ContextMenu in a custom control. I wanted to have the IsChecked property bound in two-way mode with the IsOpen property of the ContextMenu. So I did what most people would do, I created a Setter on the IsChecked property with a Binding on DropDown.IsOpen as a value (DropDown is the property of the control holding the ContextMenu). And it worked, of course. My custom control would inherit from ToggleButton and use the style with the Setter in it.

But now comes the tricky part: I wanted that when a certain condition was met, the button be checked and the menu open. So I added a Trigger to the Style on the condition that I wanted, with a Setter on the IsChecked property to True. And from then on, nothing made any sense. I would click the button and it would not open the menu anymore.

Well, if you think about it, you have a Setter in the Style and then another Setter on the same property in the Trigger. It makes a sort of a sense for them to interfere with each other, but I also know that setting a Binding as value to a DependencyProperty is like using SetBinding on the owner of the property. And I thought it was normal for the IsChecked property to be set to true from the trigger and, in turn, change the value of IsOpen. But it didn't happen. Let it be a lesson to other bozos like myself that this thing does make sense logically (or as wishful thinking), but not in WPF. And here is why:

Let's try to evaluate the values of IsChecked and IsOpen. First case scenario: clicking on the button. That changes the status of IsChecked from true to false and viceversa. Internally, what does happen is WPF finds any bindings associated with the value and refreshes them. In this case, it finds a binding to IsOpen and so the ContextMenu also opens up. Second case scenario: the condition in the ViewModel is met, the trigger is fired and the value of IsChecked is set. It should do the same thing, right? Find the bindings and refresh them. And it does! But in that fateful moment, it sees that the IsChecked property has a setter associated with it, from the trigger in the style, that sets it to True. It does not go further, because the trigger setter overrides the style setter. I personally think this is closer to a bug than a reasonable behavior, but I am biased here :) I mean, you set the value of the property directly in the code IsChecked=true;, and it works, but you set it in the trigger and it overrides the binding?

There are more solutions to this problem. One solution would be to replace the setter value in the trigger with another binding also to the IsOpen property of the ContextMenu, but with a nifty converter. I haven't tried it, because I think that, if it worked, it would add too much weird complexity and even if I love weird, this is a little bit too much for me. Of course, a programmatic solution is also possible, adding handlers for the Open and Close events of the ContextMenu and setting IsChecked, as well as setting IsOpen based on the value sent to the IsChecked property change callback. But I wanted to do something that is as WPFish as possible. Another solution is to set a binding to the IsOpen property, since it is two way, and this is what I did. Unfortunately, the ContextMenu is a variable of the control, so I had to manually set the binding in that property's PropertyChangedCallback. A more elegant solution, I believe, is to have another element present that would have two-way bindings for both IsChecked and IsOpen properties to two of its own properties. Internally, when one changes, the other is synchronized. This leaves both ToggleButton and ContextMenu free to have any setters on IsChecked and IsOpen without interference.

The pattern of using a separate control to link properties from other controls together is called Binding Hub. Here is an article detailing it. I disagree with the naming of properties as I believe for each connection a separate hub should be created with properties that actually make sense :), but the concept is powerful and I like it.

Short version: open registry, look for file association entry, locate the command subkey and check if, besides the (Default) value, there isn't a command multistring value that looks garbled. Rename or remove it.

Now for the long version. I've had this problem for a long time now: trying to open an Office doc file by double clicking it or selecting "Open" from the context menu or even trying "Open with" and selecting WinWord.exe threw an error that read like this: This action is only valid for installed products. This was strange, as I had Office 2007 installed and I could open Word just fine and open a document from within; it only had problems with the open command.

As I am rarely using Office at home, I didn't deem it necessary to solve the problem, but this morning I've decided that it is a matter of pride to make it work. After all, I have an IT blog and readers look up to me for technical advice. Both of them. So away I go to try to solve the problem.

The above error message is so looked up that it came up in Google autocomplete, but the circumstances and possible solutions are so varied that it didn't help much. I did find an article that explained how Office actually opens up documents. It said to go in the registry and look in the HKEY_CLASSES_ROOT\Word.Document.12\shell\Open\command subkey. There should be a command line that looks like "C:\Program Files\Microsoft Office\Office12\WINWORD.EXE" /n /dde. The /dde flag is an internal undocumented flag that tells Windows to use the Dynamic Data Exchange server to communicate the command line arguments to Word, via the next key in the registry: HKEY_CLASSES_ROOT\Word.Document.12\shell\Open\ddeexec which looks like: [REM _DDE_Direct][FileOpen("%1")]. So in other words (pun not intended) WinWord should open up with the /n flag, which instructs to start with no document open, then execute the FileOpen command with the file provided. If I had this as the value of the command registry key, it should work.

Ok, opened up the registry editor (if you don't know what that is or how to use it, it is my recommendation to NOT use it. instead ask a friend who knows what to do. You've been warned!), went to where the going is good and found the command subkey. It held a (Default) value that looked like it should and then it held another value named also command, only this one was not a string (REG_SZ), but a multi string (REG_MULTI_SZ), and its value was something like C84DVn-}f(YR]eAR6.jiWORDFiles>L&rfUmW.cG.e%fI4G}jd /n /dde. Do not worry, there is nothing wrong with your monitor, I control the horizontal, vertical and diagonal, it looked just as weird as you see it. At first I thought it was some weird check mechanism, some partial hash or weird encoding method used in that weird REG_MULTI_SZ type, which at the moment I didn't know what it meant. Did I mention it was weird? Well, it turns out that a multi string key is a list of strings, not a single line string, so there was no reason for the weirdness at all. You can see that it was expecting a list of strings because when you modify the key it presents you with a multiline textbox, not a singleline one.

So, thank you for reading thus far, the solution was: remove all the annoying command values (NOT the command subkeys) leaving the (Default) to its normal state. I do not know what garbled the registry, but what happened is that Windows was trying to execute the strange string and, obviously, failed. The obscure error message was basically saying that it didn't find the file or command you were trying to execute and has nothing to do with Office per se.

Of course,you have to repeat the procedure for all the file types that are affected, like RTF, for example.

Now what else could I have been? I have been doing this damn job for at least 6 years, depending on what you call programming and what not, and even in the worst moments of depression and disappointment I still can't imagine myself doing anything else.

The point is that I have taken the 70-518 exam: Designing and Developing Windows Applications Using Microsoft .NET Framework 4 with 950 points of 1000. The same old story: pointless questions with some ridiculous answers and focus on technologies that nobody has really heard about like Microsoft Sync Framework or using DTOs or planning testing strategies (you only have to know how they are named, though).

Even worse, after getting almost all the questions and answers from the web in the form of a helpful .vce file, I started researching them on MSDN. I really wanted to know exactly what each question meant and why were those the correct answers. I really expected to find tons of documentation from Microsoft about all of this, but no! Not only did I not find what I was looking for most of the time, but when I did it was either obsolete information, meaning there were from 2007 or having specific message on the pages that the information is no longer valid, or formatted in a weird and unfriendly way that was not conducive to any type of training or learning.

Go ahead, try finding documentation on Microsoft Sync Framework, a Hands on Lab or anything that can be read from top to bottom and give you the ability to use that technology. Nada! There is no book for the MCPD exam, not even one that is going to be published in the future. Sure, I can download anything, install it, try it out, google for error messages and fix things up when they don't work, but I would have done that anyway!

I leave this whole experience behind with a vague sense of disappointment. I've learned a lot about WCF and I am going to read Julie Lerman's Entity Framework book now, but none of these four exams did really push me to learn anything new or (something that I feel I deserved from Microsoft) to find the best ways of doing things. It is all a jumbled, bureaucratic mess.

A shameful affair, this. I barely got 820 of 1000 for the Microsoft TS exam 70-516: Accessing Data with Microsoft .NET Framework 4. I could invoke my birthday and some other circumstances to motivate my low result, but let's face it: I could have done a lot better.

What I can tell you about the exam is that most of the questions regard Entity Framework, but also Linq to SQL, classic ADO.Net, WCF Data Services. There are a few questions regarding security and the Microsoft Sync Framework thrown for good measure, as well. Also, there is a .vce file on the net from 2010-07-29, by Carina, and, even if there is some overlap, those are mostly NOT the questions in the exam, while the .vce from 2011-12-09 by acarum is a fake.

As preparation materials I've used Julie Lerman's excellent book Programming Entity Framework Second Edition, which is a thorough and well written book, but kind of huge! Try to allocate at least a month to read through it. I'd really intended to make a post with MSDN resources for the exam, but I didn't have the time.

Onwards, comrades! The MCPD 70-518 exam awaits!

I was doing some tests with localization in a WPF application and I've found that the way to change dynamically the language for a control (and all of its descendants) is to set the Language property. In my application at least, the propagation of change in the entire subtree took a few seconds. As I found out, the way to refresh the language is to actually remove and readd children to control trees. This is probably why simply changing the Thread culture does not work, what the Language property is for and explains why the error was thrown.

During the Language change on the Window object a validation from one of the custom controls there threw a weird Exception: Cannot modify the logical children for this node at this time because a tree walk is in progress.. What could it mean?

This link on StackOverflow says something vague about a bug in the Silverlight charting toolkit, but I think that is wrong, or at least not the root of the problem. I looked through the Reflectored .Net sources and found that this exception is thrown in AddLogicalChild and RemoveLogicalChild methods in FrameworkElement and FrameworkContentElement when the internal property IsLogicalChildrenIterationInProgress is true. Apparently, this property is set to true whenever am internal class DescendentsWalker<T> is "walking" the visual and/or the logical trees. What is this class?

DescendentsWalker<T> seems to be a class used by the WPF framework to find resources, resolve property values, find ancestors/descendants in the control trees, propagate events, etc, so it is a very important low level class. Either because of a bug or exactly in order to prevent one, an error is thrown if someone is trying to change the structure of the tree while something is walking the tree. That is what the error represents.

Now, the only question is how to solve it. The validation code was trying to change the content property of a control, thus modifying the control tree. As such, I do believe this is a slight bug in the framework, as changing the tree could just wait until the tree walk is over, but still. A simple try/catch solve it locally, but what should I do to prevent such errors in the future for all of my code? I can't pad my code with try/catch blocks.

I've tried using Dispatcher.Invoke for the change, it didn't work. The IsLogicalChildrenIterationInProgress property itself does a this.ReadInternalFlag(System.Windows.InternalFlags.IsLogicalChildrenIterationInProgress); and _flags is obviously a private field of the FrameworkElement or FrameworkContentElement class that is never encapsulated into a public property. So I can't check for it in a simple way. Of course, one can always catch Dispatcher.UnhandledException and just set e.Handled to true if this error occurs (Oops, a minor worldwide tremor caused by developer shudder!), but I don't see another global solution.

Well, at least I've thoroughly examined the problem and its causes and possible solutions, however bad or annoying they may be. If you know of a more elegant solution for it, please share it. As this is the only time I ever got this error, I believe it is something that can be handled locally, but only if one knows how to test for it. So, change the Language of your windows or do other lengthy tree walks in order to protect your application from this bug.

Well, I wanted to convey something like the scene where Mr. Fancy Pants gets the icecream, but still, I passed the MCTS 70-511 exam: Windows Application Development. The grade is a shameful 982, because of a question regarding a DataGridView and a DataSet with related tables (as well as a microwave oven and non-dairy creamer), but it is still a decent pass.

Even if I knew most of the stuff already, some materials for study were: the awful MCTS Self-Paced Training Kit for 70-511 and a post from James J. Foster's blog.

MCTS Self-Paced Training Kit (Exam 70-511): Windows Application Development with Microsoft .NET Framework 4 is a terrible book. It tries to cover the entire subject of Windows application development, so that means it must explain both Windows Forms and Windows Presentation Foundation concepts. Not only that, but it must do it in a consistent, comprehensible way, avoiding confusion between similar ideas that often overlap. It fails miserably on all counts, probably because it can't be done in a single book, but also because it is a jumbled mess that no one that is unfamiliar with the concepts there can actually learn from. I wonder, was poor Matthew Stoecker presented with the questions in the exam and asked to write a book to cover them? Because that would explain a lot. The 70-511 test itself it not much smarter.

The book starts with Chapter 1: Building a User Interface, in which it presents some basic WPF concepts like controls, resources, styles and triggers. If well written, this could have been a good start. It then continues with Chapter 2: Working with Events and Commands, containing stuff about events and commands, obviously, but then animations! So a novice at desktop applications now has to suddenly contend with animation. Maybe it was a slip up, so let's try Chapter 3: Adding and Managing Content, talking about brushes and the visual tree, even transformations, but then it goes into using MediaElement and MediaPlayer to play sounds and video.

Chapter 4: Windows Forms and Windows Forms Controls starts talking about Windows Forms, but in a completely new way and structure than the WPF part. It talks about modifying properties in Visual Studio, it describes the controls, one by one, with properties and all. It's like a completely new book. Chapter 5: Working with User-Defined Controls starts with Windows Forms, then it tries to explain Control Templates in WPF, then jumps back to user controls, this time in WPF.

The book switches to data in Chapter 6: Working with Data Binding, explaining the WPF Binding mechanisms including validation, and in Chapter 7: Configuring Data Binding it talks about various data sources and DataTemplates, also for WPF. Then it moves back to Windows Forms, Chapter 8: Working with Data Grids and Validating User Input, which starts talking about data bound controls in Windows Forms, but then it goes on and on about the DataGridView. It goes on by combining in a single subchapter Windows Forms validation and IDataErrorInfo in WPF.

Before you know it, in this whole confusing bunch of thrown facts, with no structure or plan, you go through Asynchronous Processing (using BackgroundWorker and delegates, but not Tasks!), Globalization and Localization (yeah, that is the important part) and integrating Windows Forms and WPF together, all in Chapter 9: Enhancing Usability. Chapter 10: Advanced Topics manages to mix together security, application settings and Drag and Drop. Chapter 11: Testing and Debugging WPF Applications was, I think, the most decent chapter, but still kind of frankesteined together from different sources, while Chapter 12: Deployment, talked a bit about Windows Installer and ClickOnce.

Conclusion: messed up as a whole, messed up in each small part, it's a fractally messed up book! You even get "chapter summary" points that were not covered in the actual chapter. I couldn't wait for the book to end, but I've managed to read it all. On Monday I am taking a test on this, for the 70-511 exam and I am really not sure how it's going to work out. Luckily for me I knew most of the concepts covered in the book from personal experience so we'll see how it goes.

I started writing a long argumentative post about design patterns. But what is the use? They are abstract concepts that get cemented in the development industry by some influential people or some widespread adoption. Then you get to learn them in order to answer stupid job interview questions. In real life you either don't use them or they are abstracted in the programming language or framework you are using.

You dream of getting to work on your own framework so that the entire company would see how awesome you are, but you will only get to write stupid code for web shops and CRMs. And your life gets to its apogee when the architect who does the company framework or some company middle manager/owner tells you how important they are to know for your work. And you blame yourself for being so stupid and vow to spend your entire free time learning, and you read and you go to the water cooler and say "Hey, Bob, did you know the Adapter pattern is so cool?" and Bob looks at you like you are from another planet and goes to fix the latest "Font is too large in the toolbar menu" bug.

Bottom line: it's a chicken and egg thing. They need you to know as much formal programming stuff as possible so you can improve their crappy work and learning environment, while you need to work in a good work and learning environment so you can get better. The result is always an average soup of meh!

Just a month ago, overwhelmed by a number unbelievable claims from companies and lawyers at that time, I wrote the blog entry titled Ridiculous self importance, relaying what I thought of those claims. And yet now I am forced to write another one. See what happens when people don't read my blog? :)

Let's start with the already blogged move by Red-Gate to unilaterally rescind a promise they took to keep Reflector free. Just follow the link to the story for details, but keep in mind the general idea: a software company makes a promise that is completely ignored later on.

Moving on to EA Games. Like any commercial company that reaches a certain critical size, they become assholes. I am talking about the game Dragon Age II, a game that EA Games promised in the forums it would not feature SecuROM, but it does (read article here)! The company also completely fails to notify the game buyers that the feature is there. Another article then tells us the story of a player that bad mouthed the company and got banned from the company forums for 72 hours. But during that time, the Dragon Age II game he bought could not be played, either. That really sounds a bit 1984, doesn't it? The screen device watches what you say and then punishes you. Welcome to the future!

The last article (one can only hope) in the asshole saga is about Twitter. This service that I could never find a use for has grown exponentially because of two factors: the social paradigm and the API that allowed people to make their own software on top of Twitter. Having reached the critical size, Twitter now publicly announced that it doesn't need third party applications anymore. "Thank you, guys, but we will be making the money from now on. Thanks again!". This is one of the reasons why I distrust the cloud idea. I give enough control to Google deciding what is relevant for my queries (and hosting this blog :) ) to give it or other cloud providers the physical ownership of my business.

I believe these stories are related to the recent efforts to regulate the Internet and not only that, but also how you will be permitted to use your own computer or mobile device. Just like weird events before World Wars, they are only the predictors of an era in which the web will be increasingly controlled and will become just another commercial platform for companies. These events that look morally and logically absurd are attempts to shift the regulatory framework in a direction or the other, while we remain blissfully ignorant of the battle over our heads.

Hmm, mentioning 1984 and predicting World Wars... am I becoming paranoid? Well, I hope so, because the alternative is that I am right.

The book (MCTS Self-Paced Training Kit (Exam 70-503): Microsoft® .NET Framework 3.0—Windows Communication Foundation) covers just about everything there was in the .Net 3.0 version of WCF. As I was saying in a previous post, in order to "upgrade" to a 4.0 version you need to read about the router services, service discovery and simplified configuration.

What I liked about the book is that it is a no bullshit, yet comprehensive reference to the tasks for which one would use Windows Communication Foundation. I found it easy to read and comprehend and, most of all, easy to remember.

Today I went and certified myself as a Windows Communication Foundation developer in .Net 4.0 (exam 70-513). I passed with 1000/1000, which makes me "strong" in all areas of the exam. It was difficult, too, as there is no official preparation material for the exam. You have the old 3.5 preparation book for the 70-503 exam and then you have to guess about the things that are in 4.0. Basically, you can read the book, then study a little about the router services, service discovery and simplified configuration. I found a nice post on James J. Foster's blog detailing the material that needs study, with links. Also, here is a link on MSDN about what is new in WCF 4.0.

The problem with the exam is that I had found the questions (the real ones) on the web. You can download them and simulate exams until you remember all of them and their answers. These are called brain dumps (.vce format) and apparently it is the norm rather than the exception; Cisco exams are just the same. It was too weird to be true and, frankly, the whole point of taking these exams was to actually learn something in a structured way, so I was both hoping that those were the real questions and also that they were not and I will have the opportunity to test myself on what I have learned. Alas, it was not the case. I knew all the questions already and this has soiled the entire experience and grade.

Actually, when you think about it, it makes sense. Microsoft needs to show how serious they are about the whole test thing and ignore the elephant in the room altogether, pretending the answers are not out there. Meanwhile, the companies that organize the tests need those answers public, otherwise nobody would dare come take them and thus pay for them. I mean, really... 50 questions of increasing obscureness and a minimum passing grade of 800/1000 ? Who would even consider testing themselves against sets of four questions where one of them would throw a compiler error, one of them would be completely off topic and the other two were competing on which one gets the most hard to remember, one google-second away configuration setting that would make your brain explode. The ugliest thing is that people learning this stuff normally have little to no chance of getting every question right, even if in the official preparation books you find stuff like "Exam tip: beware questions in this format, as they will always be incorrect, but we will ask them anyway so we can trap you if you didn't read our material".

So, bottom line. I am proud of myself for actually studying for this. I feel I know a lot more about WCF and the powerful ways in which I can make it work for me. But the fact that any kid can download a file, do a dozen test runs on their home computer and then take the test and achieve the same perfect score soils it a little.

Well, this makes me a MCTS. I have 3 more exams to take and then I will become a MCPD. It's like achievements in games, only they are worth something.