DarksideCookie

A while back, I was contacted by the people at Webucator in regards to one of my blog posts. In particular this one… They wanted to know if they could make a video version of it, and of course I said yes! And here it is! Hot off the presses!

So there it is! And they even managed to get my last name more or less correct, which is awesome! So if you are looking for some on-line ASP.NET Training, have a look at their website.

I recently did a blog post about how to get an ASP.NET 5 application to run in a Windows Server container using Docker. However, I kept thinking about that solution, and started wondering if I could add IIS Application Request Routing to the mix as well. What if I could have containers at different ports, and have IIS and ARR routing incoming requests to different ports based on the host for example. And apparently I could. So I decided to write another post about how I got it going.

Disclaimer: There is still some kinks to work out regarding the routing. Right now, I have to manually change the routing to point to the correct container IP every time it is started, as I don’t seem to find a way to assign my containers static IP addresses…

Disclaimer 2: I have no clue about how this is supposed to be done, but this seems to work…

I have once again been tasked with writing a ASP.NET Wep Api action to handle the upload of a file. Or rather a form including a file. And once again, I Googled it looking for good solutions. And once again I got the same code thrown in my face over and over again. It seems to be the only one out there. And it isn’t what I want…

The code I am talking about is the one available at http://www.asp.net/web-api/overview/advanced/sending-html-form-data,-part-2. And if you don’t want to go and read that, the general gist is this

if (!Request.Content.IsMimeMultipartContent())
    throw new HttpResponseException(HttpStatusCode.UnsupportedMediaType);
 
string root = HttpContext.Current.Server.MapPath("~/App_Data");
var provider = new MultipartFormDataStreamProvider(root);
 
await Request.Content.ReadAsMultipartAsync(provider);
 
/* Get files using provider.FileData */

More...

Ok, so this post sprung out of an idea that I have had in my head for a while. I know it will probably be solved better in ASP.NET v.Next, and can probably be solved in a bunch of other ways using only Web API or only MVC, but I wanted to see if I could use both to do it…

So what is IT? Well… In Web API, we have the ability to use content negotiation out of the box. Unfortunately, that content negotiation is, at least by default, based around serializing to XML or JSON. It doesn’t include all the view goodness that MVC has. There is no simple way to ask Web API to return a Razor view… So if I want to have content negotiation to handle both serialized data and views, we need to do some work…

On top of that, my solution would work nicely together with an existing MVC application, making it “easy” to add API features and content negotiation to the existing MVC URLs.

More...

Ok, so straying a bit away from the AngularJS posts I have been doing lately, I want to talk a bit about OWIN. Why? Well, I recently took a look at it, after putting it off WAY too long, and found it to be awesome! And the goal with this post is to explain what it is, why it is cool, and why Microsoft is putting it into ASP.NET MVC projects by default…

But let’s start with “what is OWIN”… Well, OWIN stands for “Open Web Interface for .NET” and you can find more about OWIN as such at http://owin.org/. And now that you are back from that site, you are probably not a whole lot more in tune with what OWIN is, and the reason for that is probably that the site contains very little information. And it contains that little information because OWIN _is_ really that small. It is just a definition of an interface used to decouple the web applications we build, from the servers that are hosting it…

More...