Getting started example does not work

[cmulka]

I get a 'table blog does not exist' error and I verified the table was created correctly in the blogging.db. I've been trying to use sqlite with entity framework and I simply cannot get it to work. Not a fan of EF.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 488629d4-9bd2-42b5-4644-34e3f2baee59
• Version Independent ID: b38b9d14-6bad-12e0-8d2d-24b50bc4977e
• Content: Getting Started - EF Core
• Content Source: entity-framework/core/get-started/overview/first-app.md
• Product: entity-framework
• Technology: entity-framework-core
• GitHub Login: @Rick-Anderson
• Microsoft Alias: avickers

[roji]

The issue here is presumably that the dotnet ef creates the blogging.db at the project root, but the application tries to look for it in its current work directory, which is under bin/Debug/net5.0. @cmulka you can simply change the Data Source parameter to point to the absolute path of your database (e.g. options.UseSqlite(@"Data Source=c:\projects\EFDemo\blogging.db"));

To fix the sample, we should probably just use EnsureDeleted/EnsureCreated - this would also simplify the very first getting started experience (no need for Design, tools, migrations...). If we really want to do migrations in this sample, we could put an absolute path which the user would then need to change.

[ajcvickers]

@roji

To fix the sample, we should probably just use EnsureDeleted/EnsureCreated

It is very much by-design that we don't do this, since it promotes a bad pattern. If the getting started using migrations doesn't work out of the box, then we really need to fix the experience rather than changing the getting started.

[roji]

I would have thought that for initial application prototyping EnsureCreated is fine (after all it does exist), with full-on Migrations coming into play when the application first goes to production (at least that's what I did for my real-world EF app dev). I guess the question is whether we want a completely new user who knows nothing about EF to have to bother with migrations in their very first experience.

Anyway, we can put in an absolute path and instruct the user to modify it - or whatever else you think we should do.

[roji]

@ajcvickers and others, I looked again and dotnet run does in fact run: it's just that Rider suffers from the same issue as VS does, where the program starts up under bin/Debug/net5.0 (dotnet/project-system#3619). I guess it's probably more of an MSBuild issue that also affects Rider. Adding <StartWorkingDirectory> as documented for VS works around the issue for Rider too.

As we seem to have been OK with the VS workaround up to now, I guess this can simply be closed. On the other hand, it does seem like a pretty big wart on the very first getting started, so we can still just change the Sqlite database path to something like C:\blog\blogging.db and instruct the user to tweak that if they want to.

[Rick-Anderson]

Changing => options.UseSqlite("Data Source=blogging.db"); to
=> options.UseSqlite("Data Source=C:\blog\blogging.db"); seems to be a win-win.

In the ASP.NET Core repo, we get lots of question on where the DB is located.

[ErikEJ]

@Rick-Anderson thinking back to SQL CE - exact same challenge!

[roji]

Modified #3079 to specify options.UseSqlite("Data Source=C:\blogging.db").

[roji]

Note that this solves the problem for Windows users, but on Linux and Mac C:\blogging.db is just another relative path, so the same problem exists there (e.g. Rider on Linux).