I have multiple related projects in one Visual Studio C# solution, which in general have similar architecture of WCF business logic services and ASP.NET clients.
In order to host these services, I have implemented custom
ServiceHosting application, which reads binding and port settings, services list and NInject settings from
App.config file and hosts these services.
Since all these settings vary from project to project, in each "subproject" I have a project like "ServiceHosting.Project1", which has only one file "App.config" containing project-specific configurations. As project startup settings, I have specified
ServiceHosting.exe with working directory of this configuration project.
So, in general it looks like:
Project 1 - Project1.Domain (contains business logic, class library) - Project1.ServiceHosting (contains configuration only, runs Tools/ServiceHosting) Project 2 - Project2.Domain (contains business logic, class library) - Project2.ServiceHosting (contains configuration only, runs Tools/ServiceHosting) Tools - ServiceHosting (application. you may run this, but no App.config will be found)
However, having a project with one configuration file smells bad for me.
Is it considered an architecture flaw?
Earlier, I had another approach - instead of using configuration file,
ServiceHosting.cs was an abstract class;
Project2.ServiceHosting contained its derived types with overriden custom
However, this looked like DRY violation.