As @OriginalGriff points out, you can grind your system to a crawl.
You could still use
TPL[
^] which uses a thread pool. It will manage the load for you based on the number of CPU cores.
To do this, I would write the processing as a plugin DLL (late binding). This allows you to load multiple instances into memory and still communicate between the host app and the plugin DLL instances allowing the host app to display processing information for each running task. You could pool the plugin DLL instances and reuse/recycle to reduce lag from loading and activating new DLL instances.
I did a quick google and found an article here on CP:
C# Winforms Plug-ins Architecture Example[
^]. I would look at how this works and use it as a guide to building your bespoke TPL processor.
UPDATE
@BillWoodruff questioned if it was possible...
Interestingly, .Net has it's own addin framework that you can use in your app:
Add-ins and Extensibility | Microsoft Learn[
^]
Here is a better example of what I was explaining:
WPF - Build Fault-Tolerant Composite Applications | Microsoft Learn[
^]. To quote the article:
Isolation Levels
Microsoft .NET Framework applications can handle third-party plug-ins in at least three different ways:
No isolation: Run host and all plug-ins in a single process with a single AppDomain.
Medium isolation: Load each plug-in in its own AppDomain.
Strong isolation: Load each plug-in in its own process.
It's
Strong isolation that I was referring to. See the article for more information on how.
For .Net Core, there is this:
Create a .NET Core application with plugins - .NET | Microsoft Learn[
^] and also:
GitHub - weikio/PluginFramework: Everything is a Plugin in .NET[
^] and this:
GitHub - merken/Prise: A .NET Plugin Framework.[
^] (
https://maartenmerken.medium.com/announcing-prise-a-plugin-framework-for-net-core-4af7cf5b4d2b[
^]).
Hope this helps.
Submit an article or tip