Converting a HttpListener to run in IIS

Question

I've heard that there are ways to take a C# app that uses HttpListener and change it such that it will run in IIS but I'm unable to find any concrete references on this. Does anyone have any ideas on the topic that they could share?

Answer 1

I found what I was looking for here: http://support.microsoft.com/kb/308001

Looks like there are only minor code changes that would need to be implemented. Hope this can help someone else, too.

Edit 6/21/19

@Vermin asked if I could find the link, which I could not, but I did find a really old code base of mine with some embarassing code that may at least provide some starting points/directions (hopefully for others too). Please forgive me if I don't provide good clarity on the 'why' behind some of these items (it was a while ago, and I didn't understand it all to the depth I should have).

1) The ServiceContract

[ServiceContract] public interface <svcName> ... 
{
        [OperationContract]
        [WebGet(UriTemplate = "/*", BodyStyle = WebMessageBodyStyle.Bare)]
        Stream MyGetMethod();

        [OperationContract]
        [WebInvoke(Method = "POST", UriTemplate = "/*", BodyStyle = WebMessageBodyStyle.Bare)]
        Stream MyPostMethod(Stream bodyStream);

2) I also had to provide a content mapper (I can't really remember why)

    public class RawContentTypeMapper : WebContentTypeMapper
    {
        public override WebContentFormat GetMessageFormatForContentType(string contentType)
        {
            return WebContentFormat.Raw;
        }
    }

3) Then there was something I needed to do in web.config...

  <system.serviceModel>
    <services>
      <service name="<namespace>.<svcName>" behaviorConfiguration="<behaviorName>">
        <endpoint address="" binding="customBinding" behaviorConfiguration="<behaviorName>" contract="<namespace>.<svcName>" bindingConfiguration="<customBinding>"/>
      </service>
    </services>
    <bindings>
      <customBinding>
        <binding name="<customBinding>">
          <!-- Used for REST.  See http://www.codehosting.net/blog/BlogEngine/post/WebContentFormatRaw-in-your-WCF-config-file.aspx -->
          <!-- Provide the fully qualified name of the WebContentTypeMapper, set max message size to 500MB  -->
          <webMessageEncoding webContentTypeMapperType="<namespace>.RawContentTypeMapper, <namespace>, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
          <httpTransport manualAddressing="true" maxReceivedMessageSize="524288000" transferMode="Buffered" />
        </binding>
      </customBinding>
    </bindings>
    <behaviors>
      <serviceBehaviors>
        <behavior name="<behaviorName>">
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="true"/>
        </behavior>
      </serviceBehaviors>
      <endpointBehaviors>
        <behavior name="<behaviorName>">
          <webHttp helpEnabled="true"/>
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <diagnostics performanceCounters="All"/>
  </system.serviceModel>

I also saw this link in the comments of the project, which may prove useful: http://www.codehosting.net/blog/BlogEngine/post/WebContentFormatRaw-in-your-WCF-config-file

You'll have to forgive me if I can't really explain the 'why' of all of the above. Some of it is easy to understand (mapping the GET, POST methods), some of it I felt like I was just trying things (the web.config stuff).

For some context, I recall the app I was migrating had code to deal with all of the underlying HTTP connections and such, and once I migrated it to IIS using the above, it wasn't that it was terribly fragile, I just felt as though I lost a lot of control without actually understanding the how or the why, and needing to make changes did cause me to feel it was fragile. It's one of the reasons I built Watson Webserver (shameless plug) for quickly building RESTful servers: https://www.nuget.org/packages/Watson/2.0.5