Sorry for not getting back to you, it's been busy days :|
I was going to share my thoughts about the architecture. I was thinking about something similar that @Arash-Sabet is proposing, but a little broader.
The Wexflow Core should be an independant NuGet package in my opinion. It should provide just the engine part (Tasks, Workflows, Scheduling, etc.), the xml necessities and basic file system tasks. Being an independant library, it can then be hosted in a Windows Service for production (as is now) or be run as a standalone executable (which would make debugging custom tasks way easier) or even be embedded in applications.
I was also thinking about replacing the xml parsing and fields in the Core classes with object serialization means provided by .NET. This would also provide the classes as the "schema" for json or other serialization targets.
Since you seem to own the Wexflow namespace in GitHub, there could easily be a "Core" project that we could start polishing the Core on. The current project would then be able to reference the new Core as a NuGet package
What do you think? I think I can write up the changes for the Core implementation that I have in mind this weekend, so maybe we can get serious on this soon if you like it