Now I have ALL of the Microsoft developer certifications – long journey is over!!!

Now I own the full deck of the Microsoft certifications and I can sit back and relax (beer is in order . Unfortunately, in the startup world that I operate most of the time, it’s not very recognizable achievement, but it’s nice to put these logos on my presentation slide decks and, especially now, I have a very powerful bragging rights – I have ALL of the Microsoft developers certifications !!!

It was a lengthy path and, I should add, a very confusing one. It wasn’t very obvious what certification is a prerequisite to which one and, I must add, I’ve made a couple of mistakes on the road until I’ve discovered a developer’s certification map by Jorgen Thelin that put everything in order and cleared all the confusions.

WPF: Extracting BitmapImage from an attached resource in referenced assembly/library

It was not that simple to find out what is a reference to a linked resource within an assembly. The biggest problem was to nail down the exact pack path to a resource. It becomes simple if you know the name of a specific assembly, but, in real life, the names are changing pretty often.

This is the solution to such a problem: find out what assembly your code is running in and then construct a pack path to it. Then update it with a relative resource path. Under “relative resource path” I mean the path to your resource relative to the project (.proj) file within the VS solution. For example: if you like to store your images under “ProjectFolder/Images” folder then the relative path to your resource will be  “Images/ImageName.png”.

Don’t forget that in WPF a linked resource should have a Resource build action (not Embedded Resource) !!!

Here is a procedure that does all the above and hides all the hustle:

private BitmapImage GetImage(string resourcePath)
{
    var image = new BitmapImage();

    string moduleName = this.GetType().Assembly.GetName().Name;
    string resourceLocation =
        string.Format("pack://application:,,,/{0};component/{1}", moduleName,
                      resourcePath);

    try
    {
        image.BeginInit();
        image.CacheOption = BitmapCacheOption.OnLoad;
        image.CreateOptions = BitmapCreateOptions.IgnoreImageCache;
        image.UriSource = new Uri(resourceLocation);
        image.EndInit();
    }
    catch (Exception e)
    {
        System.Diagnostics.Trace.WriteLine(e.ToString());
    }

    return image;
}

Prism (V2) RegionManager fails to recognize non-WPF applications

In the recent change of Prism (V2), the way how the Region Manager detects that it’s running in a Design Mode or not, has been changed. This has ultimately broke all my Prism plug-ins that were hosted by non-WPF applications. One of the examples of hosts for such a plug-in, is an Office AddIn.

It took me about 6 hours to track down this problem and, to my amazement, I’ve found the place where it broke:

private static bool RegionManager::IsInDesignMode(DependencyObject element)
{
    // Due to a known issue in Cider, GetIsInDesignMode attached property value is not enough to know if it's in design mode.
    return DesignerProperties.GetIsInDesignMode(element) || Application.Current == null
        || Application.Current.GetType() == typeof(Application);
}

The reason is that for the non-WPF application the Application.Current is NULL !!!

The solution

1. 1. Create an empty class that will inherit from System.Windows.Applicatoin. (Name doesn’t matter):

   public class MyApp : System.Windows.Application 	{ 	}

    

2. At the point of entry to a plug-in execute the following code:

   if (System.Windows.Application.Current == null)
   {
       // create the Application object
       new MyApp();
   }

This is it – now you have an Application.Current that is not null and it’s not equal to typeof(Application).

If, by any chance, you’d like to merge your application resources – do the following:

 // merge in your application resources
System.Windows.Application.Current.Resources.MergedDictionaries.Add(
    System.Windows.Application.LoadComponent(
        new Uri("MyLibrary;component/Resources/MyResourceDictionary.xaml",
        UriKind.Relative)) as ResourceDictionary);  

For more information check DR.WPF’s article (http://www.drwpf.com/blog/Home/tabid/36/EntryID/10/Default.aspx) that beautifully explains the reasons and workarounds for the problem, described above.

File encodings matter when writing Pixel Shaders

Phewww… It took me some time to realize why my Pixel Shaders were not compiling with FXC. And this is a nasty one. Are you ready?..  IT DOES MATTER WHAT ENCODING YOUR FX FILE IS !!!!

Make sure to save your file with encoding: Western European (Windows) – Codepage 1252.

Check out this article for step-by-step instructions: http://blog.pixelingene.com/?p=224

Where is my config file if my main module is not inside the executing folder?

Some people ask me: “What if my bootstrapper is loaded by my application from a another (preconfigured) folder and my Prism/Unity config file located in the same (non-executing) folder? How do I load it?”

It’s pretty simple. You need to take your executing assembly as the base and figure out the required path.

var assembly = Assembly.GetExecutingAssembly();
Uri uriPath = new Uri(assembly.CodeBase);
string path = Path.Combine(Path.GetDirectoryName(uriPath.AbsolutePath), "myApp.config" );
var configMap = new ExeConfigurationFileMap { ExeConfigFilename = path  };
var configuration = ConfigurationManager.OpenMappedExeConfiguration(configMap, ConfigurationUserLevel.None);

unitySection = (UnityConfigurationSection)configuration.GetSection("unity");

modulesSection = (ModulesConfigurationSection)configuration.GetSection("modules");

Prism: File-configuration-driven bootstrapper

If you’d like to extract all your application configuration into a config file, this is what you can do:

1. Create a config file. I suggest that you use a different file name than the App.config

2. Override ConfigureContainer method in your bootstrapper

private UnityConfigurationSection unitySection;

private void GetConfigurationSection()
{
    if  (unitySection == null)
    {
        var configMap = new ExeConfigurationFileMap { ExeConfigFilename = "myApp.config" };
        var configuration = ConfigurationManager.OpenMappedExeConfiguration(configMap, ConfigurationUserLevel.None);

        unitySection = (UnityConfigurationSection)configuration.GetSection("unity");
    }
}

protected override void ConfigureContainer()
{
    base.ConfigureContainer();

    GetConfigurationSection();

    try
    {
        unitySection.Containers["global"].Configure(Container);
    }
    catch (Exception e)
    {
        System.Diagnostics.Trace.WriteLine(e.ToString());
    }
}

3. Point the module enumerator to the same config file via ConfigurationStore

protected override IModuleEnumerator GetModuleEnumerator()
{
    string baseDir = AppDomain.CurrentDomain.BaseDirectory;
    var store = new ConfigurationStore(baseDir);
    return new ConfigurationModuleEnumerator(store);
}

 

All this is fun, but, in case you have more than one config file that contains a Modules section – the ConfigurationStore will stop reading them as soon as it’ll find a first one. It may be the file that you needed in a first place, but, as well, it may be some other file.

Here is a simple workaround:

private UnityConfigurationSection unitySection;
private ModulesConfigurationSection modulesSection;

private void GetConfigurationSections()
{
    if ((unitySection == null) && (modulesSection == null))
    {
        var configMap = new ExeConfigurationFileMap { ExeConfigFilename = "myApp.config" };
        var configuration = ConfigurationManager.OpenMappedExeConfiguration(configMap, ConfigurationUserLevel.None);

        unitySection = (UnityConfigurationSection)configuration.GetSection("unity");

        modulesSection = (ModulesConfigurationSection)configuration.GetSection("modules");
    }
}

protected override void ConfigureContainer()
{
    base.ConfigureContainer();

    GetConfigurationSections();

    try
    {
        unitySection.Containers["global"].Configure(Container);
    }
    catch (Exception e)
    {
        System.Diagnostics.Trace.WriteLine(e.ToString());
    }
}

protected override IModuleEnumerator GetModuleEnumerator()
{
    GetConfigurationSections();

    return new ConfigurationModuleEnumerator(new MyConfigStore(modulesSection));
}

public class MyConfigStore : ConfigurationStore
{
    public ModulesConfigurationSection Section { get; private set; }

    public MyConfigStore(ModulesConfigurationSection section)
    {
        Section = section;
    }

    public override ModulesConfigurationSection RetrieveModuleConfigurationSection()
    {
        return Section;
    }
}

 

As you can see, by a simple overload of the ConfigurationStore, you can return exactly the modules section that you need. Note that this section is pre-retrieved by the same function that retrieves the “unity” configuration section.

Hosted Prism (or how to host Prism in the old projects)

Recently I’m playing a lot with Prism and Unity and was looking for a way to gradually bring Prism to the existing projects. If you have an existing GUI project and you’d like to start using Prism (without rewriting everything from scratch) stay with me – I’m going to show a way that worked for me.

In order to work with Prism you need a “root” window, or, how they call it, a “shell” window. But what if you already have a window? There is a solution to that.

First of all create a WPF user control that will become a “shell” window to Prism. The XAML rules for this control is not different from any other Prism “shell” window. Just the root element of it is a “UserControl” and not “Window”. Let’s call it “ShellContainer”.

Then you need to attach this control to your existing application. But first you need to tell the Bootstrapper about it, but you don’t need to activate it:

   1: protected override DependencyObject CreateShell()

   2: {

   3:     return Container.Resolve<ShellContainer>();

   4: }

If your project is Windows Forms-based, you’ll need to drop on your form an ElementHost control. This control is located on the toolbox in the WPF Interoperability group. This will allow you to host a WPF User control on you non-WPF form.

   1: // Get the ShellContainer from IOC

   2: IUnityContainer container = new UnityContainer();

   3: var shellElement = container.Resolve<myLib.ShellContainer>();

   4:

   5: // Attach the WPF control to the host

   6: hostControl.Child = shellElement;

If you have a WPF form you can add this WPF User Control either manually.

   1: // Get ShellContainer from IOC

   2: IUnityContainer container = new UnityContainer();

   3: var shellElement = container.Resolve<myLib.ShellContainer>();

   4:

   5: // Add the ShellContainer UserControl to the main window

   6: this.mainGrid.Children.Add(shellElement);

From this point on you are on a home run – just follow the rest of the Prism guidelines.

TIP: I found it convenient to put the ShellContainer with the Bootstrapper in the same class library with the rest of the configuration logic. This allows a clean separation of the infrastructure from the rest of the logic of the Prism modules.

Retrieving a ShellContainer from Unity

As I’ve mentioned in my previous post Hosted Prism, that you can add dynamically a Shell Container to your application. This time I’m going to show you how you can configure this container dynamically and have a possibility to replace it at any time without changing your code.

To do so I’m going to use a configuration file. It’s up to you to decide which one. You can use App.config, but I’ll recommend to have a separate file for your IOC, so the customers will not be exposed to a lot of nose and will not change stuff accidentally.

Create a config file (use any name you wish with .config extension – I’ll explain why in a different post).

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration" />
  </configSections>
  <unity>
    <typeAliases>

      <!-- Lifetime manager types -->
      <typeAlias alias="singleton"
           type="Microsoft.Practices.Unity.ContainerControlledLifetimeManager,
               Microsoft.Practices.Unity" />

      <!-- User-defined type aliases -->
      <typeAlias alias="UIElement" type="System.Windows.UIElement, PresentationCore, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

      <typeAlias alias="Shell" type="OwlHollowLib.ShellContainer, OwlHollowLib" />

    </typeAliases>

    <containers>
      <container name="global">
        <types>
          <type name="Shell" type="UIElement" mapTo="Shell">
	<lifetime type="singleton" />
          </type>
        </types>
      </container>
    </containers>
  </unity>

</configuration>

Note that in the “container[@name=”global”]” I’m associating the “ShellContainer” user control with the type “UIElement” and assigning a “Shell” name for this object. As well I’m marking this object to be a singleton, but this is not necessary if you need more than one ShellContainer in your application.

And this is how you can get a reference to the ShellContainer:

public partial class MainWindow : Window
{
    public MainWindow()
    {
        InitializeComponent();

        try
        {
            var configMap = new ExeConfigurationFileMap { ExeConfigFilename = "MyApplication.config" };
            var configuration = ConfigurationManager.OpenMappedExeConfiguration(configMap, ConfigurationUserLevel.None);

            var section = (UnityConfigurationSection) configuration.GetSection("unity");

            IUnityContainer container = new UnityContainer();
            section.Containers["global"].Configure(container);

            var shellElement = container.Resolve<UIElement>("Shell");

            this.mainGrid.Children.Add(shellElement);
        }
        catch(Exception e)
        {
            System.Diagnostics.Trace.WriteLine(e.ToString());
        }
    }
}

As you can see, you need to initialize UnityContainer from a config file. If you are using a standard App.config file – you don’t need to create an ExeConfigurationMap.

As soon as the UnityContainer is initialized – it’s available for you to start resolving objects and types. The trick in the code above is to resolve your components by their parent types and by an associated name. You can see it in the line #17. This will allow you in the future to replace one UIElement with another without recompiling the application.

Note: DO NOT use the same name (in quotes) as an existing class. The resolution doesn’t work! It looks like the default resolving is conflicted with the resolve-by-name operation.

The technique described above allows you to decouple your modules and create … a loosely coupled but cohesive application.

If you want to take this technique to the extreme and make Unity calls from WPF, you can check the series of posts by Denis Vuyka [Injecting Xaml with Unity Application Block using Markup Extensions].

Stay tuned for more Prism and Unity posts.

WPF Skin Factory – or how to skin your application

Here are a couple of very simple steps to follow to make your WPF application skin-friendly.

1. Create an empty WPF Windows Application (or use or old one)
2. Create a Skins folder and a subfolder for each separate skin (you’ll need it later if your skins become more complex)
3. Add a Resource dictionary (Add –> New Item –> Resource Dictionary) into each skin folder.
1. In this example we’ll create a Black skin with BlackResources.xaml and
2. Green skin with GreenResources.xaml
4. In the App.xaml add the following code in the <Application.Resources> section:

   <ResourceDictionary>

       <ResourceDictionary.MergedDictionaries>

           <!-- Use the Black skin by default -->

           <ResourceDictionary Source="Skins\Black\BlackResources.xaml"/>

       </ResourceDictionary.MergedDictionaries>

   </ResourceDictionary>

5. Let’s start (for simplicity) with skinning of the main window background only.
6. In each skin resource dictionary create a Brush resource:
   

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

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

    <!-- The Background Brush is used as the background for the Main Window -->

    <LinearGradientBrush x:Key="MainBackgroundBrush" EndPoint="0.5,1" StartPoint="0.5,0">

        <GradientStop Color="#FF2C952C" Offset="0"/>

        <GradientStop Color="#FFFFFFFF" Offset="1"/>

    </LinearGradientBrush>

</ResourceDictionary>

7. In the window’s XAML bind the window’s background brush to the skin dynamic resource by it’s name (note that we have to use DynamicResource, since we’re planning to change it while the application is still running to let the customers to change the skin):

<Window x:Class="SkinFactory.Window1"

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

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

    Title="Window1" Height="300" Width="300"

    Background="{DynamicResource MainBackgroundBrush}">

    <Grid>

        <Button Width="100" Height="100" Content="Toggle Skin" />

    </Grid>

</Window>

8. Let’s wire the “Toggle Skin” button with the functionality that will toggle between these two (Black and Green) skins:

   1: private void ToggleSkin_Click(object sender, RoutedEventArgs e)

   2: {

   3:     var rd = new ResourceDictionary();

   4:  

   5:     string uriSkin;

   6:     if (_bIsBlackSkin)

   7:     {

   8:         uriSkin = @"Skins\Green\GreenResources.xaml";

   9:     }

  10:     else

  11:     {

  12:         uriSkin = @"Skins\Black\BlackResources.xaml";

  13:     }

  14:     _bIsBlackSkin = !_bIsBlackSkin;

  15:  

  16:     rd.MergedDictionaries.Add(Application.LoadComponent(new Uri(uriSkin, UriKind.Relative)) as ResourceDictionary);

  17:     Application.Current.Resources = rd;

  18: }

9. Note: try to avoid hardcoding the resource dictionary path in the code. You can replace it either with a configuration file or with a simple file discovery.
   
10. You have to make sure that the resource files will be located in the output folder. To do so you need:
1. On the resource file properties set Build Action to Content
2. Set the “Copy to Output directory” to “Copy if newer”
   
11. Start the application.

You can take the sample source code here:

If you’ll toggle the button you’ll see the window background colors are changing.

70-502 – Congratulations to … me !!!

It was a looooong wait but it was worth it – just received a word from Microsoft that I’ve passed the 70-502 exam.

As I’ve mentioned in my previous post Reflections on the Microsoft WPF Certification BETA Exam (70-502) – it was not a hard exam but it definitely covered a lot of grounds.

Now I’m heading to a bar for beers – I’ve earned it