Include pre-built Windows Service into build of another project

Question

Current situation :

• Multiple .NET Framework solutions (implementations) that each have :
  • Core logic library project
  • Windows Service project (builds as exe)
  • WPF UI (builds as exe)
• Core logic is run on a timer that is kept alive by the Windows Service
• Windows Service communicates over WCF to a WPF UI

Desired situation :

• Multiple .NET solutions that only include the unique portions of logic that cannot be reusable between implementations
• Reuse one common WPF UI
• Reuse one common Windows Service by each individual implementation

---

I am struggling to figure out how one common Windows Service project could be maintained, that could then be consumed by every implementing project (1 (windows service) -> to -> many (implementations).

The main limitation here being that Windows Service needs to build to an exe and have an installer to go with it, so that the service can be added to the registry.

---

Possibilities I could think of thus far :

1. Some strange pre-build event process of pulling down pre-built components for the Windows Service from somewhere (GitHub perhaps), adding them to the build directory and using said components in the build of the final installer
   • Sounds absolutely appalling and a nightmare to maintain to me
2. Maintain a common .NET project for the Windows Service. Have a rule that any new or existing solutions must 'Add>Existing Project' and point to the common .NET Windows Service project.
   • Is dependent on humans following a particular workflow each time they create/make changes to a solution, which...I am not a fan of
   • Is a little counterintuitive and is definitely repetitive and redundant to have the same exact project in each individual solution, despite needing only the build results of said project.
3. Abandon Windows Service + WCF. Adapt an architecture that more resembles microservices - run the logic that keeps the core logic alive and allows the UI to get updates to it in a docker instance.
   • Definitely sounds like the 'right' and future-proof way to do this
   • The most effort to refactor a significant portion of the codebase
   • Introduces new, unknown and potentially significant problems that using Docker may introduce given the app's highly restricted execution environment (Windows Server with sometimes extremely restrictive privileges)

Is there some method of architecting such an application that I am not aware of/not thinking of?