Target platforms: Any CPU vs x86 vs x64

A lot of developers misinterpret the meaning of "Target platform" option in Visual Studio. You can read a good explanation here. I don't want to take credit for others work, so I just summarize the 5 most important facts:

• "Any CPU, means that the assembly will run natively on the CPU is it currently running on.", however "Any CPU does not guarantee that it will run on both 32-bit and 64-bit Windows." (if it has 32-bit dependencies, but not marked - author)
• "[...] this setting actually does not affect the build of the assembly in any way except to set the platform status information on the assembly’s CLR header."
• "Reasons to set your project as x86 include dependencies upon native DLLs that are only available in 32-bit"
• "[...] assemblies marked for x86 can still run on 64-bit Windows."
• "All assemblies targeting .Net 1.0 and 1.1 will be 32-bit only (x86) [...]"

Don't forget to read the whole article to have a better understanding :)

The differece between "new" and "override"

However the keyword new and the keyword override are very alike, they have some really different purpose and it is not recommended to swap / mix them. You can read their behaviors and purposes e.g. on StackOverflow. 

Here is an example for the article above. As you can see, you will have different result, which can cause you some headache if you try to find a bug.

   public class Base
   {
      public virtual void Method()
      {
         Debug.WriteLine("Base");
      }
   }

   public class Override : Base
   {
      public override void Method()
      {
         Debug.WriteLine("Override");
      }
   }

   public class New : Base 
   {
      public new void Method()
      {
         Debug.WriteLine("New");
      }
   }

   public class Program
   {
      public Program()
      {
         var b = new Base();
         b.Method(); // "Base"

         b = new Override();
         b.Method(); // "Override"
         
         b = new New();
         b.Method(); // "Base"
      }

      static void Main(string[] args)
      {
         var p = new Program();
      }
   }

Unfortunately C# compiler has a really bad behavior and let you to hide a method without explicitly write new. Ohh, yeah... you will get a warning, but not a compile error nor a runtime error. All you are going to face with, is some unwanted misbehavior. So, watch out.

ReactiveUI extension for WPF

My very first article got published in the Dot-Net-Pro magazine last week under the title "Haben Sie schon reagiert?". It is about a new WPF extension: ReactiveUI, which lets you to develop event based, always responding and up to date UI in WPF. You don't need to worry about INotifyPropertyChanged, BackgroundWorker or CommandManager anymore. 

The greatest thanks go to my colleague, Hendrik Lösch, for his support.

Windows 7 WPF style on Windows XP / 8 / 8.1

The issue

If you have a few years experience, than you already faced with the issue probably: WPF style looks different on different Windows'. You develop and design something on Windows 7, but some old-fashion customer still have Windows XP or maybe already installed the brand new Windows 8.1 and everything falls apart. You can prevent it when you use your own style, custom controls and redefine every single style property. Well, it does not sound too friendly. But don't worry, there is another option.

Why is it different in the first place?

Although the .NET runtime framework has the same version, somehow it still looks different on different OSs due the default style on Windows XP is Luna, on Windows 7 is Aero (first introduced in Vista) and on Windows 8 / 8.1 is Aero2 (or Aero Glass). If you create a WPF application and don't change the theme, references or create custom styles then one of those themes will be applied respectively to the OS Version.
On one hand it is a little bit annoying, since one does not want to create a complete custom style for an intern-used-only application just to make sure progressbars and comoboxes as well as word wrapping  are the same. On the other hand it has to be this way to make sure OS design is consistent. So, whenever your application is gonna need the PresentationFramework.dll, the current OS will provide it's own default.

Solution

The solution is easier than you think. You don't need to customize any control or use 3rd party stuff. All you need is to tell your app to use e.g the Aero theme. First copy the Windows 7 Aero DLLs (PresentationCore.dll, PresentationFramework.dll, PresentationFramework.Aero.dll) to your solution folder from c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\ and then explicit reference them into your solution. After that, modify your App.xaml and include the theme as resource. Enjoy :)

<Application x:Class="WPFAeroDemo.App"

             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

             StartupUri="MainWindow.xaml">

    <Application.Resources>

        <ResourceDictionary>

            <ResourceDictionary.MergedDictionaries>

                <ResourceDictionary Source="/PresentationFramework.Aero;component/themes/Aero.NormalColor.xaml"/>

            </ResourceDictionary.MergedDictionaries>

        </ResourceDictionary>

    </Application.Resources>

</Application>

Result

Without explicit theme definition

OS Default style on Windows XP (left), on Windows 7 (middle) and on Windows 8.1 (right)

With explicit definition

Aero style on Windows XP (left), on Windows 7 (middle) and Windows 8.1 (right)