{"id":139,"date":"2021-08-05T12:00:00","date_gmt":"2021-08-05T19:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/react-native\/?p=139"},"modified":"2022-11-17T03:32:35","modified_gmt":"2022-11-17T11:32:35","slug":"win32component","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/react-native\/win32component\/","title":{"rendered":"Use Win32 features from a React Native for Windows application"},"content":{"rendered":"

If you have adopted React Native to build your Windows applications, you’ll know that the final output is a Universal Windows Platform application<\/a>. This development platform gives you access to all the latest enhancements in the Windows ecosystem (modern UI platform, notifications, integration with features like inking and Windows Hello, etc.), plus greater security and reliability thanks to the sandbox the application runs in.\nHowever, there might be scenarios where UWP isn’t enough and you need to perform one or more tasks which are supported only by the Win32 ecosystem: working with any file on the disk without user intervention, reading a key from the registry, integrating a SDK which doesn’t support the Windows Runtime.<\/p>\n

In this post we’re going to explore a solution that will enable you to get the best of both worlds: a React Native for Windows application which integrates a classic Win32 process. We’re going to build a sample React Native application which will be able to read a registry key and display it. The goal is to display to the user values stored in the \\HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion<\/code> hive, which contains many information about the currently installed version of Windows.<\/p>\n

The solution will use the following components.<\/p>\n

A classic Windows process<\/h4>\n

We’re going to build a .NET 5.0 console application which, by targeting Windows 10 and using the Windows Compatibility Pack<\/a>, will be able to interact with the system registry. The React Native application will send to this process the name of the key we want to retrieve; the process will read its value and send it back to the React Native application.<\/p>\n

A React Native for Windows application<\/h4>\n

This will be a traditional React Native for Windows application. However, as we’re going to see later, we’ll have to make a couple of changes to the host app generated by the template to handle the communication with the classic Windows process.<\/p>\n

App Services<\/h4>\n

App Services<\/a> is a UWP feature that enables a Windows application to host one or more background tasks that can be consumed by other applications. You can think of this feature like REST services, but exposed locally. Once a UWP application which exposes an App Service is deployed on a machine, other applications can connect to it using its name and the Package Family Name of the hosting application. Once the communication channel is established, the calling application can send data to the App Service, which will process it and send back the results.<\/p>\n

In our context, App Service will enable us to create a communication channel between the React Native application and the classic Win32 process. The main difference compared to the traditional usage is that the App Service will be hosted and consumed by the same package, since the two processes (UWP and classic Win32) will be packaged together.<\/p>\n

App Services support two approaches: in-proc<\/a> (when the implementation of the service is defined in the main application itself) and out-of-proc<\/a> (when the implementation of the service is defined in an external Windows Runtime Component, which gets executed in a different process). For our scenario, we must use the in-proc approach, since we need to hold a direct connection with the main application.<\/p>\n

A native module<\/h4>\n

A native module<\/a> is the way to expose native features to the JavaScript layer of React Native application. In the Windows context, a native module is a Windows Runtime Component that, through attributes which decorates your code, can expose methods, properties and events to JavaScript.\nThe native module is needed as a glue between the React Native world and the UWP world. All the APIs to interact with an App Service are exposed by the Windows Runtime and, as such, we need a middle man that can make them accessible to JavaScript.<\/p>\n

Windows Application Packaging Project<\/h4>\n

A Windows Application Packaging Project<\/a> (WAP project, from now on) is a template available in Visual Studio, which is typically used to package as MSIX classic Windows application. In our context, we’re going to use it to bundle together the classic Win32 process and the React Native for Windows application in the same MSIX package.<\/p>\n

The diagram below shows how all these components are tight together:<\/p>\n

\"The<\/p>\n

    \n
  1. The user launches the React Native application which, at the same time, starts also the classic Win32 process.<\/li>\n
  2. The Win32 process, at startup, establishes a communication with the React Native application using an App Service and it stores a reference to the channel.<\/li>\n
  3. The user presses a button in the React Native application.<\/li>\n
  4. The button will invoke a method method exposed by the native module. The method will push a message to the communication channel, so that it can be received by the classic Win32 process. The message will contain the information about the key that the Windows process must retrieve from the registry.<\/li>\n
  5. The classic Win32 process retrieves the desired key from the registry, it stores it inside another message and it sends it back to the communication channel.<\/li>\n
  6. The native module, which is using the App Service to keep the communication channel open, receives the message with the retrieved key and it sends it back to the JavaScript layer.<\/li>\n
  7. The React Native application can now show to the user the value of the registry key.<\/li>\n<\/ol>\n

    Let’s start building all the components!<\/p>\n

    \n

    All the samples you’ll find below (including the native module and the React Native host app) will be based on C#, since it’s the language I’m most familiar with. However, the same goal can be achieved also using the C++ templates.<\/p>\n<\/blockquote>\n

    The classic Win32 process<\/h3>\n

    For the purpose of this sample, we’re going to use a .NET 5.0 console application. Open with Visual Studio the solution included in the windows<\/code> folder of your React Native application, right click on it and choose Add -> New project<\/strong>. Choose Console application<\/strong> as template.<\/p>\n

    Before starting to write some code, we need to make a few changes:<\/p>\n

      \n
    1. Double click on the project and change the TargetFramework<\/code> from net5.0<\/code> to net5.0-windows10.0.19041.0<\/code>. The new target will enable you to leverage Windows 10 APIs from your .NET application. It’s required in our scenario since we need to use the App Service APIs.<\/li>\n
    2. Right click on the project, choose Manage NuGet Packages<\/strong> and install the Microsoft.Windows.Compatibility<\/a> package. It will give us access to the APIs to interact with the Windows registry.<\/li>\n
    3. Right click on the project, choose Properties<\/strong> and change the Output type<\/strong> from Console Application<\/strong> to Windows Application<\/strong>. Thanks to this change, our application will run headless, without any visible UI. This helps to achieve a good user experience, since our classic Win32 process will run only in background. All the UI and interaction will be handled by the React Naive application.<\/li>\n<\/ol>\n

      The application will run continuously in background, until the main React Native application will be closed. To achieve this goal, we start the main process in a separate thread, which gets terminated when the connection with the App Service is closed (which means that the application is closed). This approach ensures that the classic Win32 application doesn’t become a “zombie” process, which stays alive even if the main app has been shut down.<\/p>\n

      static AutoResetEvent appServiceExit;\r\nstatic AppServiceConnection connection = null;\r\n\r\nstatic void Main(string[] args)\r\n{\r\n    appServiceExit = new AutoResetEvent(false);\r\n    Thread appServiceThread = new Thread(new ThreadStart(ThreadProc));\r\n    appServiceThread.Start();\r\n    appServiceExit.WaitOne();\r\n}<\/code><\/pre>\n
      The code above starts the execution of a method (called ThreadProc<\/code>) in a separate thread. We use an AutoResetEvent<\/code> to block the execution of the Main()<\/code> method. This way, we make sure that the process will keep running until the communication channel created with the App Service is alive.<\/p>\n
      The ThreadProc<\/code> method is the real “core” of the process, which takes care of initializing the connection with the App Service:<\/p>\n
      static async void ThreadProc()\r\n{\r\n    connection = new AppServiceConnection();\r\n    connection.AppServiceName = \"RegistryService\";\r\n    connection.PackageFamilyName = Windows.ApplicationModel.Package.Current.Id.FamilyName;\r\n    connection.RequestReceived += Connection_RequestReceived;\r\n    connection.ServiceClosed += Connection_ServiceClosed;\r\n\r\n    \/\/we open the connection\r\n    AppServiceConnectionStatus status = await connection.OpenAsync();\r\n\r\n    if (status != AppServiceConnectionStatus.Success)\r\n    {\r\n        \/\/if the connection fails, we terminate the Win32 process\r\n        appServiceExit.Set();\r\n    }\r\n}<\/code><\/pre>\n
      We create a new AppServiceConnection<\/code> and we configure it in the following way:<\/p>\n