Entity Framework 6.1.3 migration ignoring second context - entity-framework

Question

We have two models, a Shared model and an Individual model, each with their own context. The Shared model includes a listing of all individual items along with various metadata. Each individual item has a foreign key back to this listing.
When running migrations to the Individual model we connect back to the Shared context during the "Seed" method to grab some of the listing's metadata for that item. There may be multiple instances of each type of context active at a time, so we sneak pieces of our desired Shared context's connection string into the Individual string by way of the "Application Name" attribute and dynamically generate the Shared one in code. It's a bit of a cheat, but it's worked fine for a very long time while using Entity Framework 6.0.1, however a recent upgrade to 6.1.3 seems to have broken this and I don't know why.
Here's some of our code:
public class IndividualConfiguration : DbMigrationsConfiguration<IndividualContext>
{
protected override void Seed(IndividualContext context)
{
var store = context.Stores.FirstOrDefault();
var storeListingId = store.StoreListingId;
var sharedContext = GetSharedContextFromIndividualContext(context);
var storeListing = sharedContext.StoreListings.FirstOrDefault(p => p.Id == storeListingId);
/* Use listing metadata for things... */
}
public SharedContext GetSharedContextFromIndividualContext(IndividualContext context)
{
var connString = context.Database.Connection.ConnectionString;
var builder = new SqlConnectionStringBuilder(connString);
/* Derive shared context info from the Application Name... */
builder.InitialCatalog = derivedCatalog;
builder.DataSource = derivedDataSource;
builder.ApplicationName = string.Empty;
return new SharedContext(builder.ConnectionString);
}
}
The migration command I enter into the Nuget Package Manager Console is:
update-database -configuration "IndividualConfiguration"
-ConnectionString "Data Source=localhost;Initial Catalog=IndividualDatabase; Integrated Security=True;
MultipleActiveResultSets=True; Application Name=SharedDatabase|localhost"
-ConnectionProviderName "System.Data.SqlClient" -force –verbose
Notice how "SharedDatabase|localhost" is used in the Application name. Those are the catalog and data source of the matching shared context. Looking at the results via the debugger, I can confirm that "builder.ConnectionString" has built the correct connection string, which would be:
"Data Source=localhost;Initial Catalog=SharedDatabase;Integrated Security=True;MultipleActiveResultSets=True;Application Name="
...and yet, when looking up the "StoredListings" DbSet from the returned sharedContext, the code errors out with "Invalid object name 'dbo.StoreListings'."
While troubleshooting this, I tried modifying the code that gets the SharedContext to see when things go wrong:
var ctx = new SharedContext(builder.ConnectionString);
var connBefore = ctx.Database.Connection.ConnectionString;
string latestMigration = ctx.Database.SqlQuery<string>("SELECT TOP 1 MigrationId FROM [__MigrationHistory] ORDER BY MigrationId DESC").FirstOrDefault();
var connAfter = ctx.Database.Connection.ConnectionString;
throw new Exception("CONN BEFORE: " + connBefore + Environment.NewLine + Environment.NewLine + "CONN AFTER : " + connAfter + Environment.NewLine + Environment.NewLine + "LAST MIGRATION: " + latestMigration);
...and ended up with:
CONN BEFORE: Data Source=localhost;Initial Catalog=SharedDatabase;Integrated Security=True;MultipleActiveResultSets=True;Application Name=
CONN AFTER : Data Source=localhost;Initial Catalog=IndividualDatabase; Integrated Security=True; MultipleActiveResultSets=True; Application Name=SharedDatabase|localhost
LAST MIGRATION: 201607081517538_LatestIndividualMigration
So for some reason, despite the shared context's connection string being correct, upon USING the connection it reverts back to the same individual string I used in the migration command.
Does anyone know why that second context is getting ignored? I can confirm that if I revert back to Entity Framework 6.0.1 everything starts working again, so I want to say that something changed from 6.0.1 to 6.1.3 that invalidates our code but I have no idea what that could be.