First published on MSDN on Mar 14, 2017
Visual Studio Code
, which is specific for Windows and allows to interact with the system registry, the file system, etc.)
However, the goal of this post isn’t to explain you how to create a great Electron app, not only because I’m not the most qualified person to do it (since I can’t say I’m really an expert in web technologies), but especially because it would be out of topic for this blog, since the AppConsult team is focused on helping developers to bring their existing desktop apps on the Store using the Desktop Bridge. And this will be exactly the purpose of this post: explain how you can take an existing Electron app compiled for Windows and convert it into an app package through the Desktop Bridge, so that you can deploy it in your company using a better deployment model or publish it on the Store after
having nominated it using the official form
However, even if I’ve said that the purpose of this post isn’t to explain how to create an Electron app, we need one before we can see how we can convert it using the Desktop Bridge. To get started, you will need Node.js installed on your machine: you can manually download the installer
from the official website
(for our purposes, it’s the same if you choose to install the LTS or the Current branch) or you may have Node.js already installed, since the development tools are included as an optional feature in the latest Visual Studio versions.
No matter which approach you have used, you should end up with a command prompt specific for Node.js development, which is called
Node.js command prompt
: it’s a standard Windows command prompt, but with all the correct environment variables already set to get access to the Node.js features and to NPM (Node Package Manager), the tool used to install third party packages for Node.js based projects (you can think of it like a NuGet alternative, but specific for Node.js).
Thanks to this environment, we can easily set up the
quick start project
provided directly by Electron, which is a very basic app that leverages some simple Electron APIs to display some information about the current environment, like the current Node.js, Chromium and Electron version.
Let’s start to see the basic steps to download and run this quick start, before learning how to convert it into an app package.
Download and launch the quick start
As first step, launch the Node.js command prompt I’ve mentioned before, that you can find by start typing
in the Windows 10 search box:
The next tool we need is GIT, but we don’t have to worry if we have installed on our machine Visual Studio 2015 or 2017: since this source control system is natively supported, we should already have all the tools we need. In case you don't have them, you can download the Windows version from the following link:
Now we are ready to download the sample, by simply typing in the command prompt we have previously opened the following command, after we have placed ourselves in the folder where we want to store the sample:
If you did everything well, you should have a folder with the following content on your machine:
Here is a short description of the key files:
is the main page of the application
is a JSON file that describes the projects and all the other modules that are needed for this Node.js application to run properly. If you open it with a text editor you’ll notice, in fact, that in the section called
you’ll find a module called
. It’s purpose is similar to the
file (in standard .NET projects) or the
file (in UWP apps) used by NuGet: when you’ll run the app for the first time (remember that we’re talking about a web app, so there’s no compilation involved like in a C# project), Node.js will automatically download the missing modules from NPM.
In this quick start, the
file is empty and it’s there just if you want to use this sample as a starting point to expand it: as already mentioned, the only thing that this sample does is to show some basic information about the current configuration of the app to the user, other than offering the Chromium Dev Tools to simplify the debug experience, so everything is included in the
Since, as we said, there’s no compilation involved, before running this sample we need to make sure we have all the required modules, so we need to move into the folder we have just cloned with the command:
and then launch the following command provided by NPM:
This operation will scan the
file and will download any missing module. Since we have just downloaded the app, the
module will be unavailable, so NPM will proceed to download and copy it inside the quick start project folder, in the
subfolder. After it has completed the task, now you are ready to launch the application by using the last command:
If you did everything well, you’ll see your web application running as a native desktop app:
From the creation of an Electron app point of view, we’ll stop here: again, the purpose of this post isn’t to explain how to create great desktop apps using this technology.
Creating a Windows executable
in a Node.js command prompt. To turn it into a real app, we need to leverage one of the available projects that can convert the web files into self running executables for Windows, Mac or Linux. The project we’re going to use is called
and, being a Node.js module itself, we need to install it again from the Node.js command line using npm:
npm install electron-packager -g
Now we can use this command line tool to generate the executable of our application. The tool can generate applications for every platform but, in this post, we’ll focus just on the Windows version, since it’s the one that we’ll need later to convert into an AppX through the Desktop Bridge. In the same command prompt we have opened before, we need to launch the following command:
electron-packager <sourcedir> <appname> --platform=<platform> --arch=<arch>
The required parameters are:
, which is the path of the original Electron app we’ve cloned from GitHub before.
, it’s the name of our application, which will be used to generated the executable.
is the operating system for which we want to generate the app.
is the architecture for which we want to create the executable (x86, x64, etc.).
Let’s keep the sample as basic as possible and let’s generate a 32 bit Windows application, by launching the following command:
electron-packager "C:\Electron\electron-quick-start" "ElectronSample" --platform=win32 --arch=ia32
In the previous sample, we’re assuming that we have stored the quick start we have previously cloned from GitHub in the path
After the operation is completed, we will find in the current folder a subfolder with, as name, a combination of appname, platform and architecture (in my case, it’s
The folder will contain many files and DLLs which are required by the app to work properly, including a Windows executable with the same name of the appname parameter we have passed to the electron-packager tool: ElectronSample.exe.
If you’ll double click on the
file, you will see exactly the same app that you have previously launched with the command
Now we have a real Windows desktop application, that we can turn into a Windows Store package thanks to the Desktop Bridge.
Also this tool (as basically everything related to the Node.js world) is command line based and you will have to install it using NPM and the Node.js command prompt we have already used before, by launching the following command:
npm install -g electron-windows-store
The tool, to properly work, leverages a set of PowerShell script so, if you want to use it, you need to configure your machine to run scripts downloaded from Internet. To do it, you need to open a PowerShell command prompt with administrative right (type
in the Start menu, right click on
Run as administrator
) and launch the following command:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
Now you can start using the converter tool, which can work in two different ways: using a file copying approach or leveraging the Desktop App Converter by Microsoft. Both approaches will produce the same output: the difference is that, in the first case, the tool will simply take care of copying all the required files of the Electron based desktop app and to add all the specific AppX files (like the assets or the manifest file); in the second case, it will process the executable inside a Windows Container, in the same way the Desktop App Converter does with a traditional installer. We’ll see how to use both approaches, but first let’s start from the command to execute, which is the same regardless of your choice. This is the command you will need to launch in the same PowerShell prompt you have opened before:
electron-windows-store --input-directory "C:\Electron\ElectronSample-win32-ia32" --output-directory "C:\Electron\ElectronSampleStore" --flatten true --package-version 188.8.131.52 --package-name ElectronSample
The command is pretty straight forward and shows the minimum set of parameters which are required:
is the path of the version of the Electron app we have compiled before for Windows.
is the path where we want to save the generated app package (both in terms of folder and AppX).
is a suggested parameter, since it will rearrange all the node modules used by the application in a flat and simpler structure.
is the version number of the application, as requested by the Store.
is the name of the package that will be generated.
If you want more control over the package that will be generated (like the option to already set some values of the manifest, like the identity name or the publisher) you can either choose to manually change them later and then recreate the AppX or to specify them immediately: the
tool support many more parameters, which you will find listed
in the official GitHub page
After you have launched this command for the first time, you will be prompted with the following question:
Based on your response, the tool will use the file copying method (if you answer
) or the Desktop App Converter (if you answer
). Let’s see which are the information that are asked with the two approaches.
The file copying approach
If you have chosen
as a response, the next question will be if you already have a development certificate to use for signing the package so that you will be able to side load it. If you choose
, you will get at the end of the process an unsinged AppX, that you will have to manually sign using an existing .pfx certificate and the
tool (as we have explained
in the post about the manual conversion
). If, instead, you choose
, the tool will generate for you the required certificate in the path
, in a subfolder with the same publisher name that you will be asked to specify in the next step. For example, in my case I’ve set as publisher
and, consequently, the tool has created the folder
with the following content:
If you have read
the previous post about the manual conversion
, these file shouldn’t be nothing new: they’re the custom and self generated certificates that are created by the
tools. When you answer
to this question, other than generating the development certificate, the tool will automatically take care of signing the generated AppX with it. From your side, you will have just to remember to install the
file inside the
Trusted Root Certification Authorities
store in order to side load the application.
As already mentioned, in the next step you will be asked for the publisher name that will be stored in the manifest file, which must have the form of
. In the end, the last question is the path of the Windows 10 SDK, where all the tools used to generate the package and sign it (like
) are stored. Usually, in this step it’s enough to press Enter on your keyboard, since the tool already suggests the default path where the SDK is installed, which is
C:\Program Files (x86)\Windows Kits\10\bin\x64
so, unless you have changed the default installation folder, there’s nothing to do here.
Now the real conversion process will start and, as first thing, you’ll be asked to create a password for the development certificate:
It’s important to choose
, otherwise the tool won’t be able to sign the generated AppX at the end of the process. Now the real conversion process will start and, if there isn’t any surprise, it will terminate with success.
The Desktop App Converter approach
To use the Desktop App Converter approach, you’ll need as first thing to have the tool installed on your computer, including all the prerequisites (like the base images which matches your Windows version). You can refer
to this blog post
if you want to know how to properly setup the Desktop App Converter on your machine.
The first question you will be asked is if you want to generate a development certificate, exactly like we did with the file copying approach: as such, I won’t explain again how it works.
The next question is the path where you have installed the Desktop App Converter: if you have installed it from the Store, you can get the full path by looking for the package identified by the name
in the list of all the apps installed on your system. You can get this list by launching the
command in another PowerShell window. You will need to find an entry like the one highlighted in the follow image:
This is a required step because the folder where the app is installed from the Store isn’t fixed, but it can change based for example on the version number of the tool. In the previous screenshot, the path refers to the version 184.108.40.206 of the Desktop App Converter installed on a 64 bit system.
The last question is the location where you have installed the base image of your system: the default folder is
is the build number of your Windows installation. For example, if you’re using the latest official Windows 10 version (Anniversary Update, identified by the build number 14393), the base image will be stored in the folder
That’s all: now the conversion process will continue, pretty much like it does with the file copying approach, only that this time it will leverage a Windows Container created by the Desktop App Converter.
The output of the process
No matter which approach you have decided to use, in the output folder you have specified as parameter of the
command line tool you will find:
An AppX package with the converted version of the Electron app, which could be already signed (and, as such, ready to be installed) or not, based on your choice of creating a development certificate during the usage of the tool.
A folder called
, which contains the folder that has been turned into an AppX and it’s the one that contains all the standard files required for a converted desktop app:
A manifest file (AppxManifest.xml).
A folder called
, with the executable and all the dependencies of the Electron based app.
A folder called
, with a set of predefined images that are used as icons and tiles for the converted application.
From now on, the approach is exactly the same we have seen
in the blog post about using the Desktop App Converter
: if you have already prepared everything upfront, you can install your AppX, share it or upload it on the Store (if you have received the proper permission after
having nominated your app using the official form
). Otherwise, if you need to make some changes (like updating the assets, adding an extension in the manifest file, etc.), you can apply them to the content of the
folder and then, using the
tool, generate a new package and, eventually, sign it again if you need to side load it on a Windows 10 computer.
What if I want to change a configuration parameter or start from scratch?
If you’ll try to execute again the same command as before with the
tool, you’ll notice that this time you won’t be asked any question: it will automatically use the parameters you have specified the last time. The reason is that, after the first successful conversion, the tool will store the parameters in a configuration file called
inside the folder
If you want to change any parameter, just open the file with any text editor and update it. Or if you want to start from scratch, just delete the file and the next time you will run the tool, it will ask you again the configuration questions we’ve seen before.
In this blog post we’ve seen how the Desktop Bridge can be used also in combination with applications created with Electron, which is a development platform for desktop apps that is getting more and more traction day by day, thanks to the high popularity of the web technologies nowadays. This is another example of how the Desktop Bridge can be a great tool to modernize the deployment process of a desktop application and to start leveraging Windows 10 features, no matter which is the technology behind our desktop application.