Optimize EF6 to work with PackageReference and no app.config

[ErikEJ]

(Edited by @divega. Re-purposing this issue to detail the current action plan on this area. The original text of the issue was kept at the bottom)

We had a discussion with the NuGet team on what we can do to adapt the EF6 package to a world in which more customers use NuGet's PackageReference and Install.ps1 doesn't execute anymore and in which potentially package.config is discouraged or even disabled in the long term. Here are a few things we want to make sure are enabled:

• No breaking change: Application with existing EF6 entries in app.config should continue to work based on the existing configuration when upgrading
• F5 experience works: New applications that download the EF6 package without app.config should be able to work out of the box with (e.g. F5 experience) SQL Server, likely assuming (localdb)\mssqllocaldb instance. This may required changes to default provider and connection factory registration
• Works for other providers: New applications that download an EF6-based provider package should be able to work easily
  • For this to happen automatically we may need a new mechanism to configure the provider, e.g. could we use MSBuild props or targets as detailed at https://docs.microsoft.com/en-us/nuget/create-packages/creating-a-package#including-msbuild-props-and-targets-in-a-package?
  • Otherwise having good coverage in the documentation on how to do this manually (which would require finishing porting EF6 to docs.microsoft.com) might be acceptable
  • We need to identify existing providers that use the recommended PowerShell commands to register the provider and understand in what state the changes would leave them
• Commands advertising: Since install.ps1 won't run, we won't be able to display a banner telling customers about the available commands. Should we resort to a readme.txt file instead? This actually affects EFCore tools as well (Not needed)
• T4 template distribution: Currently we use NuGet packages (entityframework.codetemplates.csharp and entityframework.codetemplates.visualbasic) to distribute customizable versions of the T4 templates for the "code first from an existing database" option in the EF6 designer. We would need to have alternative ways to distribute them, e.g. add them as item templates in the designer's setup, or point customers to the code in docs, github, etc. (Moved to Update VS Tools to work with SDK-style projects #883)

@bricelam @ajcvickers please add any details I missed.

---

[VS2017RC3] No app.config created when using "packageReference" iso packages.config

File, New Project, Console Appliation, Target .NET 4.0, add EntityFramework package, use PackageReference,

Result: app.config file with EF settings created

Actual: no app.config file at all... Causing EF to fail completely

[rowanmiller]

This is a side effect of NuGet no longer running Install.ps1 for non-pacakges.config scenarios. Our team gave feedback during the design phase that we didn't think this was a good change. Some feedback from customer may help the cause - https://github.com/NuGet/NuGet.Client.

[ErikEJ]

@rowanmiller Thanks, it was more meant as a warning of the coming support requests caused by this NuGet "malfunction"

[davkean]

@rowanmiller @divega @rrelyea Can we figure out which side of the fence is going to fix this? Currently there's a bug both against EF and NuGet that are pointing to each other.

[divega]

@davkean Yes, already looking at it.

In the meanwhile, the recommended workaround if to manually to the application's .config file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
 <configSections>
    <!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
    <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
  </configSections>
  <entityFramework>
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
      <parameters>
        <parameter value="mssqllocaldb" />
      </parameters>
    </defaultConnectionFactory>
    <providers>
      <provider invariantName="System.Data.SqlClient" type="System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer" />
    </providers>
   </entityFramework>
</configuration>

[divega]

Note for triage: users don't need to be using the new csproj file format. It is enough to use PackageReference instead of package.config.

[ErikEJ]

Sorry if that was unclear in my original issue description

[Latency]

Designer is broken regardless of an app.config being copied over from old MSBuild configurations. Template for new project configuration format does not require this file for ADO.NET Entity Data Model -> Empty EF Designer Model & Code First for the new MSBuild (Core/Standard) project configurations targeting net[45-472] frameworks.

[MrBjorn]

Hi,

I have a WinForm application that uses EF6.2. Can I use Nugets new packageReferences with EF6? I get this warning about EF in the migration dialog.

[Latency]

Hi,

I have a WinForm application that uses EF6.2. Can I use Nugets new packageReferences with EF6? I get this warning about EF in the migration dialog.

The answer is yes! But, it has nothing to do with EF6. Has to do with MSBuild configurations for what your framework is targeting and the newer build constructs.

Can you update the project config to vs2017 std/core configs?

See here for my example.

OR

See here for a video tutorial.

[bricelam]

@divega @ajcvickers The Microsoft.SqlServer.Compact package also doesn't work with PackageReference. Should we work with them to update it as part of this work?

[ErikEJ]

SQL CE 4 is in extended support - abandon it?

[divega]

Should we work with them to update it as part of this work?

It seems that "them" is the ASP.NET team 😄, right?

Am I understanding correctly that we need it to work with PackageReference to be able to run our tests?

I am thinking that if we decided to "abandon" it as @ErikEJ suggest's, customers will still be able to use the EF 6.2 provider. There isn't currently any new scenario we are enabling by recompiling the SQL CE providers with EF 6.3, correct?

[bricelam]

Correct, the only new features we intend to add for providers are to make PackageReference easier (I.e. alternatives to the current install.ps1 and content hooks)

[ErikEJ]

Alternatively you could remove the reference to the Microsoft.SqlServer.Compact package (like it was the case for the 3.5 provider) - and then install the 4.0 MSI as a build requisite:

msiexec /i %APPVEYOR_BUILD_FOLDER%\tools\SSCERuntime_x64-ENU.msi /quiet /qn

[divega]

I think that would solve one problem, but wouldn’t it also break existing SQL CE customers (the majority of whom are presumably content using package.config) when they try to upgrade the package?

We can follow up with ASP.NET (cc @Eilon) to see if updating Microsoft.SqlServer.Compact is feasible. Otherwise we discuss the other alternatives.

[ErikEJ]

OTOH, some people would be happy if the Microsoft.SqlServer.Compact package was updated to work with packagereference @onovotny

[ajcvickers]

Some thoughts on this:

• If at all possible, existing providers should continue to work with the new EF6 release, even if they only worked with package references before.
  • This only applies to net40 and net45. Existing providers will need to be updated to work with Core.
• Neither of the SQL Compact providers will work with Core because the ADO.NET part is not being ported to core.
  • Given the usage of compact and it's support lifetime, bringing compact to core seems like a non-starter

Therefore, if we do nothing here, then the existing provider should still work for net40 and net45, which is about as good as we can do anyway, So I say, let's not change it.

[madelson]

This thread seems to apply that EF6 will not work properly in a PackageReference project if the app.config changes aren't manually recreated. Is this true? As far as I can tell it works fine for creating a code-first DbContext that connects to SqlServer. What, exactly breaks if you don't have the app.config stuff?

[ggirard07]

@madelson things started to fall apart for me when I added .Net Standard reference in my project (.Net 4.6.1 project).
When I tried to run migration, the command line simply failed because some dependencies were not copied to the temp location used to run the migration command.

[madelson]

@ggirard thanks! Did you encounter any runtime issues or was it all dev time stuff like migrations?

[ggirard07]

@madelson to be honest I did not dig in too much when I tested it... When I saw things started to go south and I were no longer able to deploy my DB I did not really tested it and rolled back.

[madelson]

@ajcvickers or @ErikEJ do you know the answer to my question?

This thread seems to apply that EF6 will not work properly in a PackageReference project if the app.config changes aren't manually recreated. Is this true? As far as I can tell it works fine for creating a code-first DbContext that connects to SqlServer. What, exactly breaks if you don't have the app.config stuff?

[bricelam]

I think we hard-code how to find the SqlServer EF provider (since it ships in the same NuGet package). But without an App.config, it will default the server to .\SQLEXPRESS. Using packages.config, we'll check for LocalDB and change the default to that if available.