I successfully added something like C:\corporatelib\internalLib.dll to my F# ConsoleApplication project. I am sure it is added correctly, because I can see auto-completion working, the "open internalLib" works, and the project compiles.
However, when actually running the application, I am facing
Unhandled Exception. FileNotFoundException: Could not load file or assembly 'internalLib, version=<some wierd, wrong version nuber>, culture=neutral, PublicKeyToken=<some hex here>'. The system cannot find the file specified.
This makes no sense to me, as the path for internalLib.dll is correct: If I make a typo on puropose in the myproject.fsproj file, I lose the auto-completion, and the project doesn't compile.
I am also able to dynamically load the assembly with System.Reflection and Assembly.LoadFrom, but I would like to avoid that.
I did try to remove "bin" folder within the project tree, and rebuild/restart, with no effect
I am completely new to .NET.
As per your comments, your external library has its own other dependencies, this causes the error when trying to load the main external lib.
In this case, you need to have all the other dependencies present in the executable directory, along the other external lib you referenced.
You could copy the manually to the /bin or whatever is your output directory, to make it work. Of course, we want a more robust solution.
To get them copied automatically to your build output you could do either option A or B.
Referencing all the other library dependencies. This is somehow tedious, and not applicable here as I understand, because the other libraries should be .NET for this to work. You can avoid the tedious part by somehow scripting the edition into the .csproj file directly.
Create a solution or project folder in Visual Studio, and copy the external library dependencies here (you could copy the external lib itself here also, by the way).
Be sure to select the property "Copy Always" or "Copy if newest" for the Copy to Output Directory property of the item in Visual Studio, this way Visual Studio will actually put them in whatever /bin/ output directory. This becomes important if you setup a new environment, or create a new output configuration (debug / prod...).