sticky
GPIO Controlled By Multiple UWP Apps RRS feed

  • General discussion

  • Operating systems and runtime environments typically provide some form of isolation between applications. Windows uses processes to isolate applications. This isolation is necessary to ensure that code running in one application cannot adversely affect other, unrelated applications. Application domains provide an isolation boundary for security, reliability, and versioning, and for unloading assemblies. Application domains are typically created by runtime hosts, which are responsible for bootstrapping the common language runtime before an application is run.

    Because of Application domain, if an application gets the GPIO controller on Windows IoT Core, it will lock the handle in current application domain, so that when another application tries to get and use the controller, there will an exception thrown, the message as following.

    The process cannot access the file because it is being used by another process.

    Pin ' is currently opened in an incompatible sharing mode. Make sure this pin is not already in use by this application or another application.

    Even though in the same application domain, if you want to control the GPIO in another page, you should call Dispose method to release the handled resources for GPIO, or else the exception same with about will be also thrown out. When the application navigates from one page which controls GPIO to another, the GC will not collect the resources for GPIO controller instance, the Dispose method is used to release the resources manually.

    There is a general scenario we will encountered in our IoT solution. Multiple apps run in the device, each of them needs to control the GPIO pin. That will cause the conflict for getting the controller. In this scenario, we need to create an App Service as a bridge, which serves the GPIO control and business for the apps. App services let you create UI-less services that apps can call on the same device, and starting with Windows 10, version 1607, on remote devices. App service runs as a background task, it can be hosted in a foreground app or background app.

    As we know, background applications in Windows IoT Core are applications that have no direct UI. Once deployed and configured, these applications launch at machine startup and run continuously without any process lifetime management resource use limitations. If they crash or exit the system will automatically restart them. We can find the sample of app service which hosted on foreground app. But Microsoft did not give a sample which hosts an app service in background, it makes some user a little confused. Here I provide a sample with source code here(https://github.com/v-liujxu/AppErrorCrossDomainMonitor).


    MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Tuesday, December 18, 2018 2:03 AM
    Moderator