title: .Net Core 1.0.0, multiple projects, and IConfiguration
body: <p><strong>TL;DR version:</strong> </p>
  
  <p>What's the best way to use the <a href="https://docs.asp.net/en/latest/fundamentals/configuration.html" rel="nofollow">.Net Core IConfiguration framework</a> so values in a single appsettings.json file can be used in multiple projects within the solution? Additionally, I need to be able to access the values without using constructor injection (explanation below).</p>
  
  <p><strong>Long version:</strong></p>
  
  <p>To simply things, lets say we have a solution with 3 projects: </p>
  
  <ol>
  <li>Data: responsible for setting up the ApplicationDbContext, generates migrations</li>
  <li>Services: class library with some business logic</li>
  <li>WebApi: REST API with a Startup.cs</li>
  </ol>
  
  <p>With this architecture, we have to use <a href="http://benjii.me/2016/05/dotnet-ef-migrations-for-asp-net-core/" rel="nofollow">a work-around</a> for the "add-migration" issue that remains in Core 1.0.0. Part of this work-around means that we have a ApplicationDbContextFactory class that must have a parameterless constructor (no DI) in order for the migration CLI to use it.</p>
  
  <p><strong>Problem:</strong> Right now we have connection strings living in two places; </p>
  
  <ol>
  <li>ApplicationDbContextFactory for the migration work-around</li>
  <li>in the WebApi's "appsettings.json" file</li>
  </ol>
  
  <p>Prior to .Net Core, we could use ConfigurationManager to pull connection strings for all solution projects from one web.config file based on the startup project. How do we use this new IConfiguration framework to store connection strings in one place that need to be used all over the solution? Additionally, I can't inject into the ApplicationDbContextFactory class' constructor... so that further complicates things (more-so since they changed how the [FromServices] attribute works).</p>
  
  <p><strong>Side note:</strong> I would like to avoid implementing an entire DI middleware just to get attribute injection, since Core includes it's own DI framework. If I can avoid that and still access appsettings.json values, that would be ideal.</p>
  
  <p>If I need to add code let me know, this post was already long enough, so I'll hold off on examples until requested. ;)</p>