Over the last couple of decades, the amount of boilerplate code necessary to develop Windows applications has increased dramatically, which takes away from .NET's early roots as a Rapid Application Development (RAD) framework. Microsoft's attempt to counter-act this is the Windows Template Studio for UWP applications.

The Windows Template Studio is a scaffolding tool, much like you would find as command line tools for Node or ASP.NET MVC (though being a Visual Studio extension, Windows Template Studio is all point-and-click).

Out of the box it supports three project styles: Blank, Navigation Pane, and Pivot & Tables. This year they are intending to add a more traditional Menu Bar style.

In the past, Microsoft's project templates assumed you would be using only Microsoft libraries. Windows Template Studio differs in that you can choose a "design pattern" which includes the appropriate 3rd party library. The current list is code behind, MVVM basic, MVVMLight, Caliburn.Micro, and Prism.

A variety of page types are included:

Settings

Web View

Media Player

Master/Detail

Telerik Data Grid

Chart

Tabbed

Map

Camera

Image Gallery

Ink Draw

Ink Smart Canvas

Ink Draw Picture

Separately, Windows Template Studio can wire in "features" such as:

VS App Center Analytics

3D App Launcher, for "Mixed Reality" environments

URI Schema, for launching the application using a custom URL.

Web to App Link, which launches the application in lieu of the website

Settings Storage

Suspend and Resume

Background Tasks

Share Source, which allows sharing text, links, images, etc. with other applications

Share Target, for accepting shares from other applications

Toast Notifications

Azure Notifications

Dev Center Notifications

Live Tiles

First Run Prompt

What's New Prompt

Feedback Hub Link

Drag & Drop, both app-to-desktop and desktop-to-app

A common complaint for Microsoft templates is they are often not "production ready" and violate best practices for the platform. As a way of addressing this, the Windows Template Studio has defined a set of principles for templates and generated code.

Generated templates will be kept simple. Generated templates are a starting point, not a completed application. Generated templates once generated, must be able to be compiled and run. Generated templates should work on all device families. Templates should have comments to aid developers. This includes links to signup pages for keys, MSDN, blogs and how-to's. All guidance provided should be validated from either the framework/SDK/library's creator. All features will be supported for two most recent RTM Windows 10 Updates. Those supported releases are Windows 10 Creators Update and Windows 10 Fall Creators Update. Templates released in production will try to adhere to the design language used in the current release of Windows 10. Code should follow .NET Core coding style.

Project Structure

The project structure can vary depending on which options you select, but some things are common. For example, you'll get separate folders for data models and view-models.

As per the MVVM pattern, each view-model directly reflects the view it is associated with. In our first test we chose Caliburn.Micro as the design pattern, so each view-model inherited from Caliburn.Micro.Screen. Views themselves are divided into a "views" folder and a "controls" folder depending on how they are used.

With the Caliburn.Micro design pattern, dependency injection is enabled and pre-configured for the view models. This uses the Caliburn.Micro ViewModelLocator. Other services are wired in depending on use.

If instead you choose the MVVM Basic design pattern, view-models are created automatically by their respective views without the need for a DI framework. This demonstrates Microsoft is making a serious effort to honor the developer's choice rather than force a certain application design.

As you would see in a website, there is a "styles" folder containing resource dictionaries that drive application-wide styles. For those of you unfamiliar with UWP, a resource dictionary is the equivalent to CSS file.

Internalization support is backed into the templates, with the normal .NET string resource files organized by language/culture.

First Impressions

Setting up the first project using Windows Template Studio is slow. After the initial code is generated, the process seems to hang while it downloads and caches libraries. This doesn't affect later uses of the tool.

Adding new pages/features actually works as expected. For example, when using a design pattern with a DI framework you can see a preview of how that DI code will be modified to accommodate the new page.

And it doesn't stop there. If you add a Map page to an already existing project, it is intelligent enough to update app manifest with the necessary permissions. This is a level of detail that is rare among scaffolding tools.

But at the end of the day, it is still a UWP app with all of the limitations that entails. In tomorrow's report, we'll look at ways Microsoft is trying to make UWP more appropriate for line of business applications.