Tag: General

I know, I know. That title is probably a bit too harsh and opinionated. But it got your attention, right? A friend of mine this week asked me whether they could use middleware in their HTTP-triggered Azure Functions, ideally even the same ones they use in ASP.NET Core applications. After all, the SDK comes with HTTP triggers that seem to use the same infrastructure, right? My immediate response was “whyyyyyy?!?”. And in this blog post, I’ll try to explain. via GIPHY

In 2013, I was asked to be part of a conference agenda committee. Since, I have been part of a couple more, for conferences in different parts of the world. Being “on the other side” of a Call for Papers has been very interesting, and taught me that this is a difficult job. There’s lots of reading, discussion, re-reading and more discussion involved. At some point there comes the rewarding bit of accepting sessions to the agenda, and the part I hate the most: having to reject sessions.

In an application I’m writing, I need to deserialize some JSON. I know the class to use is JsonConvert, but which NuGet package was that type in again? Granted, that’s an obvious one. Yet, there are many uses for a “NuGet reverse package search” that helps finding the correct NuGet package based on a public type.

Usually on my development machine, I run ASP.NET Core applications in Kestrel. It’s easy to do, the project templates .NET Core provide create a nice launchSettings.json to start it from the command line, etc. However, I was asked to help someone out with hosting ASP.NET Core in IIS Express. Great! The default launchSettings.json contain an entry for that as well, so I ran dotnet run --launch-profile "IIS Express".

We all know it’s important to prevent Cross-Site Request Forgery (CSRF) attacks against our application. Unfortunately, our inherited code base has zero measures implemented - not one action methods with a [ValidateAntiForgeryToken] attribute in sight!

As discussed in the previous post, we all know it is important to perform validations to prevent a Cross-Site Request Forgery (CSRF) attack against our application. Imagine inheriting a code base that has zero measures implemented? How would you find which action methods need a [ValidateAntiForgeryToken]? Today, we will look at using ReSharper to find all action methods that need [ValidateAntiForgeryToken] added. In this series:

As ASP.NET MVC developers, whether ASP.NET MVC 5 or ASP.NET MVC Core, we all know it is important to perform certain validations to prevent a Cross-Site Request Forgery (CSRF) attack against the application we are building. The ASP.NET MVC provides the @Html.AntiForgeryToken() helper which we can use to add a hidden field in the form we are posting, and a [ValidateAntiForgeryToken] attribute which we can decorate our action method with and instructs the framework to validate the posted token is valid (or was forged).

While I am a big fan of Autofac to serve as the framework for making Inversion of Control (IoC) and Dependency Injection (DI) work in an application, it is quite convenient in simple projects to use the built-in dependency injection in ASP.NET Core. While simple to replace the default one with Autofac, the default one is often sufficient. Unless it’s not! Consider the following component registration: With the default Microsoft.Extensions.DependencyInjection package in ASP.NET Core, we can now consume an ICustomerService in, for example, our controllers:

Yes, it’s 2018, us IT folks have probably been working remote for quite a while (full-time or occasionally), but there are other industries where these things take time. Not to mention that in countries like Belgium, remote work also has to be arranged for in employment contracts or ancillary documents. But anyway, I digress.

Recently, someone asked me to look at their ASP.NET MVC application and help figure out why a certain request was taking 16 seconds to complete. It’s always fun to look at those things, so I could not pass on this nerd snipe. Much like with hunting serial killers, you have to become one with the scene at hand. Watch the crime scene. Look at the things that happen, and observe. How can you observe a web application? The browser is a good start. Since this specific call was returning JSON data, I thought it easier to look at it in Fiddler instead. A typical response looked like this: