You can reference .dll either with "-r <dll>" as a compiler option under the project property, or with
#r <dll>;;
within the file itself. Paths should be relative to the project/solution.
To reference another project, browse for and reference the DLL for that project. If right click on a project and try to add a F# project by choosing from the projects tab, the F# project does not show up.
When you compile multiple projects, dependencies are not always handled properly, so if a signature in the F# project is changed, you may have to compile twice to get around errors. The errors appear to be caused by compiling the F# after the project that depends on it. The second compile picks up the modified dll.
Also, make sure that you add the referenced DLL explicitly in the "Project Dependencies" settings in Visual Studio.
The F# Visual Studio mode runs a type checker in the background and reports the results as red-quigllies and in the Errors window. When r/I changes are made, or #r or #I in your file are changed, then the typechecker takes note of the new references, once you actually make an edit to your file to force re-typechecking.
Only files actually opened are checked interactively, so your project may still have errors in unopened files. You will discover these when you do a build.
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.
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).
A couple of F# language rules are only enforced during code generation, so they don’t show up as red-squigglies in Visual Studio. You'll find these when you build or run the code in F# Interactive.
Some errors lead to potentially misleading confusing cascading errors (up to the maximum of 10). Fix the first error in the file first. You might also like to sort the "Errors" window by file in order to keep it sane as the files get checked. 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.
When using interface files in a Visual Studio project, the order of files in the project is significant. The .fsi file for module M must occur above the matching .fs file for module M to ensure that the .fsi file is compiled before the .fs file, or you get a compiler error. This ensures that the interface is compiled before the implementation of the interface.
To change the order of the files in the project tree you must unload the project (right click on the project in the solution explorer), choose "edit ProjectName.fsharpp" on the closed project node (again in the solution explorer), make your edits then reload the project. You don't need to close Visual Studio (note, this applies to Visual Studio 2005, not Visual Studio 2003). The order of the files in the project file determines the order in the project tree.
If you are using a Visual Studio F# project (rather than just F# Interactive) then you can use F5 to actually build an executable or DLL for your code.
There is a problem where if you click on an error in the "output" window after an F5 build in Visual Studio the editor does not jump to the right file and line location. The fix for this is to use the "--fullpaths" flag in your project properties, which will then report the full path to the file which allows Visual Studio to take you to the right spot.
If you are getting errors on module names when viewing source code files, some dll files may not have registered during the install.
Find these dlls in the install tree and register them with regsvr32 to fix the problem:
FsLangService.dll
FsPrj.dll
babelpackage.dll