Creating a basic MVC 6 web application with Entity Framework 7 and xUnit - Part 2

In this blog post we will connect to an actual database, create the tables using the code-first approach and add some initial data. Be aware that migrations seem to be a bit buggy at the moment, but my solution was (at least for me) the most stable one. You can clone the repository with this sample from Github.


1. Creating a database

First, open the sql server object explorer (in the View menu).

I use the default MSSQLLocalDB for this example, but you can use any running SQLServer. Now add a new database to this SQL Server.

Specify a database name and the location where to put the database file.

Finally, we need the connection string for this database. Get to the properties of the newly created database and copy the connection string.



2. Necessary changes before the migrations

Before we can run any migration, we have to set up some things. Create a Config.json in the Sample1 project and add your connection string.
Attention: you have to escape the backslashes (just replace any "\" with "\\").

Update the Startup.cs to use the Config.json file and setup the database.

There seems to be a bug(?) in Beta 4 of EF7 where the DbContext doesn't get set up properly, so we have to change our AspNetDataContext to create a connection using our connection string. As soon as this is fixed, we just have to remove the additional code from this class without having to touch anything else. The parameterless constructor is used by the migrations command and the other one when running the application. When this is fixed, I'll write another blog post about this topic.

Finally, we have to set the Id of our Player class as a key column using the [Key] attribute . Add System.ComponentModel.Annotations to the project.json in the Sample1Data project.

And add the key attribute to the Id property.


3. Running the migrations

Running the migrations is now (hopefully) a simple thing. Use the Package Manager Console and change to the Sample1 directory.

Now run the following commands:

  • dnvm upgrade
  • dnvm use 1.0.0-beta4 -r coreclr -arch x64
  • dnu restore
  • Rebuild your solution
  • dnx . ef migration add initial
  • dnx . ef migration apply

If everything worked without an error, you should now have new tables in your database. All the AspNet* tables are automatically created because we use the IdentityDbContext class as base class for our context.


4. Creating initial data

We want to insert initial data when our application starts. Since EF7 doesn't support Seeds at the moment, we have to do this on our own. Note that EF6 has the AddOrUpdate method on a DbSet which is currently missing in EF7 so we have to do the check ourselves in the InitializeData method.

And call it from the Configure method in our Startup.cs
Note: I added a missing app.UseMvc() which we need in the next chapter.

Using the ActivatorUtilities we can easily create an instance with the context we specified in ConfigureServices. If you now run the application, it will add a Player to the database if it doesn't exist yet.

Comments

Post a Comment

Popular posts from this blog

Debugging Lua scripts in VS Code using MoonSharp

Image
Using MoonSharp as Lua interpreter in a .NET application is quite easy, but the docs lack of a good explanation on how to debug the Lua scripts. MoonSharp provides a Visual Studio Code extension and a .NET package for a debug server. I’m going to show how to implement the server using a simple .NET Core Console application. I won’t explain much about Lua or MoonSharp itself, so I expect you have at least some knowledge on how to use MoonSharp. You can find my demo application on GitHub . Preparing the environment For using MoonSharp, we need to install these NuGet packages: MoonSharp MoonSharp.Debugger.VsCode In VS Code you have to install the MoonSharp Debug extension. Make sure to use the latest VS Code version – in an older version the current line in the debugger wasn’t highlighted. In the launch.json, you have to put the debugServer object inside the configuration. The official documentation is wrong here. Loading the script For this demo, I added just one simple gl
Keep reading

Testing the response body of middleware in ASP.NET Core

Testing custom middleware in ASP.NET Core is very easy (e.g. for the response status code), but it’s a bit tricky if you want to test the response body because DefaultHttpContext uses a Null-Stream for the body and thus is always empty. Creating an implementation of HttpContext is way too much overhead, but you can use a custom Stream object for the response body of DefaultHttpContext . Here is how you do it. // use this memory stream for the response body var responseBodyStream = new MemoryStream(); var context = new DefaultHttpContext(); context.Features.Get<IHttpResponseFeature>().Body = responseBodyStream; var middleware = new MyMiddleware(async (c) => { await Task.Delay(0); }); await middleware.Invoke(context); // reset the position responseBodyStream.Position = 0; // read the body string bodyContent = new StreamReader(context.Response.Body).ReadToEnd();   The trick is to access the IHttpResponseFeature of the DefaultHttpContext and to use a custom MemoryStream
Keep reading