Le Post Infeeny

Les articles des consultants et experts Infeeny

Archives Mensuelles: février 2016

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 🙂


Déploiement d’un projet VSTO multi-users avec Wix Toolset

Problématique :

Imaginons un client X qui souhaite ajouter de nouvelles fonctionnalités à son instance de Microsoft Office (Outlook, Word, Excel ou même PowerPoint).

Pour ce faire nous lui proposerons de lui développer un composant VSTO qu’il installera sur son environnement.

Cependant monsieur X souhaites que sur une machine où est installé l’add-in, tous les autres utilisateurs qui peuvent se connecter dessus puissent y avoir accès sans avoir à réinstaller à chaque fois le composant. Lire la suite