Efcore: Feature Request: EF tools and SSDT integration

[Piggy69]

Integrating the SSDT database design tools with the new EF would be a great productivity enhancement for both teams and individual developers working on the "data side".
This will allow developers to design and implement databases with the most advanced and optimized techniques with the SSDT, having the results immediately available to the data access layer without any intermediate step.
I believe this would greatly enhance productivity of Visual Studio Users and - on the other side - leverage the value of both the SSDT and EF projects, allowing to benefit from both the integration of the SQL advanced development (which is not possible with automatictemplate translations) and the power of the Entity Framework, all integrated into the same IDE and environment.

[rowanmiller]

We agree that we could do something in this area, at least making it nice in the UI to create a model from an SSDT project.

[japj]

What would be needed to get progress on this item?
Are there parts of it that can be done by the community?

[CodeAngry]

I second @japj's question. This seamless integration really needs to happen.

[ErikEJ]

@japi & @codeangry & @Piggy69 - could you do some design specification, so the communtiy could consider if this was feasible and know the scope of it? Would a feature to scaffold a DbContext in a project based on a SDDT project in the same solution be a start?

[japi]

Sorry, I'm the wrong person :) @japj is who you're looking for. But that's a nice coincidence, since i just had a Call open at MS because of bad EF DB performance over network. We did not find a solution, but could work around by implementing multithreading... So I wish you good luck with this feature request! Every improvement counts :)

[fargs]

I was hoping this would be available as well. I would expect something like this:

dnx ef dbcontext scaffold "C:\Repos\Project\src\database\database.sqlproj" EntityFramework.SqlServer

or even better would be a relative path from my asp.net project.

dnx ef dbcontext scaffold "..\database\database.sqlproj" EntityFramework.SqlServer

[ErikEJ]

I have reverted on the feasability of this. You can just deploy the dacpac from the command line (or via VS) http://stackoverflow.com/questions/8371879/deploy-sql-server-database-project-via-command-line and then run scaffold command after

[mklemarczyk]

This need a tools for Visual Studio 2015. Last version EF tools is v6 for Visual Studio 2012 and Visual Studio 2013.

[ErikEJ]

@mklemarczyk The latest (6.1.3) Tools are included with VS 2015

[mharisko]

When will you guys going to work on this?

[rowanmiller]

@mharisko this isn't going to be something we tackle in the near future as there are a lot of higher priority features ahead of it. BTW for folks that want to maintain a database in SSDT, it is currently possible to do that and generate the EF model from the database.

[syndicatedshannon]

This feature is very important to me.

1. We need type-safe correlation between our schema single-point-of-truth and our code.
2. We must get immediate build failure when our correlated schema does not support our code.
3. Our schema must be stored in a language capable of fully expressing the fundamental immutable relational aspects of our business logic that are best-expressed as data-bound. Unless you are asking us to abandon SQL Server, that will mean business-specialized constraints and indexed views in nearly every application. In some scenarios, stored procedures and other elements poorly expressed via SQL strings in code are also important.
4. We must permit data specialists to maintain data schema, and not demand conflation of all areas of expertise into single team members that are hard to find and fairly compensate.
5. We need a mostly continuous experience with minimal build, integration, and release engineering working through multiple technologies in our IDE (currently Visual Studio). Our team should not have to write custom tooling and individual developers should not have to manually run multiple build and build verification steps.

I'm sad to see a "propose-close" tag on this issue/feature that was previously deemed important and easily doable. The removal of the concept of a neutral model makes database-first development more critical than ever. It's needs to be bolstered, not dropped.

If you want more information about the relevance of this to my business, so you can either understand the broader importance or suggest workarounds, let me know.

[bricelam]

I'm sad to see a "propose-close" tag on this issue/feature

Our team members may have gotten a bit aggressive with the propose-close tag. Don't panic yet. All it means is that we're going to take a second look at some of the older issues on our backlog and decided as a team whether it should remain on the backlog or be closed.

[syndicatedshannon]

What I'd most like to see are two items:

1. Technique to automatically generate (update preferred) the EF model from a SQL Server Database Project schema on changes, or a simple trigger to make this happen. This would provide early defect detection in DB-First environments using SSDT projects. On a side note here, it seems a wise investment for MS teams (EF, SSDT) to collaborate to encourage using MS products end-to-end.
2. Best-practice guidance on performing correlated schema and software upgrades/deployments in DB-First scenarios. I'm not expecting new tooling to accomplish this, but I am expecting for it not to become harder each day. Without defining this guidance, I feel the EF Team is drifting farther from enterprise-ready SQL support, and doesn't have visibility to the corner they are getting backed into with Code-First-centric tooling.

Regarding 2. above, @rowanmiller mentioned the issue of performing schema upgrades here: https://github.com/aspnet/EntityFrameworkCore/issues/4321#issue-126931959 . It's fundamentally different, but it still needs to have a viable strategy. IMO it's a loosely-coupled EF concern, but not something that can be disregarded.

I'm not asking for magical bi-directional capabilities (although at one point EF6 was almost there before it buckled under its own weight ;) ). I just want better support for critical relational features, such as supporting a database with business-specialized relationships.

[ErikEJ]

For anyone following this: EF Core Power Tools allows you to scaffold a Model directly from a SSDT project, without any intermediate "live" database: https://github.com/ErikEJ/EFCorePowerTools/wiki/Reverse-Engineering

[ErikEJ]

There is also now a NuGet package to do this: https://www.nuget.org/packages/ErikEJ.EntityFrameworkCore.SqlServer.Dacpac