Proper project organization and architecture for sharing code in Visual Studio/.NET projects

Question

I'm looking for recommendations on how to best share code between multiple Visual Studio projects. I'm struggling with a fundamental topic and trying to get some ideas to get over it.

My solution has:

• Several web app projects
• Several standalone process projects, eg Windows Services and/or console apps and/or Azure WebJobs

An example of functionality which is common to all projects is the need to call some common web service, or the need to read and write from Amazon S3, for example.

Where I struggle is this: Obviously the code that implements the common functionality should be broken out on its own, for example in a separate class library project. To talk to S3 for example, the code needs to know my Amazon credentials, S3 endpoints, etc. - all these things would normally be stored in app configuration files. But I don't like the idea of putting config files in class library projects because it binds a particular implementation to them. But in order to not do that, I have to pass in this information from the calling project. So for example the web app's web.config and the console app's app.config files contain this connection information. When calling the S3 code, I would assumingly pass this config info into the shared code.

However, this seems yucky* to me and I'm not sure why. It still feels to me like I'm "binding" the S3 code (for example) to a particular config method, if that makes sense. I'm not sure if my feeling is a mis-formed bias.

*For example, I may have an arbitrary amount of configuration data that would have to be passed in:

• Connection strings
• Credentials for web services
• API endpoints
• Arbitrary data from my app's config settings (which some of the callers will need, but others won't, so lots of times the data will just be useless yet I have to do the work of passing something in)

So every time I added a config variable in my main app, I'd have to modify the constructor of the common code. Things would be in constant motion.

Can you give me suggestions on this?

Answer 1

I like to use Configuration objects as parameters, that way the signature never changes, even if you add/remove properties. For instance....

public class AmazonConfigSettings {
    public string AWSkey { get; set; }
    public string ApiEndpoint { get; set; }
    ......
}

Your signature could then always look like:

public MySharedClass(AmazonConfigSettings config) { .... } 

Even if (when) Amazon overhauls their webservice settings completely.