.NET Core - how to add project reference

Well, in prev. version of .NET adding a new project reference is quite straightforward, however in .NET Core is still a challenge (thanks to the missing tools). So, let's see how to reference your custom Foo.Lib into your Foo.Web project.

1. Open project.json in Foo.Web
2. Find frameworks tag
3. Add a new tag "dependencies"
4. Extend with your Foo.Lib under dependencies.

It should look like something similar:

"frameworks": {
    "netcoreapp1.0": {
      "dependencies": {
        "Foo.Lib": "1.0.0-*",        
      },
      "imports": [
        "dotnet5.6",
        "portable-net45+win8"
      ]
    }
  },

Recompile your whole solution and now you can use your lib in the web project.

AppHarbor - .NET Cloud Platform as a Service

.NET Core 1.0 is still in preview state, but I urged to create a small demo project with it. Since I didn't wanted to use my company accounts and licenses, I google a little bit to find a free cloud service instead of Azure. 

So have I found AppHarbor. It is a really simple site, with a lot of available add-ons for free (at least for dev. purpose). You can even integrate it with your GitHub, CodePlex or local Git server to deploy code immediately. Later, if you really wanna go live and use it as a productive server, you can upgrade to a premium account. It gives you a lot more resources, custom domain and more.

Brace yourself, interview is coming!

Nowadays IT is more in focus than ever, news are full with hopeless firms, crave experts. But this is not a recruiter blog, so I just skip this part and lets focus on the technical stuff :) Regardless of your work experiences, before you go to an interview reread the basics and learn the technologies you may missed in the last years. 

Here are some sites as starting points:

• General C#
• Basic and advanced tutorials
• WPF
• WCF
• MVC

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)