/websharper.webapi

Wrappers for hosting WebSharper sitelets and remoting components in WebAPI projects

Primary LanguageF#OtherNOASSERTION

WebSharper.WebApi

Wrappers for hosting WebSharper sitelets and remoting components with ASP.NET Web API. It is designed to work with WebSharper 2.5.

Usage

Hosting WebSharper code with ASP.NET Web API has the following purposes:

  1. Using WebSharper in ASP.NET MVC4 projects

  2. Hosting WebSharper as a part an OWIN application, to make it portable between IIS and other containers

ASP.NET MVC4

Follow these steps to get started with ASP.NET MVC4 and WebSharper:

  1. Create an ASP.NET MVC4 project (or use an existing one).

  2. Using NuGet package manager, install the WebSharper.WebApi package. This will also install Microsoft Web API as a dependency.

  3. Create or use an existing WebSharper project defining a Sitelet value.

  4. Configure your application to set up WebSharper.WebApi components on initialization (see below).

OWIN / Standalone Use

Please see the provided example under examples/.

Configuration

For ASP.NET MVC4, all initialization code should be called on Application_Start, for example by placing it in Global.asax:

using System.Web.Http;
using IntelliFactory.WebSharperWebApi;

public class MvcApplication : System.Web.HttpApplication
{
    protected void Application_Start()
    {
        // ...
    }
}

In self-hosted applications, the initialization should be performed before the application starts.

To enable support for WebSharper remoting, which installs server-side handlers to requests generated by calling [<Remote>]-annotated methods from client-side code, do:

RemotingHost.Register(GlobalConfiguration.Configuration);

To host a sitelet, do:

SiteletHost
  .Configure(GlobalConfiguration.Configuration)
  .WithDebug(true)
  .WithServerRootDirectory(Server.MapPath("~"))
  .Register(MyNamespace.MyModule.MySitelet);

You may also specify a URL prefix, for example by doing .WithUrlPrefix("websharper"). The sitelet virutal path space will then be found under ~/websharper.

Sitelet hosting currently uses the router tables, so the order in of registration matters in cases when you have non-WebSharper routers.

  • When registering the sitelet at root position, register other routes before the sitelet registration and make them specific (mycontroller/{action}/{id}, not {controller}/{action}/{id}.

  • When registering the sitelet with an URL prefix, register it before other routes. In this case, other routes can capture arbitrary patterns.