Language/Framework: C# / .NET + Core
I provide a desktop, multi-platform client-server API for HW control related purposes. The "Server" is communicating with multiple HW components. The "Client" is used to develop desktop applications that can communicate with the HW, using the "Server" as a proxy and for synchronization purposes.
Currently, both client and server are built to dll assemblies, and the UI for both is developed separately. This produces 4 files: 2 dll's, and 2 exe's (Client and Server run in different processes)
There are shared resources (as "links") in the code-base: client-server comms protocol, timeouts, etc.
The question: is it architecturally correct to "merge" the client and server API's into a single assembly?
This will provide many benefits: single dll for development, maintenance, and deployment. The only drawback I see, is violating "decoupling". On the other hand though, these 2 components are strongly coupled, as they share comms interface and other necessary information.