F# September 2008 CTP - Known Issues

  • Article

We released the F# CTP a few weeks ago, and have been receiving tons of great feedback from F# developers since.  Here are some of the common issues which we've been asked about.  We'll continue to add on to this list as any new issues are raised.  Please continue to send any feedback, suggestions or comments to us at fsbugs@microsoft.com.

Known Issues

  1. Ctrl+. keybinding doesn't invoke View.ShowSmartTag in C# and VB editors
  2. Saving an F# project can fail when 'Save As' is invoked or VB profile is used
  3. Cannot add a reference to a project in a Solution folder
  4. Cannot add reference from an F# project to a C++/CLI project in Visual Studio
  5. Error message about a missing reference may get 'stuck' in the Error List 
  6. F# on 64bit
  7. Build errors are not reported in the Error List
  8. Dynamically evaluating a quotation which uses the "pown" function fails at runtime

1. Ctrl+. keybinding doesn't invoke View.ShowSmartTag in C# and VB editors

Issue:

The F# CTP uses the ctrl+. keybinding to break execution in the F# Interactive.  However, this keybinding is incorrectly applied globally, which prevents it from working in it's standard Visual Studio use of activating an editor SmartTag in the C# and VB editors.  The result is that installing the F# CTP prevents this keybinding from working in the C# and VB editors.

Workaround: 

To set the keybinding for ctrl+. back to it's original binding to the SmartTag, do the following.
In Tools->Options->Environment->Keyboard do the following:
1) Type "View.ShowSmartTag" in the "Show commands containing:" entry field
2) Hold down "ctrl" and press "." (dot) in the "Press shortcut keys" entry field
3) Click "Assign"

You can optionally re-assign the "OtherContextMenus.FSIConsoleContext.CancelEvaluation" command another keybinding, using similar steps.  Alternatively you can use the right-click menu option to cancel evaluation in the F# Interactive when needed.

2. Saving an F# project can fail when 'Save As' is invoked or VB profile is used

Issue:

The 'Save As' command in Visual Studio does not work on F# project files in the CTP release.  Projects can be saved with the name they were created with, but cannot be saved with a different name.  Related to this, if the 'Save new projects when created' option in Visual Studio is turned off, it is not possible to save an F# project after creating it.  Note that this setting is off by default in the VB profile, but on in all other Visual Studio profiles.  In both cases, an error message saying "The operation could not be completed.  No such interface supported" will be raised.

Workaround:

In Tools->Options->Projects and Solutions->General ensure that 'Save new projects when created' is checked.  To move a project file to another location, save the project and close Visual Studio, then move the project file manually and then reopen it in it's new location.

3. Cannot add a reference to a project in a Solution folder

Issue:

 

Attempting to add a reference from an F# project to a project which is inside a Solution Folder results in "Object not set to an instance of an object." error message, and fails to add the reference.

Workaround:

You can add an assembly reference to the output of the other project's build by browsing to the assembly in the Add Reference... dialog.  In some cases, it may be important to pick up the correct version of the referenced assembly depending on the build configuration, in these cases, rules such as the following can be added manually to the .fsproj file:

    <Reference Include="..\SolutionFolder\Library2\bin\Debug\Library2.dll" Condition ="'$(Configuration)' == 'Debug'" />

    <Reference Include="..\SolutionFolder\Library2\bin\Release\Library2.dll" Condition ="'$(Configuration)' == 'Release'" />

4. Cannot add reference from an F# project to a C++/CLI project in Visual Studio

Issue: 

Attempting to add a project reference from an F# project to a C++/CLI project results in "Object not set to an instance of an object." error message, and fails to add the reference.

Workaround: 

You can add an assembly reference to the output of the C++/CLI build by browsing to the assembly in the Add Reference... dialog.  In some cases, it may be important to pick up the correct version of the referenced assembly depending on the build configuration, in these cases, rules such as the following can be added manually to the .fsproj file:

    <Reference Include="..\ClassLibrary2\bin\Debug\ClassLibrary2.dll" Condition ="'$(Configuration)' == 'Debug'" />

    <Reference Include="..\ClassLibrary2\bin\Release\ClassLibrary2.dll" Condition ="'$(Configuration)' == 'Release'" />

5. Error message about a missing reference may get 'stuck' in the Error List

Issue: 

Adding a project reference to a project which has never been built will result in an error message appearing in the referencing project.  This error message may not go away when the referenced project is built.

Workaround: 

Shutting down and restarting Visual Studio will cause the error message to go away.  

6. F# on 64bit

Issue: 

Broadly speaking, F# applications will work well on 64bit machines and operating systems.  However, there are two possible issues to be aware of.

  1. The F# compiler and interactive are both 32bit processes, and will run in the WoW64 on 64-bit operating systems.  This may prevent loading native 64bit code into the F# interactive and may cause registry reads/writes to behave differently than in a true 64bit process. 
  2. F# code may be compiled as either 32bit, 64bit, or platform agnostic (AnyCPU).  Note that when F# applications are run on 64bit, they use the CLR's 64bit Just-In-Time compiler, which may not do tail call optimization in all cases, possibly resulting in StackOverflowExceptions in 64bit environments that were not seen in 32bit environments.

Workaround: 

It is possible to make F# Interactive load as 64-bit by modifying fsi.exe using corflags.exe. There are details on this .NEt Framework SDK tool at https://msdn.microsoft.com/en-us/library/ms164699(VS.80).aspx.

7. Build errors are not reported in the Error List

Issue: 

The error list in Visual Studio shows errors reported by the F# background compiler, but does not show errors reported by the F# compiler during an explicit build.  These are in most cases the same, so that this is not always an issue.  However, if some files in the project are not open, or if an error is reported during generation of the assembly, it may not appear in the error list.  Additionally, errors will appear in the error list for any open files, even ones which are not part of the current project.

Workaround: 

The Output Window in Visual Studio will always show the full results of a build.

8. Dynamically evaluating a quotation which uses the "pown" function fails at runtime

Issue:

Attempting to use the LINQ evaluation of a quotation involving the "pown" function will result in a DynamicInvocationNotSupportedException.

Workaround:

Consider using the ** exponentiation operator, a custom integer exponentiation function or repeated multiplication instead.