One of the cool things that scriptcs allows you to do, is that you can embed it into your application and allow execution of C# scripts. There are even some great resources on that out there, like this awesome post by Mads.

The same applies to the REPL functionality - you don’t have to use scriptcs.exe to access the REPL - you can use the scriptcs Nuget packages to create a REPL inside your app.

And because there aren’t that many resources (if any) on how to host a scriptcs REPL, today I wanted to show you just that. But for a more interesting twist, we’ll do that inside a DNX application.

There are many reasons why DNX is awesome, and why you’d want to use it, but especially because, through the project.json project system, it has a much improved way of referencing and loading dependencies and Nuget packages - and we can leverage that mechanism to feed assemblies into our REPL.

Because of my considerable community involvement in promoting C# scripting (i.e. here or here), I thought the other day, why not attempt to run C# scripts using DNX?

While out of the box, DNX only compiles proper, traditional C# only, thanks to the compilation hooks it exposes, it is possible to intercept the compilation object prior to it being actually emitted, which allows you to do just about anything - including run C# scripts.

Let’s explore more.

Sometimes you have resources in your code that are implementing IDisposable, and that you’d like them to be disposed only at the end of the HTTP request. I have seen a solution to this problem rolled out by hand in a few code bases in the past - but in fact this feature is already built into Web API, which I don’t think a lot of people are aware of.

Let’s have a quick look.

Let’s have a quick look at another new feature in ASP.NET MVC 6, and that is the ViewComponent feature. View components are intended to be replacements to ChildActions and, to some extent, of partial views.

Traditionally in ASP.NET MVC (and in general in the textbook MVC pattern), you had to compose the entire model in the controller and pass it along to the view, which simply rendered the entire page based on the data from the model. The consequence of this is that the view does not need to explicitly ask for any data - as its sole purpose is to just act upon the model it received.

While this sounds very nice in theory, it has traditionally posed a number of practical difficulties. There are a number of reusable components on pretty much every website - think a menu, a shopping cart, lists of all kinds, breadcrumbs, metadata and so on - so things that appear on multiple pages.

Let’s have a look at how this is solved in MVC 6.

Today, let’s have a look at he area of filters in ASP.NET MVC 6 - because it actually contains quite a few interesting changes compared to classic MVC and Web API filter pipelines.

Let’s leave the specialized filters (error filters, authorization filters) on a side for now, and focus instead on the functional, aspect oriented, filters. Aside from the good old action filters, known from both MVC and from Web API, there are two new types of filters (or rather filter factories, but we’ll get there) that you can use - ServiceFilters and TypeFilters.

The other day I ran into a post by Alex Zeitler, who blogged about integration testing of ASP.NET MVC 6 controllers. Alex has done some great work for the Web API community in the past and I always enjoy his posts.

In this case, Alex suggested using self hosting for that, so spinning up a server and hitting it over HTTP and then shutting down, as part of each test case. Some people have done that in the past with Web API too, but is not an approach I agree with when doing integration testing. If you follow this blog you might have seen my post about testing OWIN apps and Web API apps in memory already.

My main issue with the self-host approach, is that you and up testing the underlying operating system networking stack, the so-called “wire” which is not necessarily something you want to test - given that it will be different anyway in production (especially if you intend to run on IIS). On the other hand, you want to be able to run end-to-end tests quickly anywhere - developer’s machine, integration server or any other place that it might be necessary, and doing it entirely in memory is a great approach.

A while ago I wrote a post about formatters in MVC 6.

Since then, there have been some changes regarding XML handling and an interesting feature that was added recently that was not part of that post, so I think it warranties a follow up. XML formatter is now removed by default. On top of that, MVC 6 will attempt to sniff out whether your request is originating from a browser’s address bar and adjust content negotiation accordingly.

In the past I did a couple of blog posts (here and here) about how ASP.NET Web API discovers controllers.

ASP.NET MVC 6 supports both regular controllers (inheriting from Controller base type) and POCO controllers. Let’s have a look at how the discovery of them happens in ASP.NET MVC 6. Note that the code and mechanisms discussed in this article were introduced after ASP.NET 5 beta3 was released, so it is not yet available if you use the version of ASP.NET 5 bundled with Visual Studio 2015 CTP6.

This is something I hacked together last night, but it was a very interesting exercise into customizing the new (or rather, future) ASP.NET MVC 6 to suit your needs.

If you visit this blog from time to time, some time ago I blogged about building strongly typed routing provider for ASP.NET Web API (code is here). That was built around extensibility points provided by the direct routing mechanism (better known as direct routing’s default implementation - attribute routing).

So I thought, it would be fun to port this solution to MVC 6. However, while MVC 6 supports attribute routing, it does not provide the same abstractions over the routing mechanism. Instead it exposes something new for both MVC and Web API developers - IApplicationModelConvention, which is what we’ll use here.