Posts

Showing posts from 2017

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

Make ‘dotnet ef‘ work with EF Core 2.0

Image
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

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