The tools look for app.config iso web.config in a new SDK style web project.

[fretje]

(First reported here, but as Brice kindly asked me to submit a new issue, here it is...)

I have an problem with the ef6 commands after updating my MVC5 web-project to the new SDK style project, following the instructions here.

Everything works, except that the tools (add-migration, update-database, ...) look for connectionstring information in app.config in stead of web.config.
I've been digging a bit into the code and I think the culprit is in the IsWeb method in EntityFramework6.psm1. This method looks for specific projectType guids, but I don't think these exist anymore for new SDK style projects.

I can work around it by creating an app.config file with the connectionstring information in it, but it would be nice if that wouldn't be necessary.

Further technical details

EF version: 6.4.4
Database Provider: EntityFramework.SqlServer
Operating system: Windows 10
IDE: Visual Studio 2019 16.8

[tompazourek]

Another possible workaround could be to separate your EF6 migrations into its own project that would have its own config. I often see this on larger apps, they want to avoid mixing everything in a large single Web project and prefer splitting it. Besides faster compilation times, and more granularity, a benefit you might get from this is that when separated, the migrations code doesn't actually need to be part of the runtime when deployed in production. That means the entire assembly with migrations doesn't need to run on the server and be loaded in the memory. It can be just part of some deployment code. But how much it's worth doing depends on how many migrations you have and expect to have in the future...

[fretje]

Yes, you're right @tompazourek, that's actually what I'm doing but I didn't want to complicate this issue with it as the main problem exists in both cases. I used to be able to just leave the web project as the startup project, and select the library project (with the ef stuff) in the package manager console as the connectionstring was then taken from web.config.
Now I have created an app.config in the library project (which has the same connectionstring info as the web.config), and I have to set that project as the startup project before executing ef commands. That is an extra step because I don't want to "pollute" my web project with an extra app.config. But in the end I would really like to not have to "pollute" my library project with an unnecessary app.config either ;-)

Also, what you're talking about is mostly about "at deployment time", while what I'm talking about is "at development time"... I'm talking about adding migrations and updating your local development database etc... Just a little developer convenience :-)

[tompazourek]

@fretje I see what you mean. I have always needed to setup the project containing the migrations as the start-up project, and also always needed to have the app.config with connection string there. That is before SDK-style projects were even a thing, so I'm not sure if it's actually related to that.

You're right that it would be nicer not needing the config there in two places...

[fretje]

If you change the startup project of the solution to the library project, then it's normal that you have to put an app.config in the library project, as the tools look for the connectionstring info in the startup project of the solution (has always been like that). If you have your migrations in a separate project, then you only need to change the "default project" in the package manager console to the library project. It's not necessary then to change the startup project of the solution.

I've been working like this since like forever. It's only now, after migrating my project to the new sdk style that I started having this problem. So it's definitely related. Also, look at the code that is using that "IsWeb" method I've mentioned before:

function GetConfigPath($project)
{
    if (IsWeb $project)
    {
        $configFileName = 'web.config'
    }
    else
    {
        $configFileName = 'app.config'
    }

    $item = $project.ProjectItems |
        where Name -eq $configFileName |
        select -First 1

    return GetProperty $item.Properties 'FullPath'
}

IsWeb will always return false for new sdk style projects, so this code will always look for 'app.config' and never for 'web.config'.

[julealgon]

I wasted around 4h today trying to fix this problem on our solution after migrating the projects to SDK-style.

[austinw-fineart]

If it wants app.config so badly, it can have it:

<None Include="Web.config">
  <Link>App.config</Link>
</None>

Bamboozled

[CZEMacLeod]

New style SDK projects have a property AppConfig which should be used instead of the hardcoded value in GetConfigPath

$configFileName = 'app.config'

In a SDK MVC5 project you can use

   <AppConfig>web.config</AppConfig>

to sort out binding redirects and other issues - but I think this would be ignored still by the EF6 commands.

Would something like

<ItemGroup Condition="'$(ForceAppConfig)'=='true'">
   <None Include="Web.config">
      <Link>App.config</Link>
      <Visible>false</Link>
      <InProject>false</InProject>
   </None>
</ItemGroup>

work?
ForceAppConfig could even be automatically set if you included the EF6 package?
If so, I could add this to my ASP.Net 4.x SDK

I think the true fix is

function GetConfigPath($project)
{
    if (IsCpsProject $project)
    {
        $configFileName = GetCpsProperty $project 'AppConfig'
    } 
    elseif (IsWeb $project)
    {
        $configFileName = 'web.config'
    }
    else
    {
        $configFileName = 'app.config'
    }

    $item = $project.ProjectItems |
        where Name -eq $configFileName |
        select -First 1

    return GetProperty $item.Properties 'FullPath'
}

[ajcvickers]

This issue has been closed because EF6 is no longer being actively developed. We are instead focusing on stability of the codebase, which means we will only make changes to address security issues. See the repo README for more information.