Dog Fooding the Web Connection .NET Core Middleware on the Message Board

Dog Fooding the Web Connection .NET Core Middleware on the Message Board
Rick Strahl
All

Apr 6, 2020 @ 06:03pm

Hi all,

Just a quick heads up - I switched this message board application over to run on the new Web Connection .NET Core Middleware today. The site is now running Web Connection using this new hosting mechanism and it's working great:

It's only been a few hours at this point, but the app is running stable and there were no hiccups in moving it over to this new hosting mechanism.

The process is pretty straight forward:

Make sure the .NET Core 3.x Hosting Bundle is installed (on a server, SDK on a local machine)
Update the web.config to the .NET Core specific configuration

The .NET Core middleware uses a separate configuration file for settings in WebConnectionWebServer.xml which mirror the old web.config settings, but the separate configuration makes it a little cleaner because all the settings are isolated in one place.

<?xml version="1.0" encoding="utf-8"?>
<WebConnectionWebServerSettings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <HandledExtensions>.wwt,.wc,.wcs,.wcsx</HandledExtensions>
   <DefaultFiles>threads.wwt</DefaultFiles>
   <VirtualDirectory>/</VirtualDirectory>
   <MessagingMechanism>File</MessagingMechanism>
   <ServerCount>2</ServerCount>
   <AutoStartServers>false</AutoStartServers>
   <ComServerProgId>wwThreads.wwThreadsServer</ComServerProgId>
   <ComServerLoadingMode>LoadBased</ComServerLoadingMode>
   <UseStaComServers>false</UseStaComServers>
   <TempPath>~\..\deploy\temp\</TempPath>
   <TempFilePrefix>WC_</TempFilePrefix>
   <Timeout>90</Timeout>
   <AdminAccount>ANY</AdminAccount>
   <AdminPage>~/admin/admin.html</AdminPage>
   <ExeFile>~\..\deploy\Wwthreads.exe</ExeFile>
   <UpdateFile>~\..\deploy\Wwthreads_Update.exe</UpdateFile>
   <UseLiveReload>true</UseLiveReload>
   <LiveReloadExtensions>.wwt,.wc,.wcs,.html,.htm,.css,.js,ts</LiveReloadExtensions>
   <LogDetail>false</LogDetail>
   <MessageDisplayFooter>Generated by Web Connection IIS .NET Connector Module</MessageDisplayFooter>
</WebConnectionWebServerSettings>

It's also possible to import existing settings from web.config by running the middleware server as a standalone while an existing web.config is in place - and it'll automatically import the settings into the new format. Typically you'll do this during development.

The web.config configuration is completely boilerplate and is going to be pretty much exactly the same for all applications save custom overrides for default page handling, permissions or request limits:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <!-- this is the only REQUIRED handler -->
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
    </handlers>
    <!-- check the path to the dll - in Project the below works   
         in a plain publish output use `.\WebConnectionWebServer.dll`  -->
    <aspNetCore processPath="dotnet" arguments="..\WebConnectionWebServer\WebConnectionWebServer.dll" 
                stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" 
                hostingModel="inprocess">
      <environmentVariables> 
        <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Production" />
        <environmentVariable name="WEBCONNECTION_USELIVERELOAD" value="False" />
        <environmentVariable name="WEBCONNECTION_OPENBROWSER" value="False" />
        <environmentVariable name="WEBCONNECTION_SHOWURLS" value="False" />
      </environmentVariables>
    </aspNetCore>
  </system.webServer>
</configuration>

In short, this is my first live application trial run and the message board is always a good benchmark as it's a reasonably busy application that's running with multiple COM server instances. Between robots crawling, search traffic and people browsing messages the message board receives well over 100,000 Web Connection requests a day which is a decent representation of a medium sized application.

Goals and Reasons

It's interesting that when I initially built this middleware my main goal was to build an easier local server solution that would make it much easier to get started with Web Connection as well as provide the ability to host Web Connection on a local network without requiring an external Web Server.

But the more I've built out in this .NET Core server the more I think this could eventually become the end to end solution for Web Connection as the middleware can be hosted the in much the same way as the class ASP.NET module was hosted.

Just to be clear:

This new Middleware, the ASP.NET Web Connection Handler and the old ISAPI Handler are all 100% interchangeable with each other. While I am no longer updating the ISAPI handler, the ASP.NET Handler and .NET Core middleware share basically the same code base, so those two will continue to be updated in parallel.

Is the Middleware better than the Handler?

The short answer is - no. There's no big operational benefit you get from running the Middleware over the ASP.NET handler. Performance between the two seem to be on par and application stability so far seems to be the same.

The main advantage of the Middleware is that it provides a very easy to run local Web Server that is portable. This makes local development much, much easier to get started with - you basically run an EXE.

You can then use the exact same Web Server to host the application on a live server in IIS. While the middleware and handler are 99% compatible (there are some very minor and insignificant differences in the Request data provided) running the same middleware that you're running during development in production is something that is comforting.

Note - there will still be some differences between local and 'hosted' operation in IIS, but if you need to test for that locally you can also run the middleware locally in IIS.

Summary

In short I'm somewhat excited to see this all working. The work that went into the Middleware ended up improving many features like LiveReload functionality, the Administration page behavior and links, and many small subtle improvements in request processing both for the .NET Core middleware as well as for the ASP.NET Handler which has been backported with many of the improvements.

So check it out and let me know if you run into any issue on the site in the next few days. I'll be monitoring the logs and admin to see how things fare. So far I see no issues and the same great performance we've been used to with Web Connection applications.

Aloha,

+++ Rick ---