Build desktop Windows apps with Project Reunion 0.5

Project Reunion is a set of new developer components and tools that represent the next evolution in the Windows app development platform. Project Reunion provides a unified set of APIs and tools that can be used in a consistent way by any desktop app on a broad set of target Windows 10 OS versions.

Project Reunion does not replace the existing desktop Windows app platforms and frameworks such as .NET (including Windows Forms and WPF) and C++/Win32. Instead, it complements these existing platforms with a common set of APIs and tools that developers can rely on across these platforms. For more details, see Benefits of Project Reunion.

Project Reunion 0.5 is supported for use in MSIX-packaged desktop apps (C#/.NET 5 or C++/Win32) in production environments. Packaged desktop apps that use Project Reunion 0.5 can be published to the Microsoft Store. For UWP apps, Project Reunion 0.5 is available only as a preview. This release is not supported for UWP apps that are used in production environments.

Project Reunion is a code name that may change in a future release.

Overview

Project Reunion provides an extension for Visual Studio 2019 that includes project templates configured to use Project Reunion components in new projects. The Project Reunion libraries are also available via a NuGet package that you can install in existing projects. For more information, see Get started with Project Reunion.

After you build an app that uses Project Reunion, you can deploy it to other computers. For more information, see Deploy apps that use Project Reunion.

Project Reunion 0.5 includes the following sets of APIs and components you can use in your apps. You can learn more about the future plans to bring other components into Project Reunion here.

Component	Description
Windows UI Library 3	Windows UI Library (WinUI) 3 is the next generation of the Windows user experience (UX) platform for Windows apps. This release includes Visual Studio project templates to help get started building apps with a WinUI-based user interface, and a NuGet package that contains the WinUI libraries.
Manage resources with MRT Core	MRT Core provides APIs to load and manage resources used by your app. MRT Core is a streamlined version of the modern Windows Resource Management System.
Render text with DWriteCore	DWriteCore provides access to all current DirectWrite features for text rendering, including a device-independent text layout system, hardware-accelerated text, multi-format text, and wide language support.

Benefits of Project Reunion for Windows developers

Project Reunion provides a broad set of Windows APIs with implementations that are decoupled from the OS and released to developers via NuGet packages. Project Reunion is not meant to replace the Windows SDK. The Windows SDK will continue to work as is, and there are many core components of Windows that will continue to evolve via APIs that are delivered via OS and Windows SDK releases. Developers are encouraged to adopt Project Reunion at their own pace.

Unified API surface across desktop app platforms

Developers who want to create desktop Windows apps must choose between several app platforms and frameworks. Although each platform provides many features and APIs that can be used by apps that are built using other platforms, some features and APIs can only be used by specific platforms. Project Reunion will unify access to Windows APIs for all desktop Windows 10 apps. No matter which app model you choose, you will have access to the same set of Windows APIs that are available in Project Reunion.

Over time, we plan to make further investments in Project Reunion that remove more distinctions between the different app models. Project Reunion will include both WinRT APIs and native C APIs.

Consistent support across Windows 10 versions

As the Windows APIs continue to evolve with new OS versions, developers must use techniques such as version adaptive code to account for all the differences in versions to reach their application audience. This can add complexity to the code and the development experience.

Project Reunion APIs will work on Windows 10, version 1809, and all later versions of Windows 10. This means that as long as your customers are on Windows 10, version 1809, or any later version, you can use new Project Reunion APIs and features as soon as they are released, and without having to write version adaptive code.

Faster release cadence

New Windows APIs and features have typically been tied to OS releases that happen on a once or twice a year release cadence. Project Reunion will ship updates on a faster cadence, enabling you to get earlier and more rapid access to innovations in the Windows development platform as soon as they are created.

Limitations and known issues

The following limitations and known issues apply generally to Project Reunion 0.5.

• Desktop apps (C#/.NET 5 or C++/Win32): Project Reunion 0.5 cannot be used in unpackaged desktop apps (C#/.NET 5 or C++/Win32). This release is supported for use only in MSIX-packaged desktop apps.
• UWP apps: Project Reunion 0.5 is not supported for UWP apps that are used in production environments. To use Project Reunion in UWP apps, you must use a preview version of the Project Reunion 0.5 extension that is not supported for production environments. For more information about installing the preview extension, see Set up your development environment.
• The WinUI 3 developer tool limitations also apply to any project that uses Project Reunion 0.5.

The following limitations and known issues apply to specific developer scenarios.

Using the Project Reunion NuGet package in existing projects

If you want to use the Project Reunion 0.5 NuGet package in existing projects, be aware of the following limitations:

• The Project Reunion 0.5 NuGet package is supported for use with desktop (C#/.NET 5 and C++/WinRT) projects in production environments. It is available as a developer preview for UWP projects, and is not supported for use with UWP projects in production environments.
• The Project Reunion 0.5 NuGet package (named Microsoft.ProjectReunion) contains other sub-packages (including Microsoft.ProjectReunion.Foundation and Microsoft.ProjectReunion.WinUI) that contain the implementations for components including WinUI, MRT Core, and DWriteCore. You cannot install these sub-packages individually to reference only certain components in your project. You must install the Microsoft.ProjectReunion package, which includes all of the components.
• If you install the Project Reunion 0.5 NuGet package to an existing project, you can only use non-WinUI 3 components that are part of Project Reunion in your project. To use WinUI 3, you must create a new project using one of the WinUI 3 project templates as described in the previous section.

ASTA to STA threading model

If you’re migrating code from an existing UWP app to a new C#/.NET 5 or C++/Win32 WinUI 3 project that uses Project Reunion, be aware that the new project uses the single-threaded apartment (STA) threading model instead of the Application STA (ASTA) threading model used by UWP apps. If your code assumes the non re-entrant behavior of the ASTA threading model, your code may not behave as expected.

Developer roadmap

For the latest Project Reunion plans, see our roadmap.

Give feedback and contribute

We are building Project Reunion as an open source project. We have a lot more information on our Github page about how we’re building Project Reunion, and how you can be a part of the development process. Check out our contributor guide to ask questions, start discussions, or make feature proposals. We want to make sure that Project Reunion brings the biggest benefits to developers like you.

How to build V8 on Windows and not go mad

“Building V8 is not for the faint of heart “ — someone on the internet

AngularInDepth is moving away from Medium. More recent articles are hosted on the new platform inDepth.dev . Thanks for being part of indepth movement!

Sometimes I wonder where my insatiable hunger for JavaScript knowledge will lead me to. This time I decided to learn how V8 is used by a browser and Node and where the API we use daily comes from. So I set out to investigate the integration between V8 and two most popular hosting environment for myself.

My plan was to build a simple application that embeds V8. And since not many web developers know that event loop is not implemented by V8 but by a hosting environment I wanted to demonstrate this in my app. I also hoped to learn about V8 inner workings along the way.

But first I had to build V8 from sources and embed it into a simple HelloWorld application. The task turned out to be not for the faint-of-heart. I spent about a week googling and learning about many thing related to C++ and python . I had to ask four heavily downvoted questions on stackoverflow. I’m going to keep them as a reminder of the efforts it took me to build the thing.

Since both building and embedding are not trivial this article consists of two parts. The first one shows how to build V8 from the sources on Windows machine. The second part explains what is required to plug it into your application. Currently V8 can only be built on x64 machines so make sure you’re building on Windows x64 version.

👏 Please recommend this article so that others know there is a simpler way to build V8. I really hope this article will save some curious mind much pains.

Setting up environment

The instructions on how to build V8 are available here but unfortunately they assume you already have a working environment and omit many details. But these details is exactly what makes building V8 tricky.

V8 uses part of a toolchain for Chromium project, so some of the information found here also was helpful to me. Please note that you don’t need to fetch and build Chromium sources to build V8. Only part of the tool chain like depot_tools is required.

V8 uses GIT as a VCS so download and install it. If you’re not very proficient with Git checkout Become a GIT pro by learning GIT architecture in 15 minutes to boost your Git knowledge.

VS 2015

Building V8 on Windows requires building tools that come with Visual Studio. As of December 8, 2016 Chromium requires Visual Studio 2015 Update 3 with the 14393 Windows SDK. So go ahead and download the installer for Visual Studio Community 2015 with Update 3 here. This page requires membership, but it’s free, so no worries here. Now run the installer and make sure to select the following:

After the install finished, check that the installer has installed Debug Interface Access (DIA) SDK and vcvarsall.bat to the following directories:

• …\Microsoft Visual Studio 14.0\ DIA SDK
• …\Microsoft Visual Studio 14.0\VC\ vcvarsall.bat

For some reason these may be missing after the install. If that’s the case, you’ll have to figure why and somehow get them installed. Otherwise, you won’t be able to build. In my case it installed correctly on one machine were missing on the other.

Windows SDK

Since Chromium uses Debugging Tools For Windows which are not installed as part of VS installation, you’ll also need to install Windows SDK separately. Download the installer here and install. Make sure you’ve selected the package in the installer:

Depot tools

Download the depot_tools bundle and extract it somewhere.

Warning: DO NOT use drag-n-drop or copy-n-paste extract from Explorer, this will not extract the hidden “.git” folder which is necessary for depot_tools to autoupdate itself. You can use “Extract all…” from the context menu though.

Environment variables

Add depot_tools to the start of your PATH . Many build python scripts are written for Python version lower than 3.x so ensure it’s ahead of any installs of Python. Assuming you unzipped the bundle to E:\V8\depot_tools update path like that:

I also recommend to add it to the system variables PATH not user variables. The PATH is constructed from the system path, which can be viewed in the System Environment Variables field in the System dialog box. The User path is appended to the system path . It means if you add path to User variables, and you have other Python installation found from the system path, you’ll have a problem.

You’ll also need to specify two environment variables:

• DEPOT_TOOLS_WIN_TOOLCHAIN=0
• GYP_MSVS_VERSION =2015

Update Depot tools

From a cmd.exe shell, run the command gclient (without arguments). On first run, gclient will install all the Windows-specific bits needed to work with the code, including msysgit and python .

• If you run gclient from a non-cmd shell (e.g., cygwin, PowerShell), it may appear to run properly, but msysgit, python, and other tools may not get installed correctly.
• If you see strange errors with the file system on the first run of gclient, you may want to disable Windows Indexing.

After running gclient open a command prompt and type where python and confirm that the depot_tools python.bat comes ahead of any copies of python.exe .

Get source code

Go into the directory where you want to download the V8 source into and execute the following in your terminal/shell:

Building V8

Now that we have environment ready we can build V8. All commands should be executed using Windows Command Shell inside the V8 source directory. We will be executing python scripts as part of the build process and we need to ensure that the python executable from build_tools is used. The problem is that Windows can associate python files with other versions of python installed on your PC, so always execute command in the following syntax:

Start with the downloading of all build dependencies by executing the following:

Then generate the necessary build files by running the following:

To embed V8 into our application we need to build it as a static library. To do that, we need to modify default build configuration and add these two flags to args.gn file:

Run the following to open the file ..\out.gn\x64.release\args.gn in an editor:

Add the lines so the resulting file looks like this:

The last thing is to compile the source by executing the following:

Run tests to verify that everything is built correctly:

Build result

The build generates ..\v8source\out.gn\x64.release\obj folder with many static library files (*.lib) : v8_base.lib , v8_libbase.lib etc. We will use these files when embedding v8 into our application.

Embedding V8 into a custom application

As it turned out, the struggle didn’t end with a successful build. I also jumped over multiple hoops when trying to embed V8 and build sample Hello world application. The manual is pretty short and it’s for Linux based systems and again is lacking on many important details.

We will embed V8 into a simple console application. Create an application by following the instructions described here (don’t check Empty project ) or here. This creates Win32 application but the V8 is built for x64 architecture so we need to modify our project a bit. To do that, go to project properties and select x64 active solution platform:

Also, by default V8 is built in release mode. To avoid mismatch errors like this, we need to set the project to release configuration:

Also, we need to make the application to use the multithread, static version of the run-time library:

Configure include and library directories

Next, we need to add folders to look for V8 header files to Include Directories:

And add folders with V8 static library files to Library Directories:

This page nicely summarizes all types of directories.

Compose HelloWorld cpp file

Now, copy the HelloWorld example from here to your main cpp file and include stdafx as the top include in your file:

Link static libraries

We’re almost done. As mentioned earlier the V8 itself is comprised of static library files in the ..\v8source\out.gn\x64.release\obj directory. Now we need to link those libraries. To do that add the following to your code:

And also link Windows related libraries required by V8 libraries:

Build the application

And now finally we’re ready build. Go to Build->Build solution or press Ctrl+Shift+B . This will generate an executable file to the following location:

A few more bits

V8 requires two files located in …\v8-source\out.gn\x64.release for a startup:

Copy them to where the executable is. That’s it. You can now run your executable from the command line and it should output “Hello World”.