Develop Reference

c# code first DB migration with stored proc versioning control

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.

FluentMigrator automatic generating the migration c# code

I'm using FluentMigrator to build and update database. But I need to make migration code manually. I would like to have ability generate this based on entities classes like it makes EntityFramework (code-first). Do we have any solution for this functionality? Or maybe you could advise me another migration system?

What you ask for doesn't exist in Fluent Migrator.

Entity Framework DB migration

In my Application I have used Entity Framework Database First approach.
Currently my application is in Dev Environment, now it need to be moved into Test Environment and later into Production Environment.
So is there anyway that I can use .net feature or Entity framework feature to migrate/create database in Test environment. Other than using SQL feature of restoring the database.
Also note that if any enhancement comes then Database structure can change, table schema can change.
So can you suggest me the best way to easily migrate database schema in different environment without losing existing Data.

If you want to take advantage of EF-Migrations feature, you must convert your application to Code First with Existing Database http://msdn.microsoft.com/en-us/data/jj200620.aspx
If you are unable to convert to code first then you must create the update script by hand.
Use a schema compare tool, compare the development and production server.
For each difference found, create an update query.
Once the entire script is finished, test it on the staging server.
Automating the migration is very risky, it depends on the type and size changes you made to the schema. You can't trust any single feature or tool specially if the changes requires data motion (moving data around).
The following links might help you:
How to do Migrations in DB first approach
EF Migrations for Database-first approach?

With Database First, the easiest way to copy a schema is to extract a data tier application in management studio, create an empty database on the target, register it as a data tier application with the same name, and upgrade the empty database using the upgraded file. You can repeat this step to manage schema changes.
Having said that, going forward you're really better off switching your Database First to Code First as it will make change management across your deployments much easier.

Migrations are best way to deal with it
Preferred way to update production db is to first generate sql file and then run the sql file in production environment.
MS had a very good artical on this
http://msdn.microsoft.com/en-in/data/jj591621.aspx#script

Given a database schema, programmatically generate EF source code

We have a project driven by database design. And when someone makes a db modification, I would like to have my EF code updated. So, I was wondering if there is a way to programmatically generate EF source code given a database connection string. I then plan on attaching this generated EF source code to my solution. I don't need an exact solution right now, but if anyone can point me in the right direction, that would be great.
Thanks!

You could query the SQL Server system tables and generate code that way, perhaps using XML and XSLT or T4 templates.
http://msdn.microsoft.com/en-us/library/ms189082(v=sql.105).aspx

There are three approaches to Entity Framework Development: Database First, Model First, and Code First. You are using Database first.
Entity Framework Development Approaches
I recomend Julia Lerman's book Programming Entity Framework 2nd Edition.
The tutorial I've linked to is for Code First but it has a nice introduction to Repository and Unit Of Work Patterns which you will want to know when using any of the three approaches.

How do I verify that my LINQ-to-SQL model matches the database schema?

I am absolutely new to the .NET world, and started with C# on friday. I have some experience with database apps, though.
We will go with LINQ-to-SQL for a medium scale project. I am used to generating my schema from classes and keep track of changes with subversion and equivalents to Ruby's Migrations. There obviously is no easy way to do this with LINQ itself.
So I thought of generating the schema (and do some data access) with Castle Project's ActiveRecord and use Migrator.NET Tarantino or dbdeploy.net for the schema updates. (Any suggestions for this?)
My main question is: How do I verify that my LINQ classes still match the database schema? Does LINQ throw exceptions if the schema does not match? Can I iterate over all the LINQ classes and invoke some verify method?
I already found that sqlmetal is the way to regenerate the classes.
PS: We will use SQL Server (2008 or 2005).

This tool will help sync them, but I'm unsure if it'll show differences...may be of some use though. (:
EDIT: As KristoferA said in his comment, it does support comparisons (: - thanks KristoferA.

As for the:
I am used to generating my schema
from classes and keep track of changes
I just added a DDL generation feature to Huagati DBML/EDMX Tools (ver 1.47, released today). It can generate DDL diff scripts in case you have added things to your Linq-to-SQL designer but not yet added them to the database.