I'm using EntityFramework 6 in VS2013 with database-first. When you pull in the database, you can get stored procedures, which builds methods into your context for each proc, as well as classes for each of the return types which it derives from the procedures.
I'm looking for a way to run this from the command line. The closest I can find is EdmGen, but this apparently does only tables.
I've seen EfGen, but aside from this just being a download from some guy with no source code or peer review, it appears to be at least one version behind.
Building the names and parameters of the methods is easy enough - I could do that myself with the SQL Server metadata - however, building the result classes would be tricker, so ideally I'd like to do whatever VS is doing.
Is there an SDK command or something I can pull from Visual Studio to do this on demand? I often have to re-pull my procs (early in the development process so things are constantly changing), and it's a hassle to do it in the UI.
I don't think what you are trying to do is possible from the command line. As you noticed in the EF6 Designer there is no public API for reverse engineering similar to the one exposed by EdmGen. The lack of the API is not actually the biggest problem here - in general models generated by EdmGen and the new designer are semantically the same - the only difference is that in EF6 two new provider manifest tokens were introduced for SqlServer - 2012 for Sql Server 2012 and 2012.Azure for Sql Azure. You will get these provider manifest tokens when targeting the above databases with the new designer but when using EdmGen you will get 2008. The actual problem here (and the reason why EdmGen does not support generating/importing store functions) is that in the EF provider model there is no way to get the description of the results returned by a store function. To make up for this the designer uses the DDEX provider which is able to return the description of the first result set (now, you also know why the EF Designer does not support stored procedures returning multiple resultsets even though it is supported by the runtime) returned by a store function. Since DDEX is basically a VS thing I don't think you will be able to import store functions from command line using out-of-the-box tooling.
Related
It is well known that perfomance wise, it is recommended to use SQL Server stored procedures instead of inline code. However, I still use inline SQL queries in Visual Studio for various reasons:
The queries can be neatly organized in separate text files (.sql) and in a folder structure.
The files are part of the Visual Studio solution and thus submitted to source control.
Changes to SQL queries can be published together with the applications (using WebDeploy for ASP.NET apps or ClickOnce for Windows apps).
There is no need to synchronize changes to the SQL queries and publishing new versions of applications.
It enables me to work on the SQL queries even when I am offline (or without access to that particular SQL Server).
I am not quite ready to give up these advantages but still, I am aware that I am sacrificing performance.
Is there a way to get the best of both worlds?
Thanks in advance for any insights.
Chris
Literally every single one of your points can be provided by Stored Procedures too... Not only could you just have a .sql file with the CREATE or ALTER command for the stored procedure in the exact same way you manage it now, but you could go a step further and use a SQL Database Project type to deploy them in a better manner...
https://msdn.microsoft.com/en-us/library/xee70aty(v=vs.140).aspx
But I will note that stored procedures are not automatically better for performance... If you read this is probably refered to the fact that they are easier to parameterize, so the plans can be resued. Using proper Parameterized queries you will have the same benefits, so I think the basic premise of your question is incorrect.
I still use inline SQL queries in Visual Studio ...
But how? Context is important here. VS is just a tool. If you use inline queries in your app, then you have a potential security risk if you are not careful about how you implement them (re: sql injection). In addition, the use of inline queries requires the appropriate permissions to database objects - another security risk. And this approach creates a dependency between your code and the schema - which is minimized by using procedures.
I am posting this thread because I didn't find any easy way to abstract my db requests like LinQ does, allowing my program to alter dynamically the database, creating tables or fields.
I am using .NET framework 4.0 and SQL Server 2012, on windows.
I have seen a lot of topics on ORMs such as Entity Framework that allows to run migrations on the db at runtime, only they can't be generated at runtime.
For now, my project creates table at runtime by executing hard-coded SQL Server scripts.
Only, I dont want to use specifically SQLServer, I want to use some generic language that generates a script for the right DBMS according to my c# code.
Example :
I want to alter my data design at runtime because my program is actually running on several machines that have their own database.
When I update the program I would like it to create new tables that are used by the new functionnalities.
Let's say I am adding... a QCM for the user.
I have a winform that allows the user to see the questions and answer it.
Now to keep track of the answers, I want my program to create a new table using Linq and then fill it with the answers.
If I understand well, when using Entity Framework with code-first approach :
I would have to use the packet manager console to Add migrations on every machine, before running :
var migrator = new DbMigrator(configuration);
migrator.Update();
Or is there a way to send to the machine a migration file that will updated with migrator.Update(); ?
It sounds like you want to do something that is not a good fit for for EF (or virtually any ORM for that matter). ORM's are generally designed to map a static data model to a static object model.
While it's not impossible to do what you want, it would require a very deep understanding of EF and it's implementation details, to use the lower-level functions as well as Dynamic Linq. Then you'd have to map this to dynamic C# objects that can change at runtime.
Frankly, you're probably better off writing a custom data layer yourself using standard SQLCommand statements.
As far as migrations go, this is generally a development/deployment tool, not a runtime tool.
The SqlCommand class in .net allows direct access to the database, including the execution of arbitrary scripts. This will allow you to send any valid database instruction script to the database, including schema definition scripts. This will allow you to create, define, backup, restore and destroy databases.
Our project is using EF code first approach, and it has quite a few stored proc.
Currently we generate DbMigration code like this
var scripts = StoredProcedureMigrationHelper.GetSqlBatchFromEmbeddedResource("myStoredProc.sql");
foreach (var script in scripts)
{
Sql(script);
}
The problem with this is that every time when I update the stored proc, I have to create new sql file, with name convention like "myStroedProc_versionX". Which is working but lose the version control benefit such as show the difference between versions.
Is there a way / different approach to update stored proc with version control in code first?
A more robust and flexible approach could be to use EF database first and to model your database using Sql Server Data Tools (SSDT). By creating Database project in your solution, you could build a dacpac and apply it on SQL Server instance to update your schema to the desired state.
Disclaimer: I'm a product manager at Redgate Software, makers of ReadyRoll
If you have Visual Studio 2017 Enterprise, which ships with ReadyRoll Core edition, you can switch to using SQL-based migrations for your database deployments. This would allow you to include the deployment of your stored procedures alongside your schema changes, while still allowing you to use EF CodeFirst to do your modelling.
You can read more about this approach in the ReadyRoll documentation:
https://documentation.red-gate.com/display/RR1/Tutorial%3A+Entity+Framework+CodeFirst+migrations
Note that the article makes use of the programmable objects feature of ReadyRoll, which is only included in the Pro edition of ReadyRoll. As an alternative, you could script your stored procedures as post-deployment scripts (although this will cause the scripts to run with every deployment, rather than just on each change).
Unfortunately, EF doesn't provide a native solution for that, but I found a solution and I explain it in this post: https://softcadbury.github.io/dotnet/entity-framework/2022/05/10/versionize-stored-procedures-with-entity-framework.html
The idea is to embark the SQL code of your SQL stored procedures in your solution (works also with SQL views or SQL functions) and with a few C# extensions, you can manage them in EF migrations.
I'm developing an application, in part to learn new technologies - in this instance Entity Framework.
I'm using .NET 4.5, Visual Studio 2013. I need some way to store data that doesn't involve running an SQL server on my tired old laptop (not even the lightweight one) and works with Entity Framework. Ideally I would like something that just stores data in a file. I have a few basic requirements:
A simple relational database. Max 10 tables, this is a prototype, so
the tables won't get very big
Ability to design the database in some
sort of GUI tool
Ability to generate Entity Framework database model
from the DB. I don't want to type those in manually.
No proprietary software other than what I'm already using - i.e. I don't own a MS Access license
Something that ACTUALLY
WORKS
I've spent the better part of today trying to get VS2013 to connect me to an SQLite database that I've created. I never got anywhere. SQLite is simply not listed among the available types of data sources. I've read StackOverflow posts about this issue, I'm done trying to make it work. (this is where the frustration you can sense in this post stems from - this is SO not the point of the exercise, yet I've wasted so much time with it)
Is there any other file based database technology I could use?
Your needs are not compatible, the best choice is SQLite but you can not generate model from database and must use EF as CodeFirst .
and your problem with SQLite can easily fixed by using correct provider and configuration : http://www.bricelam.net/2012/10/entity-framework-on-sqlite.html
I suggest you use SQL Server Compact in combination with my free SQL Server Compact Toolbox VS extension:
A simple relational database. Max 10 tables, this is a prototype, so the tables won't get very big
SQL CE supports all standard relational paradigms, and has a max database size of 4 GB
Ability to design the database in some sort of GUI tool
The extension allows you to do this in Visual Studio
Ability to generate Entity Framework database model from the DB. I don't want to type those in manually.
Yes, fully supported
No proprietary software other than what I'm already using - i.e. I don't own a MS Access license
SQL Compact is free and freely distributable
In an ASP.NET 4.5 C# Entity Framework 5 Code First project I'd like to log the changes being made in the database at runtime (the logging has to be done in the asp.net app, not at the database). Previously, the SQL statements were built by the code, and those statements were simply logged. Now with EF, the object is retrieved via linq to entities, modified and
db.SaveChanges();
is being called. My first idea was to retrieve the actual SQL statements that EF sends to the DB -- this seems to be rather complex, however. I've found many "solutions" for displaying the SQL during debugging, but no simple way for the code to retrieve it at runtime.
So I'm looking for any solution that can log the changes being made (either the SQL being sent to the DB [preferred], or some other form of textual representation of the changes made to the object), and that doesn't require the inclusion of a number of complex debug libraries.
You should try FrameLog
https://bitbucket.org/MartinEden/framelog/wiki/Home
It is not clearly stated but it supports Entity Framework 5
I haven't tested this on EF 4.5 so it may need to be tweaked a bit, but I find for debugging purposes the extension method written at the bottom of this post:
http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/2a50ffd2-ed73-411d-82bc-c9c564623cb4/
Gives me the correct output of my entities.SaveChanges() call. It doesn't require any external libraries and since it's written as an extension method it won't clog up your code.