• Uninstall any old release of F#. Simply delete the directory contents.
• Unzip the FSharp-ILX-VERSION, e.g. at Desktop (the directory FSharp-ILX-VERSION will be created automatically).
• Double-click and run FSharp-ILX-VERSION\InstallFSharp.msi
• InstallFSharp.msi may fail if .NET 2.0 is not installed. If so, run alternative-install.bat.
• Delete the unzipped files, keeping the ZIP for archive if necessary.

  InstallFSharp.msi (and also alternative-install.bat) install the F# libraries in the Global Assembly Cache (GAC) in your machine, which means you can run the programs you compile from anywhere. Several flavours of these library may get installed, e.g. for use with early versions of the .NET Common Language Runtime (e.g. fslib10.dll - the ‘10′ stands for ‘version 1.0 or version 1.1′). F# will select the appropriate library based on the command line switches you use. You may install the libraries on other machines by copying appropriate files and running the alternative-install.bat script there or just manually adding the DLLs to the GAC

Installing F# Editing for Microsoft Visual Studio 2005

First follow the steps under Compiler Installation. If installing InstallFSharp.msi succeeded then you are done!!. See also Debugging with Visual Studio and Using F# Interactive with Visual Studio.

If InstallFSharp.msi failed you can try a manual install by simply running alternative-install-vs2005.bat. Indeed, you can always use this technique if you wish, but there will be no uninstall option. If this fails see the troubleshooting section below.

Installing F# Editing for Microsoft Visual Studio 2003

If you have Visual Studio 2003, you must do a manual install by simply running alternative-install-vs2003.bat. There is no uninstall option when using this technique, though you can always upgrade an installation simply by re-registering (in truth you can uninstall by just running the regsvr32 /u uninstallation commands that reverse the registrations done in the batch file).

When installing for Visual Studio 2003 you should ensure your machine is up-to-date with latest service packs and updates from Microsoft. You may also need to install the Microsoft Visual C++ 2005 runtime redistributable. Some people have reported problems running InstallFsharp.msi when installing for Visual Studio 2003 when registering DLL such as fslangservice.dll, in which case you can ignore these errors and register these DLLs using alternative-install-vs2003.bat. After doing this you should run devenv /setup, if this has not been done automatically by alternative-install-vs2003.bat.

Known Issues with F# Editing for Visual Studio

Here are the known issues in F# for Visual Studio, which you should read before making serious use of the system.

• Dependency order is required for the files in the Solution Explorer. If they aren’t, unload the project (right click on project, unload), edit the project file (right click on project, edit), put the entries in dependency order, reload project file.
• Resources, lexers, parsers etc. cannot be compiled from Visual Studio. You may wish to create a VB or C# project to hold your resource files.
• Use -R command line options in your project properties to reference across projects. This will copy the relevant files locally.
• Only opened files are typechecked interactively. That is, if an error is lurking in a closed file you won’t see that until you use F# Interactive or build and run.
• A couple of errors are only reported during code generation, so they don’t show up as red-squigglies in Visual Studio
• Errors in earlier files can lead to errors in later files. You should have the ‘Errors’ Window open to spot the global view of errors in your file.
• Some errors lead to potentially misleading confusing cascading errors (up to the maximum of 10)
• Sometimes the typechecker thread is a little behind the editing thread, and occasionally doesn’t catch up. To prompt the typechecker thread into action simply do a fake edit on the file (e.g. by hitting ’space’ then undo)
• Interactive typechecking happens against the _saved_ copies of files. That is, if you change a dependent file, that won’t be reflected in the interactive type checking of subsequent modules until you save it, AND you have to prompt the re-typecheck of the dependent files, (e.g. by hitting ’space’ then undo)
• The popdown menus for intellisense when hitting “|” were confusing and tiresome in versions prior to 1.1.10.2. This has now been disabled until we get the interaction right.

Troubleshooting installations of F# for Visual Studio

• You can check if F# for Visual Studio was successfully installed by running ‘regedit.exe’ and looking to see where the package key {771D2A70-00A2-4E42-9440-425CD92A4116} appears (use the Find menu). A successful installation into Visual Studio 2005 without VSIP would place it under

  HKEY_LOCAL_MACHINESOFTWAREMicrosoftVisualStudio8.0Packages

  An installation in VS 2003 would change 8.0 to 7.1, and if using the VSIP SDK then add ‘Exp’. (e.g. 7.1Exp and 8.0Exp). If the key doesn?t occur at all then installation of the F# Visual Studio components failed. If so, please report this problem to [email protected].

• You can force F# to be installed into a particular version of Microsoft Visual Studio by using the following environment variable settings. These must be set GLOBALLY, i.e. using ‘My Computer’->’Advanced’->’Environment Variables’, before you run FsVsPkgsInstaller.msi. You should unset this environment variable after you uninstall F#.
  • FSHARP_TARGET_VS_VER=7.0 — install into Microsoft Visual Studio .NET, normal mode, or no VSIP
  • FSHARP_TARGET_VS_VER=7.0Exp — install into Microsoft Visual Studio .NET, VSIP experimental mode
  • FSHARP_TARGET_VS_VER=7.1 — install into Microsoft Visual Studio 2003, normal mode, or no VSIP
  • FSHARP_TARGET_VS_VER=7.1Exp — install into Microsoft Visual Studio 2003, VSIP experimental mode
  • FSHARP_TARGET_VS_VER=8.0 — install into Microsoft Visual Studio 2005, normal mode, or no VSIP
  • FSHARP_TARGET_VS_VER=8.0Exp — install into Microsoft Visual Studio 2005, VSIP experimental mode
• If necessary you can de-register the F# package from particular versions of VS by running ‘regedit.exe’ and looking to see where the package key {771D2A70-00A2-4E42-9440-425CD92A4116} appears (use the Find menu). Delete all such registry keys and all sub-entries. Visual Studio will then no longer be able to load the F# packages.

Debugging F# code using Microsoft Visual Studio 2003 and 2005

The Visual Studio Debugger will work with F# code without any additional installation steps. Debugging information for the libraries may be found in the bin directory. In Visual Studio 2005 you may need to disable “Just My Code” debugging (use the “Options” menu). You can also set the appropriate symbol path there or you can add that path to the _NT_SYMBOL_PATH environment variable.

Debugging with F# for Visual Studio 2003/2005

If you are using the “F# for Visual Studio” plug-in for your F# projects you can launch debugging sessions directly from the environment. This is as simple as creating an “F# Project”, populating it with your code, pressing F11 to “step into” your program, and then you’re away!

Using Another Editor? You can still debug using Visual Studio 2003/2005!

All versions of Microsoft Visual Studio can be used as debuggers, regardless of whether you have created an F# project or even if you don’t have the F# Visual Studio plug-in installed at all (e.g., you are using the command-line compiler and Makefiles). There are five ways to start a debugging session. In all cases you should compile your code with the -g option to generate debug symbols.

• Just-in-time debugging. If an exception is not caught then a pop-up will typically give you the option to break directly into the Visual Studio debugger.
• Click and launch debugging. If you built your .exe from the command-line with the -g option, from Visual Studio open a “Project/Solution” selecting your .exe file, then press F11 (Step Into) and you should be debugging your code.
• Command-line launch debugging. You can launch directly into the debugger using devenv.exe /debugexe <executable-file> <args>
• Attach debugging. You can attach to a running process containing F# code using the Visual Stduio menus and/or the options on the Visual Studio command-line
• From your code. Calling System.Diagnostics.Debugger.Launch() causes a program to “ask for help”, which typically means it will pop up the standard “Just-in-time” debugging dialog box that allows the user to attach a debugger session to the program. This is very useful for assertion-like conditions that should never happen in your code. Calling System.Diagnostics.Debug.Assert() is similar, though a different assertion-specific dialog box is used. Likewise, calling System.Diagnostics.Debugger.Break() causes a break in an attached debugger, but only if a debugger is actually attached (it is ignored if no debugger is attached). System.Diagnostics.Debugger.Log() is used to send text to an attached debugger.

Tips. If debug symbols are not found for your code or for the F# library then you will probably want to disable “Just My Code” debugging in the “Options” menu (Visual Studio 2005 only). You can also set the _NT_SYMBOL_PATH variable globally on your machine.

Debugging with DBGCLR.EXE

The .NET Framework SDK comes with an excellent lightweight graphical debugger. To use this simply compile your code with the -g, make sure dbgclr.exe is on your path and then run it, e.g.,

dbgclr myexe.exe 

Using Visual C# 2005 Express and Friends

Visual C# 2005 Express, Visual Basic 2005 Express and some similar products are no-cost downloads from Microsoft site, and can all be used with F# code, or with multi-language programs. To use them with F#, open a console project and set the properties on the project to indicate the F# program to run.

Using CORDBG.EXE

This is the command-line debug shell from the .NET Framework SDK, and can be used with F# code. e.g.,

    C:devsrccode>cordbg
    (cordbg) run cdebug.exe
    (cordbg) help
    (cordbg) show 20
    (cordbg) si
    (cordbg) si
    (cordbg) si
    (cordbg) w