Auditing your Windows Javascript UWP application in production

Since the launch of Windows 8, I’m writing native Windows applications using HTML and JavaScript, for the Windows store and for enterprise applications. Believe it or not but I’m doing it full time and, so far, I’m really enjoying it. I know many people will disagree, especially in the Windows ecosystem, but I’m really enjoying the productivity and the expressiveness you get by writing rich client applications using HTML. And the beauty with Windows 8, and now Windows 10, is that you have full access in JavaScript to the Windows API, from rich file access, to sensors, Cortana integration, notifications, etc.

Even better, with Windows 10 and the Universal Windows Platform (or UWP) you could write one single application using HTML and JavaScript that will run on Windows desktop, laptop, tablet, phone, IoT devices, Xbox, Hololens and probably much more.

If you are familiar with the web ecosystem, you could also very easily reuse most or all of your skills and application code and use it to build awesome websites, or target other devices, with Github electron to make a Mac OsX version, or use Cordova or React native to reach iOS or Android. It really is an exciting time for web developpers.

As exciting as those experiences have been, there are a few things that are still frustrating. No matter what technology you use for development, one of them is the ability to detect and troubleshoot problems when your application have been released into the wild. Visual Studio is really great and provide many tools to help debug and audit your app on your dev box, but for troubleshooting applications in production, you’re naked in the dark.

Luckily when using web technologies, you could use some wonderful tools like Vorlon.js. This tool is really great because you could target any device, without any prerequisite. You have nothing to install on the client to have great diagnostics from your app.
I previously explained how to use Vorlon.js in production, and how to use it with your JavaScript UWP, follow those post if you want to setup the stage. In this post, we will see an overview of what you can achieve with Vorlon.js for a Windows UWP app in production, and a few guidance. What we will see is not specific to a JavaScript UWP. You could use the same things to debug a Webview in a C# or C++ application.

Inspect the DOM

Vorlon.js is designed from the ground with extensibility in mind. It features many plugins, and you could really easily write your own (we will talk more on that later). One of the most usefull for frontend applications is the DOM explorer. It’s very much like the tools you will find in the developper tools of your favorite browser.
For troubleshooting issues in production, it is very interesting to see what appened into the DOM, what styles are applyed, check the current size of the user screen, etc.



Watch the console

Another core plugin of Vorlon is the console. It will shows all console entries in your dashboard. If you put meaningful console logging into your app, this plugin is insanely usefull because you see in (almost) realtime what the user is doing, which is key to reproduce the issue. With some luck (and coding best practices), you could also have errors popping directly in the console with the stack trace (if the Promise god is with you). The console also feature an « immediate window » where you could issue simple JavaScript commands.


Check objects value

You could also have access to global JavaScript variables using Object explorer. This plugin allow you to watch values from your objects, and explore graph of objects. It’s always interesting to be able to keep an eye on your application state when trying to troubleshoot your application.


Monitoring CPU, memory, disk, …

You sometimes have to face more insidious bugs, like memory leaks, that usually requires advanced debugging tools. In the comfort of your dev box, you could use IDEs like Visual Studio to diagnose those bugs with specific tools. Modern browsers usually have similar tools, but does not have APIs to check things like memory or CPU that you could use remotely. Fortunately, when you are targeting Windows UWP, you could have access to all modern Windows APIs, and especially those about diagnostics.

That’s why the Vorlon team implemented a plugin specific to Windows UWP. It uses WinRT APIs for diagnostics and for different metadata from the client. For now, this plugin is not released, and you will have to look at the dev branch to try it out.


From the application metadata, you will get infos, such as its name, but also the application version, current language, and device family.


You will also have a glimpse at the network kind and status, and the battery level of the device.

It enables you to monitor the CPU, the memory and disk I/O. It’s especially usefull to track memory leaks, or excessive resources consumption.


And much more…

You have many more plugins within Vorlon that will help you diagnose your app, monitor xhr calls, explore resources like localstorage, check for accessibility and best practices, and so on. We cannot cover them all in one post, but I hope you get a decent idea of the many possibilities it is unlocking to help you improve your applications, both during development and more than anything, in your production environment. It’s especially usefull for mobile applications such as Windows UWP.

Writing plugin for Vorlon.js is really easy. You have to implement one javascript class for the client, and one other for displaying results in the dashboard. Writing a simple plugin can sometimes helps you save a lot of time because it can helps you analyse the problem when and where they occur. If you are proud of your plugin, submit it back to Vorlon.js !

Using Vorlon.js in production

Vorlon.js is a great debugging and auditing tool. It is designed to help you with any web technology. It works great for a website, an application with Apache Cordova or with Windows UWP applications, or even now with Node.js and Office addin (as the time of this writing, Office addin support is in dev branch).

It is great during development because you have one common tool to address many different devices, but that’s not the only way to use it.

Have you ever had a mobile website that shows problems on some device that you don’t have at hand ? or users reporting strange behavior and you cannot access it ? Vorlon can really help you diagnose problems in production, having access to console, objects, and so. But in production, you might have to integrate it in a slightly different way. In production, you probably don’t want to have it active by default to save performances, battery, network and other resources.

Fortunately, Vorlon.js comes with a small helper that will help you to turn it on, on demand. The idea is to embed a very tiny client in your application, and provide a way to your user to activate Vorlon. It could be a button in your about page, an easter egg of some sort (why not using the Konami code ?), or whatever way you would like.

Adding production client library

Let’s see how to do it. If you run Vorlon locally with default options, you have it running on « http://localhost:1337 ». The client script is available at « http://localhost:1337/vorlon.production.js ». Add a script tag pointing to it in your application like this :

<script src="http://localhost:1337/vorlon.production.js"></script>

Add it first in the head of your page, and immediately after, create an instance of Vorlon.Production :

<script type="text/javascript">
if (VORLON && VORLON.Production){
    var vorlonProd = new VORLON.Production("http://localhost:1337", "mysessionid");

By default, this code will not do anything, and it will have no impact on your app. It just allows you to turn Vorlon on when you will need it. As you probably noticed, you specify the URI for your Vorlon server, and the session id you want to use.

Turning Vorlon.js on

Now you could use your instance of Vorlon.Production to activate it with a simple function call.


The call to activate will add the vorlon client script to your page. It also adds a flag in sessionStorage. It means that Vorlon will still be active for the lifetime of your browser if your user navigate from page to page (or the lifetime of your app if you use Cordova or Windows UWP).

Sometimes you may want to force your page to reload when activating Vorlon, especially when you are auditing a single page application. To do that, just add true to your call to activate.


Persisting Vorlon activation

Some bugs die hard. You may want to persist Vorlon activation and deactivate it explicitely. To do so, you must create your Vorlon.Production with an additional argument :

<script type="text/javascript">
if (VORLON && VORLON.Production){
    var vorlonProd = new VORLON.Production("http://localhost:1337", "mysessionid",true);

With that argument, activation token will persist using localStorage instead of sessionStorage. It means Vorlon will be active until you explicitely turn it off. You could do it by calling « vorlonProd.deactivate() ».

We really hope you are enjoying Vorlon.js. Feel free to get in touch through the GitHub page.

If you run Vorlon, you could try the production helper in the sample page.

Using Vorlon.js with your Windows 10 JavaScript UWP

Vorlon.js is a great tool for diagnosing and auditing any application built with web technologies, and Windows JavaScript applications, or UWP are no exception. It means you could use Vorlon to diagnose your app running on PC, tablet, phone, Xbox, Hololens, Raspberry Pi and any device supporting Windows IoT.

However, for being able to use Vorlon.js in a UWP, you will have to configure your application sandbox to enable communication between your app and Vorlon.js server (or desktop app).

In this post, we will illustrate the different aspects for a packaged application (a JavaScript application that embeds pages, scripts, styles, …) because it is the most complicated, but what we will see here will work equally well for a hosted app (an app where pages, scripts and styles are hosted on a web server). In fact, what we will see here could also help you using Vorlon.js in a webview for a C# application.

Put your application in web context

This step is very specific to packaged applications. Packaged applications runs in a very specific security context where resources can only be loaded from inside your package. It means that you cannot use a script tag which « src » attribute points to a resource outside of your package.

For using Vorlon, you will have to force your app into a web context, allowing you to use alien resources. Be aware that doing this is a weakpoint in your app’s sandbox. It’s not a major one but do it only if you have the need to.

Putting your app in web context is very easy. You just need to update a couple entries in the manifest of your application.

First, you must change your start page. If your start page is named « default.html », replace it with « ms-appx-web:///default.html ». You could do it by editing the appxmanifest.xml, or by opening your manifest within Visual Studio.


In application context, you have access to WinRT API, but not in web context. To bring it back; you must add your start page to Content URIs. Again, you could do it manually in your manifest or with Visual Studio. Go to the content URIs tab and add a URI to « ms-appx-web:///default.html ». Don’t forget to enable WinRT by choosing « All » in « WinRT Access ».


Allow your Vorlon.js client script

Now we must allow our app to access Vorlon.js client script. This step is required for packaged and hosted JavaScript UWP, or if you want to use Vorlon in a webview in a C# app.

First you must take note of your Vorlon.js server URI, and add it to the content URIs for your app. I will use a local Vorlon instance running on localhost on port 1337.

Open your manifest with Visual Studio and go to the Content URIs tab. Add Vorlon server URI to the list. In my case, I must add « http://localhost:1337 &raquo;.


Enjoy !

You are ready to go, just start your Vorlon server and your app. If you have followed the steps above, you are now able to inspect your app. The screen capture bellow shows the WinRT API with object explorer !


If it’s not working properly, look for messages in the console in Visual Studio. You probably have misspelled some URI and errors should show up there.

Happy Vorlon.js 🙂


How to use Vorlon.js desktop

Vorlon.js is now available as a desktop version for Windows and Mac OSX. You could dowload them on Vorlon.js website and get started using Vorlon in a few seconds.

If you want to know more about Vorlon, check out this getting started video. There are also some great articles about using Vorlon.js. In this post, we will focus on the desktop version and its UI.

Vorlon desktop helps you use Vorlon to debug your website without setup  pre-requisites, and help you start and configure your environment very easily.


On the left side, you have a menu bar.


It gives you access to Vorlon’s logs, settings, and the about page with usefull info and links.

The default settings will probably fit your needs, but you could change it with the dedicated screen. It might be usefull, especially if you need to change ports (if you want to run it side by side with the server version of Vorlon for example).


To start debugging your website using Vorlon.js, just add this script to your website or application (it’s so usefull for cordova applications !):

<script src="http://MCNTAB011:1337/vorlon.js"></script>

Vorlon has a session mecanism to differenciate client web sites and applications. If you want to define a session, you just have to specify it in the url like this :

<script src="http://MCNTAB011:1337/vorlon.js/mysession"></script>

When using the desktop application, it’s likely that you will stick to the home screen. From there, you could see if Vorlon server is running, and start or stop it easily (Vorlon server will start automatically when you launch the application).

vorlon status

The desktop version also helps you manage your sessions, and configure Vorlon plugins for each session. The home page displays the list of connected and configured sessions. You could add and configure a session even if no client is connected.


The green dot indicate that the session is in use. The empty dot means that there is no client connected.

session options.PNG

For each session, you could see the number of connected clients, and open the Dashboard for that session.


The last button helps you configure your session. You could choose if the client must receive (if your website already use, turning this off may helps), and turn each plugin on or off.

session config.PNG

We really hope you will enjoy the desktop version. It’s a great way to get started using Vorlon.js. We welcome any feedback so feel free to join us on github to log your feedback or any issue you may have.


Bringing Vorlon.js to the desktop

Setting up Vorlon.js is really simple. You just have to clone the github repository and run 2 simple shell commands :
npm install
npm start
If you are familiar with git and node.js it really is a very easy and usual way to setup a web tool. If it sounds like a foreign language to you, I sincerely invite you to dig a little to become familiar with this. But…
When you look away from the blog posts writers, you will find out that many developpers don’t know about git and node.js. Some call them « dark matter developpers ». For those people, « npm install » may feel scary, and will begin by an internet search with something like « what is npm ». As a contributor to Vorlon.js I really feel concerned about user adopting and trying Vorlon for their every day « web debugging in hostile environment », not just the up-to-date developpers.
What if we could simply wrap Vorlon into an executable ? just download, and run the executable and you’re good to go. Well, we have done it, and it’s cross platform. The Windows and Mac OSX are available right now on Vorlon.js website. The linux version is missing for now. To be honest it’s just because I don’t have a linux machine at hand, and could not find time for setting up a VM. If you are volunteering for building the linux version, please get in touch !

Making a cross platform desktop app with web technologies

Vorlon.js is written with Node.js, and rewriting it with another technology would have been unwise, and a pain to maintain. In the web world you have some tools to make desktop apps. The more advanced projects are NW.js (aka node webkit) and electron (aka atom shell). Both tools works by combining Chromium (Google Chrome open source engine) and node.js. Those tools have subtle differences I won’t detail here.

For Vorlon we choose electron because it’s more oriented on the node.js part, but nw.js would probably have been great.

Making this desktop version has been easier than I previously thought, and it was really fun. The hardest part was about learning more on node.js to spawn Vorlon.js server process. The rest was just a thin ui layer on top of configuration and displaying active sessions. We intentionnally choose to keep the session dashboard as it is in the web version.

How to build the desktop version

If you want to see for yourself how easy it is, you could get to the github repository and grab the sources. Sources for the application is in the « desktop » folder. You will have to run « npm install » in the root folder to build Vorlon server. After that, you must install the modules for the desktop application. We do not initialize them with other parts of Vorlon because electron is a little fat and will take some time to download. Go to the « desktop » folder and run « npm install » and « npm start » in that folder. You should now see the desktop app running.
All the vorlon team is really proud of this new addition, and we hope it will make it easier for you to try Vorlon and debug your web sites and applications. If you have troubles or any suggestion, feel free to log it on github.

#UWPHTML – using application insights in your Windows web applications

Publishing an application is a great experience. You really feel self-accomplishement when users provide good feedback (and ratings if you are Lucky). And then a few users reports errors but you can’t reproduce them. When your application is in the wild, you realize very quickly that you need something to get feedback from your app. Knowing what your users are doing with your application is also very valuable to help you focus efforts where you need to.

Without noticing you slipped from developping a hobby application to entering the world of analytics. You know, those little nasty snippets that your customers always asked you to put all around like Xiti or Google analytics.

Microsoft has it’s own solution for application analytics called Azure Application Insights. This tool has free and paid options depending on how long you store data, and the number of events you want to manage.

When you create a C# UWP application, Visual Studio has an option to integrate Application Insights for your project.

Unfortunately, you don’t have that same option when using UWP in HTML/JavaScript. In that case, you will have to do all plumbing manually. Microsoft provide a SDK for using Application Insight in JavaScript. It works well but this SDK is really oriented toward web applications, both in the sdk and in the structure of the Dashboard. Even worse, if you choose to type your application insights instance to a Windows application, some of the events (like errors…) does not show up in the Dashboard when sended with Javascript SDK.

For « Bring the popcorn« , it really is a Windows native application and we wanted to get the appropriate Dashboard and reporting. After some time spent with Fiddler comparing items sent to app insight from C#  and javascript, we narrowed down the différences in metadata.

We wrote small a wrapper for JavaScript sdk that adds those metadata and everything starts working fine.

This wrapper is published in WinJSContrib but we made it in such a way that it will work without WinJS or WinJSContrib.

Using application insights in your Windows Web Application is now very easy. You will first need to declare your application in application insights. When declaring your application, choose « Windows store application » for application type. When your instance is ready, go to it’s properties and get the « instrumentation key ». You will need this key in your application.

Now you are ready to integrate App Insights into your application. Go grab Application Insight Javascript SDK, and our wrapper, and add reference to them in your application.

In your application bootstrap code, you could now add something like this :

var appInsight = new WinJSContrib.WinRT.AppInsight({ instrumentationKey: "yourInstrumentationKey" });
appInsight.tracker.trackEvent("app start");

The wrapper will inject the appropriate metadata to have your events displayed in the Dashboard. It also registers to global « error » events, and send the corresponding errors to application insights.

If you are using WinJS, you could also have page navigation events for free :


If you want to see a real world example, you could check how we use this in Bring the popcorn.

#UWPHTML – Building Windows 10 web applications

Many people still ignores it, but since Windows 8 (and 8.1 for Windows Phone), you can build Windows native applications using HTML and JavaScript. Yes you read it correctly NATIVE applications. Those applications does NOT run through a webview but with a native HTML/JavaScript application shell called « wwahost ». Those applications are now called « Windows web applications ».

Windows 10 introduced a few enhancements to Windows web apps. They run with a different security context and on Microsoft Edge engine. There is also something called « project Westminster ». More simply, Westminster is « hosted applications », or applications that runs with content hosted on the internet but still have access to Windows APIs. You could find more about hosted apps on our blog, or obviously on Microsoft’s blog.

Windows web apps are fully parts of the new concept of Universal Windows Platform applications. It means that you could make applications using HTML/JavaScript for Windows desktop and tablet, but also for Windows 10 mobile, Xbox, Windows IoT, and the soon to come Hololens.

This post is the first of a serie where we will talk about various aspects of Universal Windows web apps using HTML and JavaScript. We will illustrate the different topics with a real application called « Bring the popcorn », a remote controller for a Kodi or Xbmc media server.

This application is open source, and available in the Windows store. It uses WinJS and WinJSContrib to provide a fast and fluid experience, using the latest features of Edge and Chakra engine (or at least those made available in web apps…).

Hope you will enjoy this serie !

Writing Windows 10 App Services in JavaScript

What is an App Service ?

Windows 10 introduce a bunch of new ways for applications to communicate with each others. One way is to implement « App Services ». App Services are a request/response model where one app can call a service located within another app. App Services enable communication between apps, but also with the system. If you want to implement interactive scenarios with Cortana, you will have to implement an App Service to provide data to Cortana.

If you’re the kind of people who prefer code than blabla, you may head directly to the github repository with sample applications.

App Services use the same infrastructure as BackgroundTasks, and most of the logic and implementation details still applies. It means that when your service is called, you don’t have the whole application running, but only your service. It also means that your application don’t communicate directly with your App Service. For example, your application does not get notify when your service is called, or terminated.

In all resources I can found (Build session, Channel 9 videos, samples, …), App Services are implemented in C#. Those resources are really helpfull (especially this one on Channel 9), but if (like me) you are writing apps in HTML and JavaScript, it is likely that you prefer writing those services in JavaScript and share business code with the rest of your application. Porting C# resources to JavaScript is actually very easy. In this post, we will dive into implementing an App Service in Javascript, based on a C# sample from Microsoft Virtual Academy.

Show me some code !

In a Windows Web Application (Windows application written in HTML and JavaScript), a background task, therefore an App Service, should be thought of as a special Web Worker (no postMessage with it unfortunately). It’s a standalone JavaScript file that will get caught independently by the system.

The first step to implement your App Service is to create this file. As with web workers, you could use « importScripts » to reference any code you want to share between your app and the service. Be aware that, like with Web Workers, there is no « window » or « window.document » objects inside your background task or app service. The global context points to a completely different beast, and there is no DOM.

Inside your task or service, you will access to the current instance of the BackgroundTask object using WinRT APIs, and get a deferral on it to control the lifecycle of your service. As with background task, your service can also be canceled by the system if it needs to recover memory, or if battery is running low on the device. Your task instance provide a « cancel » event that will get caught is such cases.

A minimalistic background task/app service would look like this

var backgroundTaskInstance = Windows.UI.WebUI.WebUIBackgroundTaskInstance.current;
var triggerDetails = backgroundTaskInstance.triggerDetails;
var bgtaskDeferral = backgroundTaskInstance.getDeferral();

function endBgTask() {
    backgroundTaskInstance.succeeded = true;

backgroundTaskInstance.addEventListener("canceled", function onCanceled(cancelEventArg) {
    return endBgTask();

Now we must declare this file as an App Service. For that, we must add an extension to our application in its manifest, pointing to our javascript.

    <Application Id="App" StartPage="default.html">
            <uap:Extension Category="windows.appService" StartPage="js/appservice.js">
                <uap:AppService Name="MyJavascriptAppService"/>

As you can see, we provide the path to our JavaScript file, and we are giving a name (MyJavascriptAppService) to the App Service.

Now we must implement the service logic. To do that, we will check the trigger details on our background task, and register for a request event. When the event gets activated, we received an App Service request. This request will contains a message (with request arguments), and a sendResponseAsync method to reply to the caller. On both sides, the values in the request and in the response are provided with a ValueSet object.

//check that the app service called is the one defined in the manifest. You can host
//multiple AppServices with the same JavaScript files by adding multiple entries in the application manifest
if (triggerDetails && == 'MyJavascriptAppService') {
    triggerDetails.appServiceConnection.onrequestreceived = function (args) {
        if (args.detail && args.detail.length) {
            var appservicecall = args.detail[0];
            //request arguments are available in appservicecall.request.message
            var returnMessage = new Windows.Foundation.Collections.ValueSet();
            returnMessage.insert("Result", 42);

Calling your App Service

The app calling your service can be any app. If you want to restrict access, you will have to implement your own security mecanism. As you may have understood, the caller and the callee doesn’t have to be written in the same language. You can call a service written in C++ from a JavaScript app. All data are passing throught Windows APIs.

Calling the app service require some arguments, the caller should provide the package family name (PFN) of the target application, and the name of the App Service (as declared in the target’s app manifest). If you don’t know your PFN, you can get it through WinRT APIs by calling « » in your service application.

Using the PFN and service name, you will first get a connection to your App Service, and register to the « serviceclosed » event to be notified if your service terminate.

function getServiceConnection(){
    var connection = new Windows.ApplicationModel.AppService.AppServiceConnection();
    connection.appServiceName = "MyJavascriptAppService";
    connection.packageFamilyName = "...your PFN here...";

    return connection.openAsync().then(function(connectionStatus){
        if (connectionStatus == Windows.ApplicationModel.AppService.AppServiceConnectionStatus.success) {
            connection.onserviceclosed = serviceClosed;
            return connection;
        else {
            return WinJS.Promise.wrapError({ message: 'service not available' });

Once you get a valid connection, you will be able to send requests to the service

function callService(){
    return getServiceConnection().then(function (connection) {
        var message = new Windows.Foundation.Collections.ValueSet();
        message.insert("Command", "CalcSum");
        message.insert("Value1", 8);
        message.insert("Value2", 42);

        return connection.sendMessageAsync(message).then(function (response) {
            var e = response;
            if (response.status === Windows.ApplicationModel.AppService.AppServiceResponseStatus.success) {
                document.getElementById('result').innerHTML = 'calculated ' + response.message.Result;
                return response.message;

And voilà ! you’re ready to go. A picture is worth a thousand words, so I put a sample with service and caller apps on github for you.

Debugging your service

If you grab the sample, you can see how easy it is to debug your service. If you configure the solution to run both caller and callee on debug, you can set breakpoints in your app service. If you don’t want to run the full service app, you could also edit the properties of the project hosting the service. In the debugging section, you could set « Launch Application » to false. In that case, when you run debug for both apps, you will only see the caller application starting, but your breakpoints in the app service will get called appropriately.

Porting Windows API calls from C# to JavaScript

Windows 10 is still in preview, and as of this writing, a lot of the samples available are written in C#.
The fact that samples are not available in JavaScript does not means that the feature is not available in JavaScript. The only things that may not be available is all topics about XAML controls, like the new InkCanvas, the RelativePanel, and so on. All code related to Windows APIs may be used in JavaScript.

Porting C# code to JavaScript is actually straightforward, especially if you are familiar with WinRT development. Windows APIs (aka WinRT) are projected in all available languages (C++, C#, and JavaScript), using each language paradigms. So, moving C# code to JavaScript is just about changing variable names to lowercase (ex « connection.SendMessageAsync() » => « connection.sendMessageAsync() »), or use the « on… » syntax for event. For example « connection.RequestReceived += someEventHandlerCallback » will convert to « connection.onrequestreceived += someEventHandlerCallback ».

As you can see, this is really easy…

Your first Windows web application

Since Windows 8, you could make native Windows applications using HTML and JavaScript. With Windows 8.1, this kind of application also include Windows Phone.

With Windows 10, this kind of application is now officialy called « Windows web applications » or « Windows web apps » and is part of the Universal app platform. It means you will be able to make Windows web apps for all Windows devices : phone, PC, tablet, Xbox, Hololens, etc.

But it’s not just about the name. Windows 8 was really strict about security in those apps, and has restrictions on referencing scripts outside of the applications sandbox, or using things like innerHTML to prevent script injection.Those restrictions prevent using some libraries, tools and workflow from a web developper perspective.

With the Windows web apps in Windows 10, the goal is to put you a lot more in control, and even allow some brand new kind of scenarios. Windows web apps use a security model based on the W3C standard « Content Security Policy », or CSP, to define the security for your application. It means you are in control of where your scripts or iframe code can resides. It also means that using most libraries, like AngularJS, should come without friction.

Another great improvement is that Windows web apps use the rendering and JavaScript engines of Microsoft Edge, and not Internet Explorer. It means that you could use all new HTML, CSS, and Javascript goodness coming from Edge like ECMAScript 6 features, @support, interaction media queries, … When new feature will come to Edge, you will also be able to use them in your applications (as the time of this writing ASM.js, css filter and more are in but with an experimental flag).

But that’s not all. The sandbox have been expanded to allow an application to run pages, iframes or webviews from outside your application. You could now make applications running partially, or entirely from web content.

Windows web hosted applications

This new capability is called hosted applications, because your app can be entirely or partially hosted in the web. Lets see together how you could make such applications. To run this, you will need Visual Studio 2015 and Windows 10.

First create a new Windows web application by clicking file / new / project. In the templates, expand JavaScript / Windows / Windows Universal and pick the « Blank App (Windows Universal) » template.

new project

To use hosted content, we must allow the http domains we want to access within our app. We must declare those domains in the manifest of our application.

In Visual Studio, open your « package.appxmanifest » file. Within your manifest, you should have something like this.

    <Application Id="App" StartPage="default.html">
            <uap:SplashScreen Image="images\splashscreen.png" />

Inside the application, just after the « uap:VisualElements » node, add a node called « uap:ApplicationContentUriRules ». If you start typing, you will see that Visual Studio provide intellisense. In that node, add a « uap:Rule ». To that rule, the « Match » attribute indicate the http domain, and the « Type » attribute indicate if you want to include or exclude the http domain.

You should have something like this

<Application Id="App" StartPage="default.html">
        <uap:Rule Match="" Type="include" />

Lets make a full hosted app. For that, we will change our starting page to point to our http domain. Change the « StartPage » attribute on the Application node to reflect that change.

<Application Id="App" StartPage="">
        <uap:Rule Match="" Type="include" />

Now just run your application by hitting F5. A brand new application will run with your web content.

As configured here our web site can not use Windows Runtime API (WinRT). To enable this kind of scenarios, you must explicitely enable this http domain to access WinRT. Update the « uap:Rule » you set with the WindowsRuntimeAccess attribute to « all ».

<Application Id="App" StartPage="">
        <uap:Rule Match="" Type="include" WindowsRuntimeAccess="all"/>

Congratulations, your website can now access WinRT features like Cortana, native share, and all other APIs available in WinRT (just look at MSDN documentation to see them all). Your application can also be deployed in the Windows Store, and add visibility to your site and services.

Obviously, just wrapping a website like we did is not the most valuable story. You will probably want to add a few files to bootstrap your application and show a decent (and branded) error page in case the user access your application without network. You may also mix packaged and hosted content by opening an iframe on that same uri, or whatever scenario respond to your needs.

This new hosted applications and new security model is really interesting because it unlocks many scenarios, for both public store applications, and line of business applications. We will try to expand on such scenarios in future posts.