Reputation: 3489
First off to get the research out of the way. I have already seen and applied the solution in the answer to this question here: Web Deploy / Publish is adding a unknown connection string?
It does not work, and by that I mean, it does not have any affect whatsoever on the problem I'm facing.
Another piece of information that might help is that I am working on Visual Studio 2015 Enterprise.
Alright, now the problem that I am facing is a strange one. I have two DB connections in my web.config
file. They are defined like this:
<add name="DefaultConnection" connectionString="Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\Test.mdf;Initial Catalog=Test;Integrated Security=True" providerName="System.Data.SqlClient" />
<add name="ErpConnection" connectionString="Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\Test.mdf;Initial Catalog=Test;Integrated Security=True" providerName="System.Data.SqlClient" />
The context associated with DefaultConnection
is ApplicationDbContext
. And the context associated with ErpConnection
is ErpEntityContext
. Each of these is defined like this:
public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
public ApplicationDbContext()
: base("name=DefaultConnection")
{
}
public static ApplicationDbContext Create()
{
return new ApplicationDbContext();
}
}
And:
public class ErpEntityContext : DbContext
{
public ErpEntityContext()
: base("ErpConnection")
{
}
}
However, web deploy decides that ApplicationDbContext
and DefaultConnection
must be two very different things so ends up showing them as two different connections like in the image below:
Removing DefaultConnection
from web.config
gets rid of the double entry (this is obviously not the solution since I would like to have my connection string around). Changing the name of the connection string does not matter at all. It also does not happen with ErpConnection
.
This happened from one session of Visual Studio to another and appeared out of nowhere yesterday. Then after some hours it automatically disappeared when I relaunched VS. I thought it was fixed and everything was dandy but today it has reappeared. I am completely lost as to what may be going wrong here. As much as I am interested in a solution, I would also appreciate if someone could tell me why this is happening.
EDIT:
To clarify and answer the questions asked in the comments, I do not have any transformations specified and the problem appears in all build configurations.
Also, I have tried to publish with Remove additional files at destination
checked and unchecked. Similarly, I have tried to publish with Exclude files from the App_Data folder
checked and unchecked to see if I can fool the thing ( :) ). But to no avail so far.
UPDATE:
Further investigation of the issue reveals that the culprit may be the use of Loaded
event in DbConfiguration
:
Loaded += (sender, args) => args.ReplaceService<DbProviderServices>((s, _) => new CachingProviderServices(s, transactionHelper, new ExampleCachingPolicy()));
The documentation for this event says:
Occurs during EF initialization after the DbConfiguration has been constructed but just before it is locked ready for use. Use this event to inspect and/or override services that have been registered before the configuration is locked. Note that this event should be used carefully since it may prevent tooling from discovering the same configuration that is used at runtime.
The question is what the fix would be in case this event needs to be used. I will write an answer if I find one but if anyone else knows please feel free to do so.
Upvotes: 4
Views: 747
Reputation: 171
After long hours of research and experimentation, I finally found a way to get rid of the double entry: give your connectionString the same name as your Context!
So, to answer the question, renaming the connection string DefaultConnection
to ApplicationDbContext
should remove the double entry. Note that you'll also need to update the following with the new connection string name:
public ApplicationDbContext()
: base("name=ApplicationDbContext")
Sadly enough though, I decided to leave it as it was (with the double entry) since it gives me the possibility to either use Execute Code First migrations (runs on application start)
or Update database
to update the database.
The advantage of using Update database
is that you can run custom SQL scripts before and after the Schema update.
Upvotes: 1