Tag: ICT

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:

At Microsoft Build 2018, a number of Azure App Service on Linux enhancements were announced. One that I was interested in was this one: Remote debugging, in public preview: You can now choose to remote debug your Node.JS applications running on App Service on Linux. Sweet! But… how? The blog post did not mention a lot of details on the debugging part, so let’s walk through it, shall we? Remote debugging of Node.js apps on Azure App Service from WebStorm! First of all, we will need a number of things on our machine: The latest version of the Azure CLI 2.0

I have decided to retire from the Microsoft MVP program. In the first week of April, an e-mail from Microsoft landed in my mailbox. I was given the choice to either remain an active MVP (but without access to NDA content) until my next renewal period, or retire from the program.