Does C# project with configuration file only seem to be an architecture flaw?

Question

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; Project1.ServiceHosting and Project2.ServiceHosting contained its derived types with overriden custom GetServices, LoadNinjectModules and GetBinding methods.
However, this looked like DRY violation.

• JeffO: How difficult is it to add another project that uses the same config file?

Answer 1

Projects in a Visual Studio solution generally have their own individual configuration files. However, the configuration file that gets used is the one that is captured in the starting app domain, and it actually is more complicated than that, due to roaming profiles and such. So any DLL's that are referenced in the starting project will use the starting project's app.config file, and not their own.

In short, having a single app.config file in play is not only not an architectural flaw, but it's considered good practice in the .NET world.

See Also
How to find path of active app.config file?