Some words on #nugate

The sad truth

The Cockney Coder

As the author of what is now becoming an infamous PR, I thought that it’d be an idea to document my thoughts regarding both my motivations for it, as well as my thoughts on the reactions to it from all sides since then.

What’s #nugate?

tl;dr – a tiny and innocuous PR to the NuGet gallery that showed how to install NuGet packages when using Paket was closed abruptly by the NuGet team with an inadequate explanation, and then apparently ignored, despite large community feedback.

The Paket PR

Just a bit of background first on the PR. The idea came when looking at the new version of the NuGet site (which looks much nicer than the current one, I must say) and noticing a “tab view” for how to add a given package to your solution using either NuGet or the dotnet CLI. I thought that this might be…

View original post 3,644 more words

Why OO Matters (in F#)

I kind of agree and also prefer to use objects in some cases.

Eirik Tsarpalis' blog

F# is a functional-first programming language that comes with a substantial object-oriented feature set. It is so feature-complete in fact, that almost any C# class can be ported over to F# code with little substantial alteration.

However significant, this subset of the language is seeing limited appreciation from the community, which I suspect is partly fuelled by the known criticisms of OOP and partly by a desire to be different than C#. After all, this is a functional-first language so we can just replace all our classes with functions. There is also the opinion that OOP in F# merely serves as a compatibility layer for .NET, so it’s really only there to cover those unfortunate scenarios of having to use a library that accepts interfaces.

Enabling Abstraction

One of the most important aspects of maintaining a nontrivial codebase is controlling complexity. Complexity can be contained by partitioning code into logically…

View original post 1,596 more words

You’re better off using Exceptions

Worth reading, for sure.

Eirik Tsarpalis' blog

Exception handling is an error management paradigm that has often been met with criticism. Such criticisms typically revolve around scoping considerations, exceptions-as-control-flow abuse or even the assertion that exceptions are really just a type safe version of goto. To an extent, these seem like valid concerns but it is not within the scope of this article to address those per se.

Such concerns resonate particularly well within FP communities, often taken to the extreme: we should reject exceptions altogether, since code that throws is necessarily impure. In the F# community, this opinion is in part realized by advocating alternatives like result types and railway-oriented programming. In essence, these approaches follow the Either monad found in Haskell, but often intentionally avoiding the use of do notation/computation expressions (since that’s just interpreted exception semantics).

The TL;DR version of the approach is that we define a union type for results that looks…

View original post 920 more words

TypeShape: Practical Generic Programming in F#


Eirik Tsarpalis' blog

Last week I announced a new library, TypeShape, with claims that it provides a practical way of doing generic programming in F#. I’m following up with this blog post to elaborate why I believe this to be genuinely useful, and how it could benefit the day-to-day life of the working .NET developer.

The pain of Reflection

Almost everybody who has worked with .NET will at some point need to dabble in the murky ways of reflection. Reflection is needed in scenaria where we need to access data in an indirect fashion, or where circumvention of the type system is necessary.

For example, assume that we have defined the following static method

Assume now that we would like invoke that method, with a value whose type cannot be known at compile time. In other words, we want to define a function

which takes an input of type obj and invokes the generic method…

View original post 558 more words

Wire – Writing one of the fastest .NET serializers

Worth to try

Roger Johansson Blog

First of all, there is no such thing as “the fastest” serializer, it is all contextual.
But under some conditions, I would however argue that Wire is, by far, the fastest of all the .NET serializers out there.

Given the following POCO type.

Round tripping one million objects of this type, that is, serializing and then deserializing a million objects using Wire with all optimizations on, completes in about 550 milliseconds on my personal laptop.

Doing the same using MS Bond, which is the second fastest serializer in the benchmark, takes about 830 milliseconds, and this is while being very generous to Bond as it has some very specific prerequisites.
Protobuf.NET which is the third serializer on this benchmark completes in about 1360 milliseconds.

Other serializers that was included in the same benchmark was Jil, NetSerializer, FS Pickler, Json.NET and .NET BinaryFormatter.


View original post 1,847 more words

F# Type Providers Development Tips (not Tricks)

There are several tips that you probably would like to know if you plan to create a new F# Type Provider(TP) or to contribute to the existing one.

Tip #1: Use FSharp.TypeProviders.StarterPack

Latest version of ProvidedTypes SDK is stored in fsprojects/FSharp.TypeProviders.StarterPack repository and you have to use this version in most cases.

Community agreed to use this repository as master version for the SDK. You may find SDK files committed to other repositories, some of them (like files in FSharp.Data repository) may even be modified, contain new features or latest fixes. Once changes are tested and generalized enough, they will for sure be contributed back to FSharp.TypeProviders.StarterPack. So it is better to use a version from the official repository to be on the safe side.

Tip #2: Use Paket dependency manager

Paket allows you to reference files directly from GitHub and easily keep them up-to-date together with other NuGet dependencies.

All you need is to add two lines to your paket.dependecies files (that tell Paket to download files from GitHub to paket-files folder)

github fsprojects/FSharp.TypeProviders.StarterPack src/ProvidedTypes.fsi
github fsprojects/FSharp.TypeProviders.StarterPack src/ProvidedTypes.fs

and two lines to paket.references file (to tell Paket to insert files into corresponding fsproj files)


You can see how it works in ExcelProvider: paket.dependencies + paket.references

Tip #3: Create two solution files (*.sln)

You should not store TP project and projects that use TP in one solution, because when you reference TP dll, IDE/Intellisense loads this assembly and locks file on a disk. After that, you will not be able to rebuild your TP anymore until you close IDE.

So, it does not work in a long run and you have to separate your code to two solutions. The first one (let’s say SwaggerProvider.sln) will contain TP source code, tests for parser and for all components that don’t call TP directly. The second one (let’s say SwaggerProvider.TestsAndDocs.sln) will contain tests, which use TP directly and docs that may also use TP dll.


Tip #4: Automate build (using FAKE)

This tip is quite generic and you have to do it for all projects, but it becomes extremely useful for type providers. It’s tedious to open a new solution (IDE instance), when you want to test latest changes – it is much easier to have a build script that rebuilds and tests everything in one click.

The good start point here is fsprojects/ProjectScaffold that contains most useful generic build automation steps.

Tip #5: Yes, you can debug Type Providers

Debugging of TP does not look an easy task at first sight (and it is really slow in practice), but it is real.

You can start two instances of your IDE. The first one, for a solution with TP code and the second one for code that uses compiled type provider (here is important to check that the second one really references dll compiled by the first one). For the second IDE you can use TestAndDocs solution from Tip #4 or a simple *.fsx script that calls your TP. The last step is to set break point in the first IDE instance and to attach to the second IDE instance process.

This allows you to debug, but you will not be able to modify the code of TP. After each modification, you will need to close 2nd IDE, rebuild dll and repeat all these steps once again.

However, you can automate all manual steps:

  • Open project properties of TP project.
  • Open Debug tab.
  • Select start external program checkpoint
  • Enter path to your VS devenv.exe (For example: “C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe”)
  • Put path to your tests project (file) in command line arguments (For example “d:\GitHub\SwaggerProvider\SwaggerProvider.TestsAndDocs.sln”)

After that, when you press F5 from your TP project, VS will automatically build your TP, start your instance of VS, attach to a new VS process and open your tests solution in it.


Tip #6: Write tests using FSharp.Compiler.Service

Usefulness of this tip really depends on the TP you are working on, but if you are lucky enough (like I am) and you have an access to a large collection of schemes for your type provider, you can automate testing of compilation of provided types.

There is an awesome resource called (Wikipedia for WEB APIs) that provides an access to several hundred Swagger schemes of real-world Web APIs. For sure, SwaggerProvider uses these schemes to test schema parser and it is relatively easy to do.

But we can go further and check that provided types are “compilable” by F# compiler (there is no collisions in type names, property names, field names and method names).

The one way to do this is to use “Hosted Compiler” feature of F# Compiler Services. This allows us to create a simple script that just instantiates TP for each schema and asks F# Compiler to compile this generated script.

Here is source code from tests:

[<Test; TestCaseSource("JsonSchemasSource")>]
let ``Compile TP`` url =
  let tempFile = Path.GetTempFileName()
  let fs = Path.ChangeExtension(tempFile, ".fs")
  let dll = Path.ChangeExtension(tempFile, ".dll")

  File.WriteAllText(fs, sprintf """
  module TestModule
  open SwaggerProvider
  type ProvidedSwagger = SwaggerProvider<"%s">
  let instance = ProvidedSwagger()
  """ url)

  let errors, exitCode =
      (["fsc.exe"; "-o"; dll; "-a"; fs] @ asms))

  [tempFile; fs; dll]
  |> List.filter File.Exists
  |> List.iter File.Delete

  if exitCode <> 0 then
    let strs = errors |> x->x.ToString())
    failwithf "Error:\n%s" (String.Join("\n", strs )) 


Tip #7: Handling 3rd party NuGet dependencies

You face a dilemma when your TP needs 3rd party dlls: “How to deliver these dlls to a user?” This is a dilemma, because your IDE will not be able to resolve 3rd party dependencies without your participation if you just add them as dependencies to your NuGet package.

This is the case, for example, when your schema is in JSON format and you decided to use JSON.NET to parse it, or in Yaml format and you want to use YamlDotNet.

Option 1. Pack all dependencies inside your NuGet package.

The simplest solution is to put all required dlls in the folder with your TP dll in NuGet package. In this case, there is nothing to do with assembly resolution and it is definitely a good option to start from.

For example, FSharp.Configuration uses this option and packs SharpYaml.dll inside.

BUT, you have to remember that in this case you limit your users to the exact version of dll packed with your TP. If they reference a newer version from NuGet, it may lead to a run-time error.

Option 2. Uses AssemblyResolve event handler.

If I am not wrong, this solution was firstly developed in RProvider.

Actually, you split your TP into three assemblies:

  • TP.dll that setups AssemblyResolve event handler that helps IDE find assemblies on a hard drive and tells the compiler that TP will be in TP.DesignTime.dll (but doesn’t reference this assembly directly).
  • TP.DesignTime.dll that contains implementation of TP.
  • TP.Runtime.dll that contains the code that should exist in run-time and may be used by provided methods.

TP.dll references TP.Runtime.dll but uses nothing from it. Such dependencies do not break intellisense (because it does not need this assembly), but in the same time your provided code will be able to call code from TP.Runtime.dll.

Read more about this in RProvider Developer Notes (SwaggerProvider uses the same approach).


Tip #8: Use experience of other TP developers

Google Cloud Vision API from .NET\F# (OAuth2 with ServiceAccount.json)

Google Cloud Platform provides a wide range of APIs, one of which is Cloud Vision API that allows you to detect faces in images, extract sentiments, detect landmark, OCR and etc.

One of available annotators is “Logo Detection” that allows you to find company logo in your image and recognize it.

.NET is not the part of mainstream Google Cloud SDK. Google maintains google-api-dotnet-client that should allow you to authenticate to and call all available services. API design looks slightly not intuitive for .NET world (at least from my point of view).

I spent some time on Google/SO/Github trying to understand how to use OAuth2 in server-to-server authentication scenario with ServiceAccount.json file generated by Google API Manager.


You cannot use this API without billing account, so you have to put your credit card info, if you want to play with this API.

Also, note that you need to have two NuGet packages Google.Apis.Vision.v1Google.Apis.Oauth2.v2 (and a lot of their dependencies)

So, here is the full sample:

#load "Scripts/load-references-debug.fsx"

open System.IO
open Google.Apis.Auth.OAuth2
open Google.Apis.Services
open Google.Apis.Vision.v1
open Google.Apis.Vision.v1.Data

// OAuth2 authentication using service account JSON file
let credentials =
    let jsonServiceAccount = @"d:\ServiceAccount.json"
    use stream = new FileStream(jsonServiceAccount, 
                         FileMode.Open, FileAccess.Read)

let visionService = // Google Cloud Vision Service
        ApplicationName = "my-cool-app",
        HttpClientInitializer = credentials)
    |> VisionService

// Logo detection request for one image
let createRequest content = 
  let wrap (xs:'a list) = System.Collections.Generic.List(xs)
    Requests = wrap
        Features = wrap [Feature(Type = "LOGO_DETECTION")],
        Image = Image(Content = content))
  |> visionService.Images.Annotate

let call fileName = // Call and interpret results
    let request =
        File.ReadAllBytes fileName
        |> System.Convert.ToBase64String
        |> createRequest
    let response = request.Execute()

    [ for x in response.Responses do
        for y in x.LogoAnnotations do
          yield y.Description
    ] |> List.toArray

let x = call "D:\\fsharp256.png"
// val x : string [] = [|"F#"|]

FsShelter: a Storm shell for F#

I think, therefore I spam.

About a year ago Prolucid adopted Apache Storm as our platform of choice for event stream processing and F# as our language of choice for all of our “cloud” development.

FsStorm was an essential part that let us iterate, scale and deliver quickly, but even from the earliest days it was obvious that the developer experience could be improved. Unfortunately, it meant a complete rewrite of FsStorm:

  • FsStorm DSL is a really thin layer on top of Nimbus API model:
    • has explicit IDs when describing components in a topology
    • uses strings in all the names
    • matching of inputs/outputs is not guaranteed
  • FsStorm uses Json AST as it’s public API:
    • messages, tuples, configuration
    • serialization mechanism is hard-baked into the API

We’ve worked around some of the problems, usually by writing more code.

It actually makes sense that Storm itself doesn’t care about the type of the tuples/fields. It runs on JVM, which is very much typed…

View original post 220 more words

Application contracts with Swagger powered APIs for .NET or Why SwaggerProvider

This post is part of the F# Advent Calendar in English 2015 project.
And special thank you to Phillip Trelford for the idea of F# Advent in English year ago.

In this post I want to talk about how we design software, what we should care about and what we should not.

The story of The Contract

The initial thing is a problem. Nobody writes code without understanding what he/she is doing and what he/she expects to receive at the end. The task (problem description) may come from anywhere: it may be task from your boss or an awesome idea that pretty soon can change the world and bring you a lot of money or some tool / OSS project that will make your life easier in the future.

When you have a clear problem definition, you can start thinking about the solution. There are plenty of ways to solve any problem. You can choose any programming language, any operating system, any programming paradigm, any framework, any tool-set and so on. In order to choose one (the best in your case) solution you start applying real world constraints to reduce the number of solutions. You will probably decide to use a language and tools, which you are more familiar with or which suits better for this particular task. People do this because we all have very important real-life constraint – it is the time. Time-to-market is always important. Nobody starts writing a new operating system just because he/she can do it. We always try to minimize amount of work that should be done to speed up time-to-market.

When you actually start hacking, the thing you start with is `architecture`. Argh, I said that arch.. word. But architecture is nothing more than decomposition. If you do it right in terms of your constraints and limitations – you are almost done. After that, you should write code for small pieces and compose them to get the solution. But what defines the right decomposition? The answer is contracts!

Sounds really simple, does not it? However, it is not so far from the truth. Real-world solution architecture is always state of art, it cannot be super cool for all things, but it can fit your requirements to certain extent. All you can do mastering the architecture is to decompose your monolith idea to simple manageable components with clear responsibilities and clear contract.

The implementation of contract in programming language level is an interface (the promise of capabilities to the world). The implementation of interfaces in F#/C# is pretty good. You as a developer should only define an interface and implement it somewhere to provide a capability by contract. When you are on the other side and want to consume provided capabilities you should only reference component that defines contract and use it with almost zero overhead.

Based on the experience with interfaces, you have three ways of interaction with contract:

  1. Design (define) contract
  2. Provide (implement) contract
  3. Consume contract

But it is not so simple, when your application is larger than one executable file… What happens when you cross process and/or machine boundaries? In this case, we need a technology that allows us to setup the component that provides contract to one machine and consumes this contract on another machine with the same elegance as interfaces do this. At this moment, higher-level contracts (so called API) come to play.

There are plenty of technologies that can help you to develop some sort of API for your component. Probably first helpful thing that comes to mind is WSDL (Web Service Definition Language). When you choose WSDL as your contract language you receive plenty of tools that help you to manage your API, generate implementation from API contract, generate contract from your implementation, generate code that encapsulate all communication difficulties for consumers and so on. WSDL world is pretty mature and beautiful (I really love it), but it usually comes with SOAP and communication protocol that does not suitable for all types of cross-machine communication.

There are some real-world cases when you need more lightweight and fast communication mechanism that can be “easily” consumed from different languages and run-times. In such cases, people more often decide to provide RESTful APIs. BUT, all of you who design RESTful API for your systems and components SHOULD REMEMBER that technology that you use to design and implement contract SHOULD also provide a way to CONSUME your API. It is your responsibility to care about consumers, they should be focused on solving their own task using your API rather than writing boilerplate code to consume your API.


One of technologies that provide such goodness for developers is Swaggernlp-logo-navbar

Swagger is a simple yet powerful representation of your RESTful API. With the largest ecosystem of API tooling on the planet, thousands of developers are supporting Swagger in almost every modern programming language and deployment environment. With a Swagger-enabled API, you get interactive documentation, client SDK generation and discoverability.

Swagger Specification is able to describe pretty wide range of RESTful APIs. Swagger comes along with Swagger Edit that allows contract first API development. APIs that have Swagger schema can easily be integrated with Swagger UI – very powerful interface that dramatically simplify studying of new API (demo). Swagger ecosystem also has tools that generate client code for wide list of languages.

In the .NET world, exists a project called Swashbuckle, which generates Swagger schema to ASP.NET WebAPI services and plugs Swagger UI in your application. I’ve already blogged about how to use Swashbuckle from F# Web Apps.

Swagger is used in ASP.NET API app in Azure App Service and may come to Nancy very soon as well.

F# Swagger Provider

swaggerAs you may already understand, Swagger ecosystem looks very promising in general and Swagger Specification perfectly matches with F# Type Providers approach. So, I am glad to present the SwaggerProvider.

In order to start you need to add reference to SwaggerProvider NuGet package and pass Swagger JSON schema to it (for this example I will use a schema from Petstore – Swagger demo app).

#r "SwaggerProvider/SwaggerProvider.dll"
open SwaggerProvider

type PetStore = SwaggerProvider<"">

So, you are generally done. Type Provider parses provided schema and generates all required data types and methods to call API. Note that SwaggerProvider is generative type provider and generates types and methods that exist in run-time, so that means that it can be used from C# code as well.



Even if the RESTful API that you need to consume does not gently provide Swagger schema for you, you still can use SwaggerProvider to call it. It should be easier to manually describe schema once than to write and support source code for all REST calls.

Let’s say that we want to call GitHub API to get all fsprojects repositories. For this API call schema will look like this

    "swagger": "2.0",
    "info": {
        "description": "This is a Sample for GitHub API.",
        "version": "1.0.0",
        "title": "Swagger GitHub"
    "host": "",
    "basePath": "/",
    "tags": [
            "name": "repos",
            "description": "Repositories API"
    "schemes": [ "https" ],
    "paths": {
        "orgs/{orgId}/repos": {
            "get": {
                "tags": [ "repos" ],
                "summary": "List organization repositories",
                "description": "",
                "operationId": "orgRepos",
                "consumes": [ "application/json" ],
                "produces": [ "application/json" ],
                "parameters": [
                        "name": "orgId",
                        "in": "path",
                        "description": "Organization name",
                        "required": true,
                        "type": "string"
                "responses": {
                    "200": {
                        "description": "successful operation",
                        "schema": {
                            "type": "array",
                            "items": {
                                "$ref": "#/definitions/Repo"
    "definitions": {
        "Repo": {
            "type": "object",
            "properties": {
                "id": {
                    "type": "integer",
                    "format": "int64"
                "name": {
                    "type": "string"

If you use Visual Studio to edit Swagger schema, you will be pleasantly surprised by “Intellisense for JSON Schema in the JSON Editor


This JSON describes one data type Repo, that contains simplified version of GitHub Repository data type, and description of one API method /orgs/{orgId}/repos that does the job. Now you are able to use this schema to call GitHub API.



But if you really want to make a call to GitHub API, you need to specify real user agent header and SwaggerProvider allows you to do this:

open SwaggerProvider

let [<Literal>] schemaFile = __SOURCE_DIRECTORY__ + "\GitHub.json"
let [<Literal>] headers = "User-Agent=Googlebot/2.1 (+"
type GitHub = SwaggerProvider< schemaFile, headers >;

let names =
    |> (fun x -> x.Name)


Note: SwaggerProvider does not support schemes in YAML format yet. But this feature is definitely will be implemented, because it dramatically simplifies manual schema creation.

Please share your thoughts about SwaggerProvider and do not be shy to try it and report issues if any.

Special thanks to project for maintenance of wide range of real-world Swagger schemes that were used to test SwaggerProvider.