WebSharper.WebApi

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

• NuGet identifier: WebSharper.WebApi
• Git sources at GitHub
• Mercurial sources at Bitbucket
• License
• Issue tracker

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.