By András Jankó on Tuesday, December 16, 2014 — 0 comments

WebSharper 3.0.3-alpha released Core team

This is our first release of WebSharper 3.0-alpha with a new feature: source mapping. If you enable it on your project, you can see the F# sources in your browser and set breakpoints in it.

Source maps

  • You can enable including source maps and the required source files in a WebSharper assembly, by adding the


    property to your project file.

  • To unpack the source maps in your web project, add this same property to the project file, and

          <mimeMap fileExtension=".fs" mimeType="text/plain" />

    inside the web.config file's <system.webServer> element.

  • It is also recommended to set


    to have source position information inside reflected definitions available for WebSharper. Otherwise only the starting lines of functions can be mapped.

  • Single-Page Application projects are currently not supported.
  • In Google Chrome, you need to check the "Enable JavaScript source maps" setting in Developer Tools Settings.
  • For Internet Explorer, you need to have Windows 8.1 Update 1.
  • websharper.exe also has new flag -sm for source map embedding/unpacking.

Sitelets improvements

  • We added combinators to simplify writing Sitelets for sub-actions and embedding them into Sitelets for wider actions. See issue #307 for more details about these combinators.

WIG improvements

  • Added ObsoleteWithMessage function, with it you can specify a message for the obsolete warning.
By Loïc Denuzière on Monday, December 8, 2014 — 0 comments

News from WebSharper 3.0: NuGet, Visual Studio, Mono, upcoming features and API changes Core team

The community response to the WebSharper 3.0 announcement has been overwhelmingly positive. Thanks to everyone who keeps spreading the word! Here are some news from the front:

  • WebSharper just hit the NuGet repository, together with all the public extensions. Don't forget the -pre flag when running NuGet update, since they are marked as alpha.
  • We also uploaded the first version 3.0 of the Visual Studio extension, together with a few updates to the WebSharper website.
  • Thanks to some updates to IntelliFactory.Build and WebSharper itself, WebSharper 3.0 can now be built from source on Mono. Don't hesitate to try it out and report any issues you might encounter!
  • Work has also started on some API enhancements and simplifications and some new features:

    • We are implementing JavaScript source maps. This feature will allow you to see the original F# code in your browser's debug window, for a much better runtime debugging experience.
    • We are working on enhancing the foreign function interface, in particular regarding higher-order functions. Such functions are currently wrapped at the language interface in a helper that can take arguments either separately (for JavaScript calls) or as a tuple (JavaScript array, for F# calls); but this causes problems eg. with functions taking a single array as argument. We are still exploring solutions.
    • The branch js-stdlib-merge contains a simplification of the bindings for the standard JavaScript library. The gist of it is that everything that is built in the browser is currently spread between no less than five namespaces and modules; this change moves all of it into IntelliFactory.WebSharper.JavaScript. More detail in this commit message.
    • We are looking to rename the namespaces IntelliFactory.Html and IntelliFactory.WebSharper.Html to something more explicit. Many developers have been confused by this naming because the difference is not obvious: the former is for server-side markup, while the latter is for client-side markup. The server-side markup will probably be renamed to IntelliFactory.WebSharper.Sitelets.Html; we haven't yet decided a name for the client-side markup.
    • More enhancements will be coming; we hope to have the bulk of the breaking changes in before the end of the year.

Happy coding!

By Loïc Denuzière on Saturday, December 6, 2014 — 0 comments

WebSharper migration to GitHub complete! Core team

When we announced WebSharper 3.0 on Wednesday, we also mentioned that we would be migrating from BitBucket to GitHub. Well, this is now done!

Here is the new main repository for WebSharper. All tickets from the BitBucket tracker have also been migrated (apologies to everyone whose mailbox has been spammed by this!), and are available at this address. Finally, public extensions have been transferred too (for those that weren't already GitHub-based), and are listed under the IntelliFactory organization.

We eagerly await your suggestions, bug reports and pull requests on our new repositories!

By Adam Granicz on Wednesday, December 3, 2014 — 6 comments

WebSharper 3 alpha now under Apache 2 Core team

We are super excited to announce that as of the very latest 3.0-alpha commit, WebSharper is now available under the Apache 2.0 license, free of charge to anyone, for both closed and open source applications!

Over the years, WebSharper grew from an experiment in F# web development into a mature, enterprise-grade F# web framework and helped a multitude of organizations benefit from its type-safe, functional constructs and its powerful F# to JavaScript translation engine. From early on in its development, our main focus was establishing sound abstractions around common web patterns and chores, from simple representations of client-side content, through type-safe, composable, declarative ways of specifying user interfaces, to representing even entire applications in the type system. Some of these abstractions are the result of years of hard work and research, and are distilled into peer-reviewed academic papers, a good set of online documentation and samples, and several book chapters, among others, and make WebSharper a truly innovative, robust, bleeding edge web framework for the serious enterprise web and mobile developer and also for the academically curious researcher.

It is this fundamental power, elegance of expression, and unparalleled productivity that in our humble opinion deserves more attention and widespread use, and this is a great motivation for us going Apache. We have grand and ambitious plans to take WebSharper to places we could never foresee before.

During the past few months and before, we received overwhelming community feedback confirming that there is an ever-growing need for going beyond ordinary web development and continuing to push the boundaries of robust functional web development with WebSharper. Community feedback also confirmed that we are now ready to take WebSharper to the next level and bring it to a much wider audience via a less restricted license.

What does this mean to existing users? First of all, existing license holders continue to be able to use the 2.X releases for closed source applications as before, and they are also welcome to update to the 3.0-alpha line at their convenience. We are now aiming to deliver a set of systematic API updates as part of the 3.X feature set, and many such changes will be breaking changes and new features. If, for whatever reason, you prefer to use the 2.X line, feel free to contact us for licensing. However, we recommend that new users start with the upcoming 3.X releases, despite possible API changes (flagged as pre-release or alpha for the time being, with our aim to deliver most of these changes by the end of this year).

At the same time of going Apache, we will also be offering dedicated support for WebSharper, a new level of service for enterprise users and groups. We will announce plans and related information on this blog shortly. Similarly, premium tooling built for enterprise ex-license holders will now be available on separate subscriptions, with existing license holders enjoying uninterrupted access.

Incidentally, today is also the birthday of one of our main WebSharper team members, Happy Birthday Loic! This is also a great time to say thanks to all those dozens of people who contributed to the development over the years – thanks everyone!

All in all, we can’t wait to hear how far WebSharper can take you in your web development efforts! These are exciting times for both F# +WebSharper and the entire community, and we hope you take this opportunity learn more about WebSharper and fall in love with it like we did.

And last - keep an eye on NuGet: the first set of 3.0-alpha binaries should arrive there tomorrow, and be sure to turn on the “Include pre-release” flag when updating.

Happy coding!

By András Jankó on Tuesday, December 2, 2014 — 0 comments

WebSharper 2.5.134 released Core team

A lot of useful functions of FSharp.Core are now translatable by WebSharper.

Async cancellation

  • Proxies for CancellationTokenSource, CancellationToken, CancellationTokenRegistration.
  • Proxies for Async class members: DefaultCancellationToken, CancelDefaultToken, CancellationToken, OnCancel, TryCancelled
  • Async RPC calls are cancellable, the cancel continuation runs ASAP and the response are discarded.


  • Proxy handles timeout arguments and cancellation
  • PostAndReply/TryPostAndReply methods are not supported as JS is single-threaded.


  • Proxies for sprintf, printfn, failwithf, Printf.kbprintf
  • %O uses JavaScript String(x) function
  • %A generates a recursive pretty-printer for F# types if type information is available. Currently supports lists, unions, tuples, records, 1 and 2 dimensional arrays. Other types are sent to a dynamic pretty-printer.
  • printfn prints to JavaScript console
  • Printf.sprintf is not supported, use ExtraTopLevelOperators.sprintf instead.
  • Printing as unsigned is not supported.


  • Fix #300: Server-side runtime error in some regional settings (for example Turkish)
  • Fix #304: Converting string to char checks string length now
  • Async.FromContinuations ensures that continuation is called only once, throws an error otherwise.

Breaking changes

  • System.Web.HttpPostedFile type in Sitelets API have been changed to System.Web.HttpPostedFileBase to enable non-ASP.NET hosting (OWIN).
  • Indexed properties in WIG: Previously if a property was defined with name "item", it translated to a an indexer on the object. This is changed so that the empty string is usable for this (still will get .NET property name Item, the default indexer for the class).
// generates default .NET indexer
"" =@ T<obj> |> Indexed T<int> // has JavaScript inline "$this[$index]"
By András Jankó on Monday, November 17, 2014 — 0 comments

CloudSharper released Core team

This is a bugfix release with some additions for FSI.

Full changes:

  • #568: Do not send multiple commands to local service when using the "Retry" button on the dashboard screen.
  • Markdown documents with embedded F# code blocks show two buttons now. "Send to interactive" was renamed to "Run" and "Edit" just sends the contents to the Interactive input box without executing it.
  • DLL files have a "Reference in interactive" context menu which runs an #r command with that library.
  • "Find in solution explorer" context menu item on tab headers is only visible when the file has a node in solution view.

Happy coding!

By Adam Granicz on Thursday, November 13, 2014 — 2 comments

Self-hosted WebSharper application template available Core team

A new Visual Studio template has been added to the latest Visual Studio installer called "Self-Hosted Client-Server Application," and you can use this template to build OWIN-based self-hosted applications that can be deployed via an .exe file and without requiring an installed web container (IIS, etc.) on the serving machine.

The following code shows embedding a given sitelet (Site.MainSitelet) into an OWIN container and starting it:

module SelfHostedServer =

    open global.Owin
    open Microsoft.Owin.Hosting
    open Microsoft.Owin.StaticFiles
    open Microsoft.Owin.FileSystems
    open IntelliFactory.WebSharper.Owin

    let Main = function
        | [| rootDirectory; url |] ->
            use server = WebApp.Start(url, fun appB ->
                            FileSystem = PhysicalFileSystem(rootDirectory)))
                    .UseSitelet(rootDirectory, Site.MainSitelet)
                |> ignore)
            stdout.WriteLine("Serving {0}", url)
            stdin.ReadLine() |> ignore
        | _ ->
            eprintfn "Usage: OWIN1 ROOT_DIRECTORY URL"

The OWIN machinery to make this work has been released as a new WebSharper.Owin NuGet package as well. The new Visual Studio template contains this boilerplate code, takes care of fetching the dependent OWIN packages, and calls the generated OWIN container .exe with the right arguments to host your sitelets easily.

Work to add this new WebSharper project template to the MonoDevelop/Xamarin Studio integration is underway.

Let us know what you think and happy coding!

By András Jankó on Wednesday, October 29, 2014 — 0 comments

CloudSharper released Core team

This is a bugfix release for cloud workspace management. A context menu item was added on cloud workspaces to get the clone and download links. If you delete a cloud workspace, you still have to wait a minute before you can re-upload it, but get correct notification about the failed upload.

Full change log:

  • #571: Download zip returns a corrupt archive.
  • #569: Add 'Get Share URL' option to cloud workspaces on the dashboard.
  • #570: Sync up fails if there are spaces in the workspace name.
  • #574: Dashboard workspace menus are not updated after sync operations.
  • #566: Fix uploading a previously deleted cloud workspace.

Happy coding!

By András Jankó on Tuesday, October 28, 2014 — 0 comments

CloudSharper released Core team

The dashboard is now showing your cloud-synced workspaces as well as your local ones. Separate icons show the availability of your workspaces in local working directory and the cloud storage. You can access the sync up/down commands on the context menu of the workspaces grid or by the More menu above. If both cloud and local copy exists, sync up or down will overwrite the other copy or if newer files exist at the destination, you will have the choice of keeping the newer version of all files.

Opening a workspace clone link will now warn if a local clone already exists and ask for opening the last version or create a new clone. However, cloning information is only stored starting from this release so older cloned workspaces won't get notified about.

Full change log:

  • #561: Add cloud workspaces management on the dashboard.
  • #564: Detect when user is trying to open an online-only workspace.
  • #560: Users should be able to log in with their email addresses as well.
  • #561: Add cloud workspaces management on the dashboard.
  • #424: Fix for using IF.Build.
  • #447: Notify user when the number of synced up workspaces reached the quota of his or her account.
  • #553: Deleting a file removes its compiler errors in Notification.
  • #565: Opening a clone URL with existing local workspace.

Known issues:

  • #566: Fix uploading a previously deleted cloud workspace.
  • #568: List workspaces sometimes get called twice if Retry button on dashboard was used .
  • Happy coding!

    By Loïc Denuzière on Wednesday, October 15, 2014 — 0 comments

    CloudSharper released Core team

    This release of CloudSharper adds configuration options for the local service's web server and the workspaces directory. These options are present in the CloudSharper.Console.exe.config file if you use the GUI console, or can be passed via the command line if you use CloudSharper.exe directly.

    • #558: Added an option rootdir pointing to the directory where CloudSharper should store workspace files.
      The string "$USERPROFILE" is replaced with the user's home directory (usually C:\Users\username in Windows).
      The default value is "$USERPROFILE\CloudSharper".
    • #559: Removed the option serveip and replaced it with two options: websocketserverip and webserverhostname.

      • websocketserverip configures the IP address on which the WebSockets server listens.
        The default is
      • webserverhostname configure the hostname or IP address on which the web servers (for static files and WebSharper Sitelets) listen.
        The default is localhost.

    Note for users in restricted environments such as Windows Domain accounts:

    CloudSharper used to require the use of the netsh command with administrator privilege in order to be able to run its web servers. Starting with this version, this is not the case anymore when webserverhostname="localhost". However, you may still experience a failure to start the web server and an error message printed by CloudSharper advising you to use netsh to allow the server to run. The most likely reason is that the port was reserved for previous CloudSharper versions to serve under the hostname instead of localhost. The best course of action is to remove this reservation by running the following command as administrator:

    netsh http delete urlacl

    where PORT is the port number indicated in the error message.
    You do not need to then run the netsh http add command as advised in the error message, because localhost is allowed by default if no other hostname reserves the same port.

    If you have any questions, don't hesitate to ask us on the FPish forums.

    Happy coding!