CI Build

Factory Orchestrator is a tool for built for Original Equipment Maufacturers to aid in the manufacturing of Windows devices. Factory Orchestrator consists of the following projects:

.NET Standard library containing the core FactoryOrchestrator classes. Required in all projects.

A .NET Standard library containing the server-side FactoryOrchestrator classes. Required on all FactoryOrchestrator server projects.

.NET Core Executable project for FactoryOrchestratorService.exe, the FactoryOrchestrator server implementation. Requires administrator access to run.

.NET Standard library containing the client-side FactoryOrchestrator classes, required to interact with FactoryOrchestratorService. Also contains optional helper classess.

C# UWP app project for FactoryOrchestratorApp.exe, the UWP used to manually interact with FactoryOrchestratorService via GUI.

FactoryOrchestrator forks the source of IpcServiceFramework. At this time, we are actively working on integrating our version of IpcServiceFramework with the official IpcServiceFramework repo, removing the need for this fork.

FactoryOrchestrator minimally forks a portion of the source of Pe-Utility, to build it as a .NET Standard library and reduce the code complexity for FactoryOrchestrator's use case.

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

Any variation of Visual Studio 2019+ (Enterprise, Community) is fine. In the installer, make sure you click the checkboxes for .NET Core cross-platform Development, and Universal Windows Platform Development (10.0.17763.0).

Other development environments such as Visual Studio Code are acceptible if you are not making FactoryOrchestratorApp changes.

https://docs.microsoft.com/en-us/windows/uwp/get-started/enable-your-device-for-development

FactoryOrchestrator contains a series of unsigned powershell scripts. Windows security measures prevent unsigned scripts from executing. In order to develop on FactoryOrchestrator, you need to do one of two things.

More information on how to do this can be found here: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_signing?view=powershell-7

This method is not recommended. Setting the Execution Policy to Unresricted allows any powershell script to run. Documentation on Execution Policy: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.security/set-executionpolicy?view=powershell-7

When building the source code, keep in mind that certain actions only occur when the build is run as part of an Azure DevOps Pipeline or when run in the "Release" configuration locally. For example, DocFX documentation for the Core and Client Libraries is only generated when the build is run in in one of those two modes. These actions are skipped in Debug builds to increase inner-dev-loop speed.

Run FactoryOrchestratorApp (Universal Windows) and FactoryOrchestratorService in separate Visual Studio 2019+ instances. This will allow the app and the service to communicate with each other. Even if you are coding for just the app, you generally need to run the service so the app has something to connect to. The service must be run as administrator.

At the moment, running either the app or service under a debugger will cause exceptions to be thrown related to certain registry keys (ex: GetOEMVersionString()), but all exceptions are caught and will not result in a crash. This is because they try to access registry keys specific to a Microsoft internal product. You can routinely skip over these exceptions when they occur or disable them.

Factory Orchestrator uses a slightly modified form of semver versioning. All Factory Orchestrator binaries from the same build share the same version; there is no unique client or service version. In the src/custom.props file, increment the:

• MAJOR version when you make incompatible API changes,
• MINOR version when you add functionality in a backwards compatible manner.

The PATCH version is automatically set by the build, and is based on the date/time the build is run. The PATCH version is only changed when the build is run as part of an Azure Pipeline or when run in the "Release" configuration locally.

When the MAJOR version diverges between a Client and Service, Clients will be prevented from connecting to the Service by default. Changing the signiture of any FactoryOrchestratorCoreLibrary class is therefore usually a MAJOR version change and should be done sparingly.

Happy Coding!

Please refer to SECURITY.md.

Copyright (c) Microsoft Corporation. All rights reserved.

Licensed under the MIT License.

IpcServiceFramework - Jacques Kang - MIT License

DotNetCore.WindowsService - Peter Kottas - MIT License

Pe-Utility - Andres Traks - MIT License

WindowsDevicePortalWrapper (mgurlitz .NET Standard fork) - Microsoft Corporation and mgurlitz - MIT License