LOB help in the WinRT world - "Brokered WinRT Component Project Templates"

Brokered WinRT Components was one of the hits of Build 2014. These project templates will help you make your own...

Visual Studio Gallery - Brokered WinRT Component Project Templates

This package contains project templates used to created Brokered Windows Runtime Components and their Proxy Stubs, which enables side-loaded modern applications to communicate with pre-existing desktop components.

This solution works on Windows 8.1 update or later version.

It contains two project templates:

1. A C# project template for you to create the Desktop Windows Runtime components that are used to bridge modern application and pre-existing desktop code.

2. A C++ project template to generate the IPC proxy stub that will be used in your modern application.

For more details about the Brokered Windows Runtime Component, please review whitepaper on MSDN:

http://msdn.microsoft.com/en-us/library/windows/apps/dn630195.aspx

Here is a brief guidance on how to use the template to create a brokered WinRT component:

1. Create a new Brokered WinRT Component using the Templates -> Visual C# -> Brokered Windows Runtime Component (Let’s call this BrokeredComponent)

2. Make updates to Class.cs (change file name if needed) to define the component.

...

Brokered Windows Runtime Components for side-loaded Windows Store apps

[This documentation is preliminary and is subject to change.]

This paper discusses an enterprise-targeted feature for the Windows 8.1 Update that allows touch-friendly apps to use the existing code responsible for key business-critical operations.

Introduction

Windows 8 and Windows 8.1 brings an entirely new class of applications, designed for touch, running on a new generation of hardware optimized for touch, and using a new runtime and APIs. The new runtime, called the Windows Runtime, brings with it a host of new functionality, new APIs for existing concepts and new generations of UI frameworks (XAML and HTML) for these applications.

Note

The sample code that accompanies this paper may be downloaded from this location.

The new generation of applications have been designed to be distributed through the Windows Store and its related infrastructure. A new certifications process for these applications include requirements that deprecate a large number of older APIs and frameworks. While creating a vastly simpler programming surface for the new style and design requirements, many existing enterprise software assets have been left in a state of limbo. They continue to operate in their "desktop" world, but are difficult to leverage in the new touch-friendly applications. Calling these deprecated APIs or using the legacy frameworks causes issues to be raised in the WACK certification tool included in Visual Studio and run as part of Windows Store submission.

Recognizing that critical business functions and rules are embodied in existing software assets and that enterprises have a wide variety of scenarios for which the new application style will be highly productive, the Windows 8.1 Update includes a new feature called Brokered Windows Runtime Components for side-loaded applications. We use the term IPC (inter-process communication) to describe the ability to run existing desktop software assets in one process (desktop component) while interacting with this code in a Windows Store app. This is a familiar model to enterprise developers as data base applications and applications utilizing NT Services in Windows share a similar multi-process architecture.

Side-loading of the application is a critical component of this feature. Enterprise-specific applications have no place in the general consumer Windows Store and corporations have very specific requirements around security, privacy, distribution, setup, and servicing. As such, the side-loading model is both a requirement of those who would use this feature and a critical implementation detail.

Data-centric applications are a key target for this application architecture. It is envisioned that existing business rules ensconced, for example, in SQL Server, will be a common part of the desktop component. This is certainly not the only type of functionality that can be proffered by the desktop component, but a large part of the demand for this feature is related to existing data and business logic.

Lastly, given the overwhelming penetration of the .NET runtime and the C# language in enterprise development, this feature was developed with an emphasis on using .NET 4.5 for both the Windows Store app and the desktop component sides. While there are other languages and runtimes possible for the Windows Store app, the accompanying sample only illustrates C#, and the desktop component portion is restricted to the .NET runtime exclusively.

...

Personally I still think there's more required, much better distribution story, like  an inside-the-firewall app store, but this IS a good step forward and will help smooth the LOB Modern App way a bit...