Windows 8 Store Apps: Class Library vs. Windows Runtime Component

October 30, 2012

no comments

When working with Windows 8 Store apps in C# (or VB, but I’ll stick with C#), there are several ways of creating reusable (or at least seemingly reusable) class libraries for Windows 8 Store projects. In this post, I’ll take a to look at the options, contrasting their features and usefulness.

Looking at the new project dialog in Visual Studio 2012, under the Windows Store node (under Visual C#), we can see the following:

SNAGHTMLa50e07

There is a third option, the traditional Class Library project located under Visual C# / Windows. Where does that fit in?

A Windows Runtime Component project is a DLL that can export WinRT types. This means this project produces a metadata file (.WINMD), that can be consumed by Windows 8 Store app projects (or other Windows Runtime Component projects) in any supported projection language, such as C++, C# and JavaScript.

A Class Library (Windows Store apps) project is a DLL that can be used by Windows Store apps written in .NET languages only. The critical difference – no metadata file is created, so this cannot be used with other languages, as there is no common ground.

So, why would we not use Windows Runtime Component at all times? This seems to be the more flexible choice. The problem with this kind of project is that every public type must be a WinRT type – that means it must be sealed, it can’t inherit from anything (unless it’s something in the Windows.UI.Xaml namespace, such as Control and UserControl). Public fields are not allowed, making declaration of dependency properties a little harder, by forcing a split between a private static field and a public static property. As a simple example, the following does not compile in such a project:

    public abstract class ObservableObject : INotifyPropertyChanged {
        public event PropertyChangedEventHandler PropertyChanged;

        protected void OnPropertyChanged([CallerMemberName] string name = null) {
            var pc = PropertyChanged;
            if (pc != null)
                pc(this, new PropertyChangedEventArgs(name));
        }
    }

This is classic base class for MVVM support. This does not compile, because an abstract class cannot be exported. We can remove the “public” then this will compile – but will not be exported, so nothing outside this assembly would be able to use it. In a Class Library (Windows Store apps) project, this would compile fine and be usable from other like-assemblies.

What about a plain vanilla Class Library? That is not usable from a Windows Store app, because it uses the full .NET framework, and not just the subset allowed in WinRT. This is exactly what Class Library (Windows Store apps) ensures.

Conclusion

If you’re writing .NET code to be used by other .NET libraries/apps for Windows Store, Class Library (Windows Store apps) is a more flexible choice. If you want the library to be used by any WinRT-compliant language, Windows Runtime Component is your choice.

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*