I am running into an issue while testing the NServiceBus Quickstart using .NET 10 and the Learning Transport via Particular.PlatformSample.
When I launch the solution, the console hangs indefinitely on the following message: Waiting for ServiceControl to be available .NET 10
Diagnostic details so far:
Environment: Local development machine running the standard portable/in-process quickstart setup.
Process Status: I checked Windows Task Manager while the launcher was waiting, and ServiceControl.exe is not running at all. It seems to be failing or crashing instantly upon launch before it can even spawn a process footprint or bind to its local ports.
Troubleshooting tried: I have already tried cleaning the solution, deleting the bin/obj folders, ensuring the project folder path is short, and looking for a .learningtransport directory to clear out, but the behavior remains exactly the same.
Because this is the out-of-the-box quickstart with the learning transport, there are no external databases or Windows services installed.
Has anyone else encountered this instant-crash behavior with the portable platform binaries under .NET 10, or is there a specific environment variable or prerequisite I might be missing?
I managed to identify the cause and found a workaround.
The issue is related to the runtime configuration of the ServiceControl components included in Particular.PlatformSample.
While the PlatformLauncher targets .NET 10.0.0 and uses the default runtime roll-forward behavior, the ServiceControl components explicitly request .NET 10.0.11 and disable roll-forward:
My development machine has .NET 10.0.13 installed, but not 10.0.11. Because roll-forward is explicitly disabled, the ServiceControl processes fail to start despite the newer patch version being available.
A workaround was to set the following environment variable on the PlatformLauncher launch profile in Visual Studio:
The ServiceControl child processes inherit this setting, allowing them to start successfully using the installed runtime.
This resolves the startup issue without modifying the runtime configuration files distributed with the package.
I’m still curious whether disabling roll-forward is intentional or a side effect of the packaging process, as it makes the Platform Sample dependent on an exact .NET patch version.