ASP.NET Core Hosting Models with IIS

With the introduction of ASP.NET Core 2.2, ASP.NET team has introduced 2 hosting models when we are hosting the ASP.NET Core application in IIS.

One is In-process and the other is Out-of-process. In-process hosting is made possible with the introduction of aspNetCoreModuleV2 which is a required to host ASP.NET Core applications targeting 2.2 or higher. You will get this once you install .NET Core Runtime & Hosting Bundle which is a prerequisite.

You can configure the hosting model pretty easily through one of the following approaches.

1. Through Project Properties in Visual Studio, Under Debug

Visual Studio

2. From the csproj file

csproj file

If the <AspNetCoreHostingModel> property isn't present in the file, the default value is OutOfProcess.

By doing this when the project is published, the web.config file will contain information on whether to run the application In-Process or Out-of-process.

<aspNetCore processPath="dotnet" arguments=".\HelloWorld.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="InProcess" />

So what’s is In-process and Out-of-process hosting.

In-process

In process basically means the ASP.NET Core application will get run inside IIS Worker process (w3wp.exe) and hence the naming. So here IS HTTP Server (IISHttpServer) is used instead of Kestrel server.

Out-of-process

When on Out-of-process, ASP.NET Core application does not run on IIS Worker process, instead it will be running on Kestrel and all the requests are being forwarded to Kestrel.

So what is preferred and why. In-process is the preferred hosting model in IIS. In-process hosting provides improved performance because requests don’t get proxied over to a separate dotnet process. Microsoft states there is an improved throughput of up to 400% on when In-process hosting model is IIS.

More Information,
Host ASP.NET Core on Windows with IIS

ASP.NET Core Module

Hope this helps.

Happy Coding.

Regards,
Jaliya

ASP.NET Technical Guru - May 2019

Another month as a judge in Microsoft TechNet Guru Awards under ASP.NET category. The TechNet Guru Awards celebrate the technical articles on Microsoft TechNet.

Original Post,

https://social.technet.microsoft.com/wiki/contents/articles/53084.technet-guru-winners-may-2019.aspx

ASP.NET Technical Guru - May 2019  

Happy Coding.

Regards,

Jaliya

Received Microsoft MVP Award in Developer Technologies

I am honored to receive the precious Microsoft Most Valuable Professional (MVP) Award for the sixth consecutive year.

As always looking forward to another great year on top of Microsoft Development Stack.

Microsoft Most Valuable Professional (MVP)

Thank you Microsoft for your appreciation and Thank you everyone for your continuous support.

Happy Coding.

Regards,
Jaliya

Task.Wait() Vs Task.GetAwaiter().GetResult()

In this post, let's go through one of the best practices when using async/await.

In some cases, we might want to run an async method synchronously and wait for the execution to be completed. Let's consider the below code.

static void Main(string[] args)
{
    // 1
    RunSomeTask().Wait();
 
    // 2
    //RunSomeTask().GetAwaiter().GetResult();
}
 
private static async Task RunSomeTask()
{
    // some long running work
}

 So our options to call RunSomeTask synchronously would be something like below,

1. Task.Wait() (or Task.Result to get the return value if it returns something)
2. Task.GetAwaiter().GetResult()

What would you prefer?

So the best practice is, we should be using Task.GetAwaiter().GetResult() instead of Task.Wait()/Task.Result(). Let's see why.

For the purpose of this post, I am modifying the RunSomeTask() method to throw an exception.

private static async Task RunSomeTask()
{
    await Task.Delay(200);
 
    throw new Exception("Failed because of some reason");
}

Now let's have a look at 2 different outputs.

When used Task.Wait():

Task.Wait()

When used Task.GetAwaiter().GetResult():

Task.GetAwaiter().GetResult()

As you can see when used Task.Wait(), if the task threw an exception, it will be wrapped inside an AggregateException. But when we are using Task.GetAwaiter().GetResult(), it will throw the exception directly which will make things like debugging/logging easy.

That's a very simple tip, but can be really useful.

On a final note, we should avoid calling tasks synchronously as much as possible.

Hope this helps.

Happy Coding.

Regards,

Jaliya