efcore: dotnet ef dbcontext scaffold can't be run on .NETStandard class library projects
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:
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
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 6
- Comments: 30 (16 by maintainers)
Well documented here: https://docs.microsoft.com/en-us/ef/core/miscellaneous/cli/#frameworks
You can use EF Core Power Tools reverse engineering and not be required to install anything in your solution 😁
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
.NETStandardand 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?
@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.
@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.
.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…
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.
you change title for solving. but it was amazing answer! i do with this solution
@bricelam let’s talk about what we can add to the docs, fwlinks, etc.