F# Kung Fu #4: Avoid using relative paths in #r directives

Today, Vladimir Makarov faced with quite interesting ‘bug'(very unexpected behavior) of FSI. The initial goal was quite simple – count number of NuGet packages, which have “ASP.NET” in title. As a result, there was created a script that perfectly works in compiled form and crashes in FSI, here it is:

#r "../packages/nuget.core.2.8.2/lib/net40-Client/Nuget.Core.dll"
#r "System.Xml.Linq.dll"

let repository =

let aspnet = query {
    for p in repository.GetPackages() do
    where (p.Title.Contains "ASP.NET")

When we run this in FSI we got an exception

System.ArgumentException: Incorrect instance type
Parameter name: obj
at Microsoft.FSharp.Quotations.PatternsModule.mkInstanceMethodCall(FSharpExpr obj, MethodInfo minfo, FSharpList`1 args)
at Microsoft.FSharp.Quotations.ExprShapeModule.RebuildShapeCombination(Object shape, FSharpList`1 arguments)
at Microsoft.FSharp.Primitives.Basics.List.map[T,TResult](FSharpFunc`2 mapping, FSharpList`1 x)
at Microsoft.FSharp.Linq.QueryModule.walk@933-1[a](FSharpFunc`2 f, FSharpExpr p)
at Microsoft.FSharp.Linq.QueryModule.EvalNonNestedInner(CanEliminate canElim, FSharpExpr queryProducingSequence)
at Microsoft.FSharp.Linq.QueryModule.EvalNonNestedOuter(CanEliminate canElim, FSharpExpr tm)
at Microsoft.FSharp.Linq.QueryModule.clo@1741-1.Microsoft-FSharp-Linq-ForwardDeclarations-IQueryMethods-Execute[a,b](FSharpExpr`1 )
at <StartupCode$FSI_0002>.$FSI_0002.main@() in D:\Downloads\test.fsx:line 4

When we looked more carefully to FSI output, we saw that:


WAT? FSI lies to us?! First message says that correct version of DLL was referenced, but then FSI loads completely wrong old version installed with ASP.NET. Why? Let’s check what #r actually does…

#r means to reference by dll-path; focusing on name. This means that FSI will use the file name first, looking in the system-wide search path and only then try to use the string after #r as a directory-relative hint

So that means, #r is not reliable way to reference assemblies. You can get into the situation when your script depends on the environment: assemblies in GAC, installed software (like version of ASP.NET) and so on. To avoid this it is better to explicitly specify an assembly search path (#I) and then reference the assembly:

#I "../packages/nuget.core.2.8.2/lib/net40-Client"
#r "Nuget.Core.dll"
#r "System.Xml.Linq.dll"

let repository =

let aspnet = query {
    for p in repository.GetPackages() do
    where (p.Title.Contains "ASP.NET")

Thanks to Vladimir Makarov for interesting challenge and be careful in your scripts.

F# Kung Fu #1: Mastering F# Script references.

One of the most boring parts during working with F# Script files is external references. We need to write a lot of directives with paths to the required files.

New Visual Studio 2013 can help here a bit. A new ‘Send to Interactive‘ button is available there.  Now you can avoid typing an extra command to load references for interactive execution of a small part of your application. But what to do if F# script is our goal?

If you are VS2012 user, then one nice plugin from Tao Liu is available for you “AddReferenceInFSI“. It is a really nice extension, but it is still not a silver bullet.

What do real gurus do in such a situation? Tomas Petricek has shared one typing trick. You can find it in his latest Channel 9 video “Understanding the World with F#” starting from 4:40. What?!? How did he open file picker inside the source code file, chose file that he wanted and inserted relative path to the file directly in code? Why do I always type these long and boring paths if it can be done so easy? Today the truth will come true!

Thomas was so kind and revealed the secret of this trick:

The truth is not so magical as on the face of it – just use the power of your file editor. Let’s repeat all steps once again to better remember:

  1. Find a place where you want to insert file path
  2. Press Ctrl+O that should open a standard file picker. By default VS should open a dialog in the directory where your current file is saved in.
  3. Start typing relative or absolute path to your file, BUT do not use mouse – you are able to use only auto-complete in file path edit box.
  4. When you find a file – select path to it (Ctrl+A)
  5. Copy it (Ctrl+C)
  6. Close file picker (Esc)
  7. Insert path in your script (Ctrl+V)

Do not type boring paths – do it like Tomas 😉

Update from Yan Cui: There is one useful script from Gustavo Guerra. You can load it in every FSI session and save your time.

F# Interactive “branding”

FSI console has a pretty small font size by default. It is really uncomfortable to share screen with projector.  Source code in FSI is always small and hard to read. Never thought (until today) that I can configure font, color, font size and etc. In fact, it is very easy to do:

  1. Click Tools -> Options.
  2. Select Environment -> Fonts and Colors.
  3. In the ‘Show setting for‘ drop-down select ‘F# Interactive‘.FSIbranding
  4. Here it is – you can change whatever you want.
  5. That’s wonderful!

Running F# Interactive from Windows context menu

It is looks like really reasonable option!

In F# Major

Today a question popped up on Stack Overflow on how to arrange running F# scripts from Windows context menu, but in case of abnormal termination still having opportunity to access diagnostics. Regular context menu item Run with F# interactive lacks the latter because interactive console window closes abruptly on script failure.

Although I gave an outline of the solution as Stack Overflow answer, it lacks level of details that those who want to use such feature may find useful. So, I decided to give here a more detailed description. I will show the implementation for my own work environment, which is Windows 7 Ultra x64 + VS2012 Ultra RC. Reproducing the approach for other environments may require trivial adjustments.

1. Let’s begin with spying the mechanics of stock context menu item Run with F# interactive… implementation. Let’s fire regedit in Run as Administrator mode and search through the registry for…

View original post 209 more words

Accessing Local Variable Information in FSI

It’s time to make first steps to the new improved FSI. I feel that I should start looking for ways to implement something from My wish list for FSI. Let’s begin from #3 and try to find a list of declared variables and functions.

Before execution of any piece of code, FSI compiles it and creates a new type in current assembly. This type contain all named variables as properties and named function as function. The latest unnamed variable/function stores in property that called ‘it‘. So, it means that we can collect all required information using reflection.

Below you can find my implementation of the function objects() that prints lists of declared variables and functions.

let objects() =
  let methods =
      |> Seq.filter (fun t ->
        t.CustomAttributes |> Seq.exists (fun a ->
          a.AttributeType = typeof<Microsoft.FSharp.Core.CompilationMappingAttribute>))
      |> Seq.sortBy (fun t -> t.Name)
      |> Seq.map (fun t ->
        t.GetMethods() |> Seq.filter(fun m -> not(m.IsHideBySig)))
      |> Seq.concat
      |> List.ofSeq
  let var, func =
    Map.empty<string, System.Reflection.MethodInfo>
      |> List.foldBack (fun (m:System.Reflection.MethodInfo) map ->
              let name = if (not(m.IsSpecialName)) then m.Name
                         else m.Name.Substring(4)
              if ((m.IsSpecialName && (m.GetParameters().Length > 0)) ||
                  map.ContainsKey(name)) then map
              else map.Add(name, m))
      |> Map.toList
      |> List.partition (fun (_,m) -> m.IsSpecialName)

  let printList title ls =
    printfn "%s : %A" title ( ls |> List.map fst |> List.sort )
  var  |> printList "Variables"
  func |> printList "Functions"

Now let’s look at a real-life example on the screenshot below.

My wish list for FSI

I have thought about possible directions of FSI development. I have some ideas that I would like to share and discuss.

In general, it would be great to make FSI more than just an execution shell. It can become a really powerful development tool. What exactly we can do:

1) Session Save/Load functionality

It will be nice to have an ability to save current FSI state into the file and continue work in the next time.

2) Native C# interaction with FSI saved sessions

It could sound crazy, but  it would be cool to save FSI session to assembly and provide an easy C#-F# interaction with such assemblies.  For example, it might be useful for Machine Learning tasks. You will be able to create, train and tune your model directly from FSI then save it to assembly and use it from your C# application.

3) Current environment overview

Provide an ability to see the difference between current FSI state and default state. For example:

  1. Print all declared variables with their values
  2. Print all declared function with their signatures
  3. Print list of referenced assemblies with included directories
  4. Provide an ability to print function’s body

There is a tool that provides a part of this functionality. This is FsEye – a visual object tree inspector for the F# Interactive.

4) Intellisense for FSI
5) Detailed type provider description

One of the main cons in type providers is impossibility to explore the schema of the provided world. For example, I want to use Freebase type provider, but I do not know the nature of the provided types. I cannot use provided types fully, because I do not know what data they have.

I am pretty much sure that we need to supply a way to explore provided types. This feature for sure should be tightly integrated with F# IDEs (into Object browser for example).

6)Interactive help

All we use MSDN to understand how things work. We copy type name + function name and paste them to Google, find first MSDN link and go there. Why cannot we teach FSI to do it? We just need to build an easy syntax for that.

7) The ability to use the load directive inside of modules\functions (by @davidkl_)

P.S. I will be happy to hear your feedback or new ideas. Feel free to post comments here or to contact me in twitter (@sergey_tihon).

64bit fsi (FSharp Interactive) already available !!!

The good news for all F#/SharePoint lovers! As I learned today, 64 bit version of fsi already available as a part of F# 3.0. It is FsiAnyCPU.exe (at C:\Program Files (x86)\Microsoft SDKs\F#\3.0\Framework\v4.0).

These mean that now we should be able to connect to the SharePoint directly from fsi. It’s really cool !!!

As I see, into vs2012 we can choose version of fsi from Tools->Options.

P.S. Great thanks to the Mauricio Scheffer for great news.