WinRT component authoring: dependency properties and other limitations

As a .NET developer, authoring and deploying WinRT components for Windows 8 Store apps using XAML might be trickier than expected. Here are some annoying limitations and some workarounds that one can use, tough:

Classes must be sealed: In order to avoid code duplication, define a common set of static methods to encapsulate common functionality, and call them from the published classes as appropriate.
Only a limited set of WinRT types are accepted for the public members of your classes (even the well known DateTime type needs to be replaced with DateTimeOffset): You may use standard types internally and provide conversion functions to handle importing and exporting values (DateTime and DateTimeOffset make use of implicit casting to convert values seamlessly).
Fields cannot be public members of your classes; as a consequence, you cannot export dependency properties as they require public static read only fields defined in your owner classes:

You can still work with dependency properties by defining and marking the fields as internal and keep only the wrapper properties public, but note that this removes the standard dependency property features even when the application developers that use your components are also .NET developers like you.*

*

To resolve this issue, a possible workaround would be to deploy both a standard WinRT component (WinMD file) to be used by all Windows Store app developers (such as leveraging WinJS), and also a class library (DLL file) accessible as a reference in .NET languages based WinRT applications:

  • Create a component library project and also a WinRT component project in your Visual Studio solution, configuring them to share their output assembly names and namespaces (although the project files need to be named differently);
  • Have the common source code files actually saved in your component library, and add them also “as linked items” in your second project;
  • Mark the component library with a preprocessing symbol, such as “MANAGED”;
  • In your source code, whenever you have dependency properties to define, expose them as public when MANAGED symbol is defined, and otherwise keep them internal:
    #ifdef MANAGED
    public
    #else
    internal
    #endif
    static readonly DependencyProperty…

Setup (MSI) deployment project type (VDProj file extension type) is not available in Visual Studio 2012.

As as a workaround you can use a Visual Studio 2010 Setup project:

  • Note that WinMD file type isn’t supported for deployment; an error message is shown if you try to add such a file to the installation folder definition;
  • To resolve this final issue, you can change the WinMD file content a bit, for example changing the first byte from ‘M’ to ‘Z’ before deployment; this way the WinMD file is accepted as a simple file (not a known executable assembly) by the Setup project;
  • Finally, at installation time, using a Custom Action, an minimal tool may be run to prepare the actual WinMD file on the target computer by changing the first byte of the deployed file to ‘M’ again.

About Sorin Dolha

My passion is software development, but I also like physics.
This entry was posted in Computers and Internet and tagged , , , . Bookmark the permalink.

Add a reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s