Now I’m a MCTS: Win Forms (are we still using them?)

Another one for my collection:  Microsoft Certified Technology Specialist: .NET Framework 3.5, Windows Forms Applications

And the total is:

(I think that there is one more empty spot in this logo … Hmm…)

Data in the Cloud: Data Camp presentation in Waltham

It was a lot of fun to present last Saturday at the very first Data Camp that was held in Waltham.

Almost every company I worked with needed some ways to store and process huge amounts of data on the cloud – that includes Intel, ICQ/AOL, Symantec and Broadserve. The latter was the worst case scenario – it was an online multimedia streaming on demand.

So, as you can guess, I’ve learned a great deal about this “trade” and, after release of Amazon AWS and, now, Azure, I’ve become a happy man – no more need in setting up and managing your own infrastructure.

In my view, the “DATA in the Cloud” is actually a mix of the following 3 main aspects (“pillars”):

1. Data Storage
2. Data Processing
3. Data Delivery
4. Access Control (Authentication + Authorization)

Yes, I know – it’s four, but where can you go without mentioning the last one? Nowhere – you’ll be eaten alive

In this presentation I’ve tried to distill all the different ways that Azure Fabric (Platform and Services) helps you to address all the (first) 3 aspects of working with the “Data in the Cloud”.

Enjoy the presentation!        (URL is here) 

While at this: I’d like to thank the organizers of the Waltham Data camp and Microsoft for providing support and the great location!!!

Note the change in my status – MCPD

This morning I have received a notification that I’ve passed one of the MCPD exams (others are still in Beta). Cool !!!

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.

More information on MEF

If you’re interested in Composite Applications in general and in MEF in particular – you may find Glen Block’s blog interesting.