4

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:

enter image description here

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.

Community
  • 1
  • 1
Nico
  • 3,471
  • 2
  • 29
  • 40
  • Is it your intention that both connection strings are identical? Also, do you have any transformations specified (can you expand your .config file and see sub-nodes)? Finally, does the problem apply in all build configurations, just debug, etc? – Basic Nov 06 '15 at 17:48
  • @Basic Yes, that is correct. However, changing those strings to something different has the same result. One connection gets displayed twice and messes stuff up on publish. – Nico Nov 06 '15 at 17:50
  • 1
    @Basic thanks for the questions, I updated the question to clarify the situation. But in short, no transformations, and yes it happens in all cases. – Nico Nov 06 '15 at 17:54
  • I am experiencing the exact same problem. Did you ever find a solution ? – Alexandre Jan 17 '18 at 20:17
  • @Alexandre Never was able to figure it out. Gave us on it. – Nico Jan 17 '18 at 23:58
  • 1
    @NicolásCarlo Thanks! I've been working around it without any real problems but I was curious. – Alexandre Jan 21 '18 at 05:07

1 Answers1

1

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.

Alexandre
  • 161
  • 4
  • Wen you changed the name, did you also changed it in this line ```public ApplicationDbContext(): base("name=DefaultConnection")```? As far as I know, migrations will use the parameterless constructor. – IvanGrasp Feb 14 '18 at 20:21
  • Yes I did. Although our code uses an appSetting that defines the connection string name to use so I only had to update the proper appSetting. I haven't tested it thoroughly but the app seemed to be working normally. – Alexandre Feb 14 '18 at 20:59
  • I had some issues with one of my projects. Depending on how your app starts it may read the configuration from a different file. For example, an EF project in a solution with a MVC project set up as "StartUp Project", will read the appSetting from Web.config instead of app.config. – IvanGrasp Feb 14 '18 at 21:23
  • 1
    Thanks! I do not have the project to test this on anymore. If someone can confirm that this works then I'll accept this answer. – Nico Feb 15 '18 at 23:32