Efcore: dotnet ef dbcontext scaffold can't be run on .NETStandard class library projects

[MaximRouiller]

Running the following on a .NET Standard Class Library:

dotnet ef dbcontext scaffold <CONNECTION> Microsoft.EntityFrameworkCore.SQLServer

Will produce this error:

Startup project 'projectName' targets framework '.NETStandard'. There is no runtime associated with this framework, and projects targeting it cannot be executed directly. To use the Entity Framework Core Package Manager Console Tools with this project, add an executable project targeting .NET Framework or .NET Core that references this project, and set it as the startup project; or, update this project to cross-target .NET Framework or .NET Core.

Similar issues on StackOverflow:

• PowerShell
• dotnet cli
• PowerShell again
• Another

Note: All those users are using the tools as expected. It used to work before Core if I remember correctly.

Steps to reproduce

Get your command line to a directory with a project of type .NET Standard Class Library and run the following command,

dotnet ef dbcontext scaffold <CONNECTION> Microsoft.EntityFrameworkCore.SQLServer

Further technical details

EF Core version: 2.1.1
Database Provider: Microsoft.EntityFrameworkCore.SqlServer
Operating system: Windows 10
IDE: CLI

csproj content:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <ApplicationIcon />
    <StartupObject />
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="2.1.1" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.1.1" />
    <PackageReference Include="NuGet.Protocol.Core.Types" Version="4.2.0" />
    <PackageReference Include="NuGet.Protocol.Core.v3" Version="4.2.0" />
    <PackageReference Include="Semver" Version="2.0.4" />
  </ItemGroup>

</Project>

// @spboyer for tracking

[ErikEJ]

Well documented here: https://docs.microsoft.com/en-us/ef/core/miscellaneous/cli/#frameworks

[MaximRouiller]

Hi @ErikEJ,

I don't think it should be the default behavior to have the user create a throwaway project just for basic behaviors.

The normal user will try to create a class library and extract their existing database model to that class library (for reuse) and immediately fail.

What is the root cause issue for this? Why can't we support .NET Standard libraries? By default, Class Libraries are created as .NETStandard and will fail by default when people try to extract their model to this class library on the first try.

This issue was created for tracking this workaround so that we can have a better user experience in the future. Do we have an existing issue I can track instead of this one?

[ErikEJ]

You can use EF Core Power Tools reverse engineering and not be required to install anything in your solution 😁

[MaximRouiller]

Is EF Core Power Tools available for VS Code? I'm thinking about the Linux and MacOS communities out there that would be trying to use this. 😁

[ErikEJ]

No, not at the moment, but PRs highly appreciated

[MaximRouiller]

It was half a joke.

I think those are core scenarios that should be covered.

Opinions? @divega @bricelam

[bricelam]

In order to make .NET Standard projects work, we'd have to cross-target netcoreapp2.0, restore, and build behind the scenes when you invoked an EF command. We considered it (#8349), but decided it was too high-cost and error-prone.

Cross-targeting netcoreapp yourself would be a better solution, but cross-targeting projects aren't well supported in VS (especially by UWP and Xamarin projects). If they become more supported, we can fix #10882 and recommend cross-targeting instead of using a dummy project.

[MaximRouiller]

Taking into consideration that I'm a complete n00b in the intricacies of EF Core. I've used it but never did a PR on it.

1. Why do you need to cross target to make it work? What's causing the requirements to have netcoreapp2.0 instead of netstandard2.0?

So let's assume that's a scenario that absolutely has to be covered and that the EFCore team is missing the tools/support/Pym particles to achieve that.

1. Who do I need to talk to? Who can make better cross-targeting happen? Who can help us achieve that?

[bricelam]

.NET Standard isn't a runtime--it's just an API contract. In order to execute code, you need an actual .NET runtime like .NET Framework or .NET Core. The EF Core tools need to execute code in your project to build the model, load design-time services, etc.

On top of that NuGet will only restore assemblies and native libraries for the target framework. So even if we did just load the .NET Standard assembly into .NET Core and try to execute it, none of its .NET Core dependencies would be present.

The EF Core Power Tools do it by...

1. Not loading design-time services defined in the project
2. Including a copy of certain providers (SQL Server, SQLite, etc.) that it can use. Unfortunately, this means that even if you install a newer version of the provider into your project, it will still use the older copy.

Trust that we've talked to several teams at Microsoft about this. No other team executes .NET Standard code at design-time. Even xUnit.net prohibits running tests directly from a .NET Standard class library.

We have filed issues for the places cross-targeting falls short. Those issues are prioritized by the individual teams.

[bricelam]

You could consider filing an issue on dotnet/templating to change the default framework of class libraries to .NET Core instead of .NET Standard, but they're not likely to change it just for the sake of EF.

You can also just type this instead:

dotnet new classlib -f netcoreapp2.1

[MaximRouiller]

@bricelam Thanks for the clarification. It makes sense.

I feel like something should be done. Can I specify a project and scaffold into another? Is that a supported scenario? Like... "here's my entry point but here's where I want you to generate the data"..

I feel like users will bump their head on this nonstop.

[bricelam]

dotnet ef --startup-project EntryPointProject/ --project AddToProject/

[MaximRouiller]

Can we add this to the documentation as the recommended way of doing things? At the very least, we should document the actual error message and the code you posted as a way to resolve the issue.

The results while copy/pasting the error in Google only takes us to GitHub and StackOverflow. We should lead users directly to our docs to offer them a prescriptive way of solving their problem.

/cc @Rick-Anderson @mairaw

[divega]

@bricelam let's talk about what we can add to the docs, fwlinks, etc.

[ajcvickers]

Create a fwlink.

[ajcvickers]

@divega to create a forward link.

[MaximRouiller]

Thanks!

Do I understand this right? Will we have a fwlink that will be shown in the tooling directly when a user encounter this error?

[divega]

@MaximRouiller The fwlinks are included in the message you get in the tools output and point to an explanation in our documentation. They are https://go.microsoft.com/fwlink/?linkid=2034705 for PMC and https://go.microsoft.com/fwlink/?linkid=2034781 for dotnet ef.

[MaximRouiller]

Perfect! Thank you so much @divega! 😄

[symbiogenesis]

Why couldn't the CLI automatically generate a true .NET Core (or Framework) project in a temp folder to circumvent this?

[divega]

@symbiogenesis I don’t remember the full details, but I think @bricelam explained to me why that wasn’t as easy as it sounds. For starters, that temp project would need to reference you library, pick a runtime that works in your machine. @bricelam any comments?

[sjkaminski]

Surprised that the nuget package for Tools can be installed into a .NET Standardized project.

[mbasij1]

You can use EF Core Power Tools reverse engineering and not be required to install anything in your solution 😁

you change title for solving. but it was amazing answer! i do with this solution

[abdelgrib]

Worked for me !

You cannot target directly .NET Standard dll bt scaffold ! Specify the exe project (start-up) of the solution that ref your dll in your scaffold script.
Add the necessary packages to your exe project.

dotnet ef dbcontext scaffold
"conn_string"
Npgsql.EntityFrameworkCore.PostgreSQL
-o Entities
-project //or -p or us cd to this project
--startup-project ../ //or -s ../

See more :

https://stackoverflow.com/questions/48673987/trying-to-set-up-entity-framework-core-in-net-standard-project

[escalonn]

Can anyone explain _why_ the dbcontext scaffold command specifically needs to execute any application code? In the common case where the connection string is given directly, all the information needed to reverse engineer is provided in command-line options. You need the provider assembly but what possible use are the application assemblies?

There shouldn't be any need to fix compile errors to run scaffold, much less create a dummy startup project.

[bricelam]

We execute user code to discover design-time services (e.g. an IPluralizer). If you've successfully built once, you can skip building with --no-build. This is currently a hidden option, but we have an item on our backlog to document it and add it to --help.

[bricelam]

@escalonn You can also use the EF Core Power Tools which don't require your project to build (but you won't be able to override services)

[ErikEJ]

@escalonn But you can enable and disable services via the options on the tool 😎

[escalonn]

We execute user code to discover design-time services (e.g. an IPluralizer). If you've successfully built once, you can skip building with --no-build. This is currently a hidden option, but we have an item on our backlog to document it and add it to --help.

@bricelam is there any documentation about any aspect of design time services besides this? EF Core docs are really in an awful state even after all these years.

@ErikEJ do you mean the Power Tools tool? or the EF Core tool?

[ErikEJ]

I mean in Power Tools...