Importing namespaces in Xaml for .Net for Metro Style

Importing namespaces in XAML is different in .Net Metro applications compared with WPF. The difference is subtle and caught me unawares…

In WPF, one imports a namespace using.

<Grid xmlns:Core="clr-namespace:Namespace;Assembly=AssemblyName"

This has changed to :


Note the ‘using:‘ rather than ‘clr-namespace:’

So its similar to syntax of import statements in c# code behind. The bonus is that you no longer need to specify the assembly name ( it is handled for you automatically).

System.Delegate missing Method Property in .Net for Metro Style Apps

This post is part of a series of ‘Lessons Learnt’ from  a recent conversion of Microsoft.Practices.Prism to Net Metro Prism. See  here for related posts

I got stumped on an issue with delegates whilst converting Prism to Metro  … In metro, A System.Delegate type doesn’t have a Method property. How can that be!?


One of the internal classes in the Prism library (DelegateReference.cs) acts a weak Delegate reference… It takes a Delegate type parameter in its constructor and records all of its information . It then allows the delegate to be freed from memory until the point it is meant to be fired; at which point it re-creates the delegate using the information it recorded.

I believe its used as part of the EventAggregator functionality to avoid having lots of active event handlers .


The existing  constructor attempts to record the MethodInfo from the Delegate using the following line of code.

string methodName = @delegate.Method;

In .Net for Metro this Method property is not exposed


My initial thought was that the delegate must know which method to invoke; so even though it is not exposed on the abstract Delegate class; it must be recorded a private variable. Perhaps the derived class will expose the method.

So I started the debugger; and used the immediate window to inspect the delegate as it was passed to the ctor.


Notice that you can see the Method property – [void DoEvent(System.String).

If I look at the base System.Delegate class then I can also see the same method:


The property is there and i can see the event. Yet intellisense and the compiler won’t allow me to access it.

…..!? Does anyone know what is causing this?

My initial thought is that there is a mismatch between the assemblies that Visual Studio/Compiler is using; and those that are in use from the GAC at runtime.


Instead of using a strongly typed Delegate; I referred to it using the dynamic keyword instead. This avoids the compiler checking; and allows me to write the code that queries the method property. As the Method property is in memory when running the app the code works as it should.

Error after upgrading to Wcf Data Service 5.0

I recently upgraded a WCF Data Service project to WCF Data Services 5.0  for OData v3. This upgrade has support for accessing your EF Code First entities via a Wcf data service.

There’s a good blog post on MSDN by Glenn Gailey with details on how to upgrade.

However, I started my upgraded service and got this rather unhelpful error message:

The server encountered an error processing the request. Please see the service help page for constructing valid requests to the service. The exception message is ‘On data context type ‘<type>’, there is a top IQueryable property ‘<propertyName>’ whose element type is not an entity type. Make sure that the IQueryable property is of entity type or specify the IgnoreProperties attribute on the data context type to ignore this property.’. See server logs for more details.

The cause of the problem was failing to remove all references to  System.Data.Services and System.Data.Services.Client from all my projects.

Following the guidance I’d removed all references to System.Data.Services.* from the main WCF data service project; but I had missed the indirect reference in my “Entity Model” Project.  Some entities  were marked with the [DataContractKey()] attribute; thus leading to the stray reference.

Removing all reference to System.Data.Service.* and replacing with Microsoft.Data.Services.Client.dll fixed the error.

(assemblies can be found in %programfiles(x86)%\Microsoft WCF Data Services\5.0\bin)

Where is Type.GetTypeInfo() in .Net 4.5/Metro apps?

This post is part of a series of ‘Lessons Learnt’ from  a recent conversion of Microsoft.Practices.Prism to Net Metro Prism. See  here for related posts

Where is Type.GetTypeInfo()!?

Most members from the System.Type class have been moved to the System.Reflection.TypeInfo class. All the documentation suggests you can get an instance of this type calling Type.GetTypeInfo(); but its not there?

>> Its an extension method and to use it you must include an import statement to System.Reflection:

using System.Reflection


Where are .Net Metro apps deployed and installed to?

The exe and assemblies can be found under C:\Program Files\WindowsApps  (need to add permissions to view folder)

Deployed Metro apps access application settings and runtime state information in C:\Users\<username>\AppData\Local\Packages

The  appxmanifest.xml can be found under C:\ProgramData\Microsoft\Windows\AppRepository  (need to add permissions to view folder)


Your application can be identified by matching the folder name with the name you provided in the Package.appxmanifest file included in your project.

Open Solution Explorer –> Package.appxmanifest:


Open the Packaging Tab:


In File Explore navigate to C:\Users\user\AppData\Local\Packages. –> Locate folder via name


Resources (.resw) and ResourceLoader in .Net for Metro Style Apps

This post is part of a series of ‘Lessons Learnt’ from  a recent conversion of Microsoft.Practices.Prism to Net Metro Prism. See  here for related posts

In Metro there is a whole new improved mechanism for dealing with resources and localization. Its quite powerful; allowing one to embed text, images  and even Resource-Dictionaries that can vary from one locality to another.

If you’re used to Resource.resx files (for specific language/culture);  then you may be surprised to find its not an option with Metro Apps.  Instead the new file type is a Resource.resw that allows one to enter String Resources.

A quick web search of this new resource file gave me the wrong impression of how to do localization in Metro. Many forums commented on the lack of the usual auto generated code to access resources. Most suggested avoiding ResourceManager and using ResourceLoader. Others commented that embedding localized image resources in metro is not supported.

It true that the new preferred way of loading resources is using the ResourceLoader class

A number of code snippets show the following code:

ResourceLoader rl = new ResourceLoader("MyAssembly/Resources"); string localizedString = rl.GetString("MyLocalizedStringKey");  

This code will access any resources you add to “MyAssembly/Resources.resw”   

….but I was left a little confused. How do I know the path to specify for my Resource file?   How can I swap between different languages using this? I also wanted to know how to change images based on the current language of the user.

Fortunately I kept looking and came across this 3 part blog post, Part 1, Part 2and Part 3 – that do an excellent job of explaining it all.

Basically you organise you’re solution so that it contains folders for specific language codes. For example:


You add a resources.resw into each folder and put the appropriate language variants in each

You simply create an instance of ResourceLoader without passing a specific resource file into the ctor:

ResourceLoader rl = new ResourceLoader(); string localizedString = rl.GetString("MyLocalizedStringKey");

And voila, you app will magically have the correct language based on your windows language settings. (To understand the magic, read Part 2and Part 3)

You can access the current User’s language choice using Windows.System.UserProfile.GlobalizationPreferences.Languages. This returns the list of language choices (a user can have a order (or fallback) of preferred languages). The most preferred language is first in the list.

var languages = Windows.System.UserProfile.GlobalizationPreferences.Languages; string preferredLanguage = languages.ToList()[0];

Images (and other Assets) work in exactly the same manner. Just name a folder after the language code you’re catering for and add similar resources into it. See below



  • Do use an appropriate language code (en-GB, fr-FR)
  • Do use a consistent name for assets in each language folder (flag)
  • Do remember case sensitivity (it has to be consistent)

Now to use my localised flag.png file I simply use the following line of code:

myImageControl.Source = new BitmapImage(new Uri(@"ms-appx:/Assets/flag.png"));

Notice that I do not refer to a specific file in my application; simply the assets folder.

Also notice the use of ms-appx: – In metro you cannot use relative Uri to a resource – it must be absolute. ms-appx:  is equivalent of using [packagename]

So now I could vary my application based on the users preferred language. As the user changes between English (en-GB) and French (fr-FR) language, the application automatically updates the greeting and the  flag displayed:

image image

To automatically respond to a user changing language (cos that happens every day), there is an event that you can subscribe to.

var manager = Windows.ApplicationModel.Resources.Core.ResourceManager.Current; manager.DefaultContext.QualifierValues.MapChanged += QualifierValues_MapChanged;


If anyone wants the source code for this app; then let me know and I’ll make it available

Converting Prism to .Net for Metro Style Apps

I recently converted Prism to work with .Net for Metro Style Apps.

You can get the project on codeplex at 

Its a pragmatic conversion; but keeps most of the existing functionality that you get in Prism 4.1 apart from features that don’t naturally work within Metro (such as reflectively loading modules). I’ve kept the namespaces intact; so its easy to replace with the official Prism framework when it is ready. However, I have renamed the assemblies to avoid any confusion.

It uses a MetroIoC  – (port from microIoc  done by Ian Randall) as the only IOC container I could find to work with Metro style apps.

My aim was :

  • Get a functioning Prism framework to help create a modular Metro App (…and to help convert some desktop apps I’ve created using Prism 4.1)
  • Learn the differences between .Net 4.0 and .Net for Metro Style Apps
  • Learn the pitfalls of moving apps from the Desktop to Metro

I’ll write up a few posts with details of the conversion and a few lessons learnt.

I’ll aggregate in this post and on codeplex at

Resources (.resw) and ResourceLoader in .Net for Metro Style Apps

Where is Type.GetTypeInfo() in .Net 4.5/Metro apps?

System.Delegate missing Method Property in .Net for Metro Style Apps