FOService::GetOEMVersionString()

RunningBackgroundTasks & RunningTaskRunTokens use different mechanisms to track running tasks, and does not always properly dispose of the CancellationTokenSource() token used. We should consider rewriting this logic to simplify it and reduce the risk of bugs.

It expects no auth, which is uncommon

https://microsoft.github.io/FactoryOrchestrator/ClientLibrary/Microsoft-FactoryOrchestrator-Client-FactoryOrchestratorClient-CreateTaskListFromTaskList%28Microsoft-FactoryOrchestrator-Core-TaskList%29/

has a link to https://microsoft.github.io/CoreLibrary/Microsoft-FactoryOrchestrator-Core-TaskList which doesnt exist. Should link to https://microsoft.github.io/**FactoryOrchestrator**/CoreLibrary/Microsoft-FactoryOrchestrator-Core-TaskList/

This is the standard location for configuration files

InvalidOperationException will occur if the IPC code has changed significantly between versions and an older client is calling a newer service or vice versa. The FactoryOrchestratorClient should detect this exception and throw an FactoryOrchestratorVersionMismatchException to alert the callee that the versions are diverged.

It's not ideal there are two HostBuilder operations in the service. We should create both FOService & the IPC in the same host, and also allow appsettings.json & command line options to modify the both the Host's service configuration (primarily logging levels) & FOService configuration.

Describe the bug
With the WinUI 3 build (10.3.1) updates to the network info shown on MainPage causes the buttons in upper right to move on the UI.

To Reproduce
Steps to reproduce the behavior:

1. Launch UWP 10.3.1
2. Connect to a device with 2+ network connections
3. UI in upper right

Repro video
https://user-images.githubusercontent.com/31931010/128423403-af3c8ff7-559b-4d06-a31b-99dd58ea07b5.mp4

Expected behavior
Buttons should never move position.

Environment (please complete the following information):

• OS: [e.g. Windows 10, Windows Server 2019, Ubuntu 20.04] all
• Service and/or client version(s) [e.g. 10.0.0] uwp client 10.3.1
• Any applicable service configuration: N/A

Expect: About page shows versions
Actual: About page shows 0.0.0.0 for both versions

Describe the bug
Transfer Files Tab is disabled on localhost app even when a container is connected

To Reproduce
Steps to reproduce the behavior:

1. Boot image with Factory Orchestrator app configured to auto start
2. If the container starts after the app the Transfer Files tab never appears

Expected behavior
Transfer files tab appears once container is found.

Workaround
If the app is exited and restarted after the container has started, the tab appears.

Environment (please complete the following information):

• OS: FOS w/ container
• Service and/or client version(s) 10.3.0

https://docs.microsoft.com/en-us/windows/win32/api/winsvc/nf-winsvc-getserviceregistrystatekey is the recommended way to read and write to the registry for a Windows service, as it properly isolates the registry state and is Windows OS agnostic.

This issue tracks using that API to open registry keys instead of opening up registry keys manually.

github.io documentation should auto update :)

What:

• Use templates where possible
• Split builds into one Job per Configuration/Architecture
• Run Policheck and Component Governance on all builds including GitHub (if possible)
• Add/Improve build pipeline documentation

Why: The current pipelines share no YML code, even though they mostly perform identical tasks. It also needs better documentation for easier debugging & maintenance.

There is no consistent naming format for variables. Ideally they follow a consistent pattern which is documented in the contribution guidlines.

The "Run In Container" checkboxes in the FO app are creating confusion as users see them greyed out when the image has no container support. We should hide the boxes entirely if container support is disabled in the Service by policy.

UpdateContainerIpAddress() and UpdateContainerId() currently rely on FactoryOS specific registry, a non-ideal non-portable implementation. Ideally, they use public APIs to get container information.

Both app and Client APIs should allow the client to send input to any running TaskRun that expects input from the user.

FxCop refactor caused an issue to show up in PEUtility.Executable, that part of the refactor needs to be reverted.

if this is generic sysinfo, what else would be useful?

• battery info?
• total Memory?
• free disk space / used space?
• Serial Number
• Computer Hardware ID
• System manifest info

Originally posted by @spaceisfun in #182 (comment)

WHAT: Add a new Task type for a shutdown/reboot task.

WHY: An automated TaskList might want to reboot the DUT in the middle of the task flow. Currently, you would need to finish a TaskList, reboot via the API, then resume the TaskList.

HOW: Add a new Task type, which is used for Shutdown or Reboot. When executed as part of a TaskList, the reboot operation is performed and then the DUT resumes executing the same TaskList once the DUT has completed the reboot.

A recent commit c4819fe, changed the TaskRun::TaskOutput parameter type from List to LockingList. Ideally the core classes such as TaskRun return abstract classes like IList, so that this wouldn't have been a breaking change.

Let's encrypt our messages so they aren't transmitted in plain-text 👍 .

Currently, LoadOEMCustomizations() and the FOService ctor both handle setting key properties, fields. This should be done in one location for consistency.

Merge latest code into FO repo: https://github.com/jacqueskang/IpcServiceFramework
Fix issues and port enhancements as needed

Gets us closer to consuming IPC nuget directly

Task never starts executing due to premature disposal of Cancellation Token

This is most noticable when running programs via the app command prompt, since they are invoked via cmd.exe /C .

NET Core 3.1 has a Kill(true) method to terminate child processes, but it isn't available in NET Standard, yet. It should be with NET 5.0. Or, copy the implementation of Kill() true and reimplement it in our code

By using Uno or similar we should be able to make the Factory Orchestrator app cross platform, capable of running on Linux.

The Factory Orchestrator UWP app's command prompt would be much improved with a basic command history, so that it is easy to re-run commands.

https://github.com/microsoft/FactoryOrchestrator/blob/main/src/App/ConsolePage.xaml.cs

These files:

1. Are checked into source
2. BUT use a version that is dynamically updated based on common.props

They should use an obj file instead like Microsoft.FactoryOrchestrator.Client.psd1

UI still shows tasklists. Not sure if it is an app issue, service issue, or both.

Let's ship a truly cross-platform task orchestration service!

This tracks shipping the service as a standalone program, not as a daemon. Future work will make it a daemon.

While there is a decent API reference for Factory Orchestrator, and a C# sample showing those APIs in use there is not a good set of building blocks / guides for technical users to ramp up on the programming flows required.

Think: https://docs.microsoft.com/en-us/windows/uwp/get-started/create-a-hello-world-app-xaml-universal, which guides a dev through creating a hello world app, and explains why each step is done. Or https://docs.microsoft.com/en-us/windows/uwp/files/quickstart-reading-and-writing-files which then guides a dev through writing basic file R/W code.

Goal would be to author a set of mini-walkthroughs describing each useful 'thing' you can do with FO APIs. Ex:

• Connect to DUT
• Copy files
• Install & run apps
• Monitor task/tasklist status with ServerPollers
• Create tasks/tasklists
• Execute tasks/tasklists
• Interact with running tasks/tasklists (esp external tasks)
• Execute programs outside of a task
• Interact with containers

Issue is due to dotnet/runtime#50020

Workaround is documented in issue above, but requires a fork of behavior between Windows Service and Windows applications (likely by checking for an extra argument passed in to the service mode)

https://microsoft.github.io/FactoryOrchestrator/service-configuration/

These 3 settings are hard to understand how to use, and have a lot of overlap. We should consider:

• Consolidate into one single file.
• New TaskList attributes in XML (properties in C#) to denote if the tasklist is a first boot or every boot tasklist.
• All Tasks/TaskLists are returned by QueryTask(), GetTaskListGuids() & similar APIs.
• Consider deprecating GetBootTaskList* APIs.
• App UI shows all TaskLists, but divides between boot and non-boot, or has a UI toggle. This should be done no matter what :)

If an Executable task has a timeout or is aborted, child processes should be terminated also.

• variable naming style
• bracket placement etc

Not all actions needed happen in the HL OS. It would be great to understand if we can find a way to orchestrate:

1. Take an EFI Application from disk / somewhere
2. place it into a FAT32 / shared location
3. setup the system to boot to the EFI Application on next boot.

one example of this could be rebooting into EFI Shell and running some commands.

Describe the bug
File transfer from a remote FO service to a local app frequently gives Access Denied errors
To Reproduce
Steps to reproduce the behavior:

1. Install app on Win10 device
2. Install service on remote device
3. Connect app to remote device
4. Ensure file transfer permission is enabled in Settings
5. Attempt to transfer folder from remote -> local

Expected behavior
Works.

Screenshots

Environment (please complete the following information):

• OS: Win 10
• Service and/or client version(s): 10.3.0 for both