World of coding

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

EF Core 2.0 changed the way the CLI looks for the DBContext to use. There are now two ways: Invoke BuildWebHost in Startup.cs Use the class implementing IDesignTimeDbContextFactory<T> BuildWebHost is called even if a class implements IDesignTimeDbContextFactory<T>. Solution for this problem: Rename BuildWebHost to e.g. _BuildWebHost (making it private isn’t enough). Next step: create the class DesignTimeDbContextFactory : public class DesignTimeDbContextFactory : IDesignTimeDbContextFactory<ApplicationDbContext> { public ApplicationDbContext CreateDbContext(string[] args)    {     IConfigurationRoot configuration = new ConfigurationBuilder()           .SetBasePath(Directory.GetCurrentDirectory())           .AddJsonFile("appsettings.json")           .Build();       var builder = new DbContextOptionsBuilder<ApplicationDbContext>();       var connectionString = configuration.GetConnectionString("DefaultConnection");       builder.UseSqlSe

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

I was looking for a convenient way to publish my ASP.NET Core application, but soon I saw that it wasn't that easy. The worst problem is that dnu publish will publish all files in the wwwroot folder with no possibility to filter these files because you can't publishExclude files and folders in the wwwroot folder. So I came up with a solution which keeps all files out of the wwwroot directory, using gulp to compile Typescript and Sass files and copy css and javascript during development and preparing them for production. I created a GitHub repository with a working example which you can customize to fit your needs. I added an detailed readme with all informations you need which will be updated too if I add new task or improve the existing ones.

Microsoft just released ASP.NET 5 and Entity Framework Beta 8. There were some breaking changes which require some changes in existing code. All changes can be found here: Announcing Availability of ASP.NET 5 Beta8 As with every upgrade you should change the -beta7 to -beta8 in the global.json and in all package.json files. Below I address the things I found which need to be corrected: Package.json Remove these dependencies: "Microsoft.AspNet.Server.IIS": "1.0.0-beta7" "Microsoft.AspNet.Server.WebListener": "1.0.0-beta7" and replace them with: "Microsoft.AspNet.IISPlatformHandler": "1.0.0-beta8" "Microsoft.AspNet.Server.Kestrel": "1.0.0-beta8" Finally add this one: "Microsoft.Framework.Logging.Debug" : "1.0.0-beta8" Now change the web command "web": "Microsoft.AspNet.Hosting --config hosting.ini" to "web": "Microsoft.AspNet.S

So I wanted to mock the interface I use as base for my data context in my unit tests. Mocking the interface itself is pretty easy, but I wanted to check if the properties of type DbSet have changed correctly. So, all we need to do is mock the methods of the DbSet we are using, e.g. Add() and AddRange(), and use a callback to send the value of the method calls to a List . As you can see, the method calls to a DbSet can easily be captured and send to another List which we can use for our asserts.

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 V iew  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 backsla