title: How to share company wide settings across multiple team projects in TFS?
body: <p>This is a problem we have been living with for a while already. Suppose that I have three files:</p>
  
  <ul>
  <li>a FxCop ruleset, containing our basic Code Analysis rules</li>
  <li>a Resharper .DotSettings file, with company defined naming conventions, for instance</li>
  <li>a StyleCop.Settings file, with some of the default style cop settings disabled</li>
  </ul>
  
  <p>How do I share these kinds of company wide settings files across multiple TFS Team Projects?</p>
  
  <p>At the moment, we have these replicated in a <code>Resources</code> folder in each project, but this is quite a maintenance nightmare, since when we decide to update a few rules on any of these files, we have to update them in a lot of different places.</p>
  
  <p>One approach I've seen is to create a team project specifically to store these files on TFS, for instance <code>$/Core</code>, and by some means share the files this way, either using workspace mappings or branching the project into the other projects.</p>
  
  <p>I don't like this primarily because it requires manual intervention and hardcoded paths. Ideally, I'd like an approach that was not intrusive, i.e. a developer gets the project from source control and compiles without any problems. No need for separate mappings into specific forlders, setting environment variables, anything like that.</p>
  
  <p>At the same time, I'd like to keep the history on these files, so it would be nice if they could still be source controlled. Since they are central to the company, it would be ideal to have limited permissions on them, and that each change was documented appropriately (changesets provide that).</p>
  
  <p>Another approach that crossed my mind was to share these settings via company internal nuget packages. Say for instance that I do have this <code>$/Core</code> project, but instead of using workspace mapping or branching it inside the other projects, I publish a nuget package (or more than one even) containing the configuration files, and add these packages to each project that needs it. I can then use relative paths to the package folder when referencing them, and it would require no manual intervention on the developers part.</p>
  
  <p>Although using nuget would probably work fine, this solution seems weird to me, since nuget packages are meant to be project specific, but this would be "whole team project" specific instead. Again, using this approach, I'd probably have to add the package to one of the projects inside one of the solutions inside each team project. This is actually quite similar to how test adapters are shared now. For instance, <code>NUnit</code> <a href="https://www.nuget.org/packages/NUnitTestAdapter/" rel="nofollow">already support this approach</a>. I feel I'd have to do something very similar to that if I went with an internal nuget package: each solution would have to load the package at least once.</p>
  
  <p>Is there some other way to share these kinds of things across the whole company, while still maintaining them on source control? What if I loosened this constraint, and accepted that they don't need to be source controlled? Would it open up other options to share them?</p>