Cannot Create Database with credentials using Entity Framework Code-First?

Question

I'm a bit new to code-first approach but I used Database first approach before using entity framework, now I want to work with code first instead and its kinda a habit.

I started creating models and its all good, then enabled migrations and add-migration as well and all works well, but when I run Update-Database command I get an error.

Hence I want to create a database with code-first using credentials, after a lot of research I didn't find a solution and mostly tutorials use "Trusted Connection".

What I use

App.Config

  <connectionStrings>
    <add name="CodeFirst" connectionString="Server=.\SQLEXPRESS;Database=CodeFirst;User ID=anyuser;Password=anypassword;"
         providerName="System.Data.SqlClient" />
  </connectionStrings>

DbContext Class

public class CodeFirstContext : DbContext
    {
        public CodeFirstContext() : base("name=CodeFirst")
        {

        }

        public DbSet<Product> Products { get; set; }

        public DbSet<Category> Categories { get; set; }

    }

The Error I get

Login failed for user 'anyuser'.

The question is I did something wrong ? or using credentials can't be done using code-first approach ?

Thanks in advance

Answer 1

OP:

I want to create a database with code-first using credentials ,

...and:

after a lot of research I didn't find a solution and mostly tutorials use "Trusted Connection".

Therein lies the problem with code-first approaches when deploying to a new database using a specific login - it's a chicken and egg because:

1. the database doesn't yet exist
2. the connection string is requesting an explicit login
3. the login does not yet exist in say SQL
4. because the database doesn't exist

OP's config:

<connectionStrings>
    <add name="CodeFirst" 
         connectionString="Server=.\SQLEXPRESS;Database=CodeFirst;User ID=anyuser;Password=anypassword;" 
      ... />
  </connectionStrings>

So what's the solution?

1. Use Integrated Security: this allows you to create the database from scratch from code. However any other logins you may need might have to be created later. However, DB-speaking, it's a bit of a bad practice because you should get into the habbit of having one account for deployment (with just enough rights for deployment) and another for general app access (and no rights for deployment)

2. Create Login First: this allows you to use your specified login however you most likely will need to create a blank database first from SQL before you can create the login. Code-first purists may not like this idea.

The latter does follow DACPAC best practices you should already be familiar with from your time in database-first. Just like how a DACPAC shouldn't be deploying logins and adjusting security neither should code-first. Afterall at the end of the day, databases don't care about whether you use code-first or database-first (under the hood, both probably employ some form of encasulated scripting) but your DB Admin might raise an eyebrow depending on how security is being used.

Are database-first approaches better?

In the theme of don't do that, try this instead , code-first tries to do everything via code and whilst a noble pursuit perhaps isn't realistic. Some things like attempting to create logins perhaps isn't possible as mentioned above.

Meanwhile database-first schema changes are carried out by deploying DACPACs from the database side. Authentication is via the login used to get into SSMS (for example) in the first place. DACPAC deployment doesn't require code, .NET or otherwise.

DACPACs can create and/modify database security including logins but is generally frowned upon.

You might want to re-think code-first. Code-first and EF Migrations hasn't really succeeded as a concept in the real world where you have staged CD environments such as DEV; TEST; UAT and PROD.

I see so many developers using code-first only for deploying to their local database . Once there, they use different means to deploy the changes to other computers including TEST and PROD whether it's TSQL scripts or database backup.

It just seems to be so much effort for something that doesn't even complete the race.