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.

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.

• .net
• f#

• 1 Is the file present in the build output, i.e. is it in the /bin/.... folder ? If not, is the runtime error solved if you copy it in the same directory as your executable ? Having the dll properly referenced for the project (e.g. for autocompletion) is not the same as having it bundled into the actual executable output. – Pac0 Commented Feb 7 at 16:55
• @Pac0 yes, the referenced .dll is present, however this particular library has about 100 other bunled .dll with it in C:\corporatelib. I presume I should reference them all? – Denis Commented Feb 7 at 17:01
• mmm, I see.. You could reference them if you want the build output to be properly generated, but I can see it could look awkward from a dev point of view. You don't need them in your code. Other option is to copy the other referenced dll along in your solution, in a "lib_dependencies" folder for instance, and select in their property the build option "copy - Always" or " copy- newest" (don't remember, and don't have Visual Studio with me at the moment). – Pac0 Commented Feb 7 at 17:09
• 1 Actually I just tried, I copied all the .dll in the bin folder, along with the main internalLib.dll, and that does nothing.. still NotFoundException. Also, i am not able to reference other dll, impossible to add them because "the reference is invalid or unsupported" – Denis Commented Feb 7 at 18:00
• 1 Ha, you solved it (I copied wrong architecture and I forgot to copy ".xll" which i thought were unnecessary) !! Just for more context: yes, the main .dll is indeed a .NET library, but many other .dll are actually C++. I am already using this exact internalLib.dll in python (clr-loader + code generation). However the performance is less than stellar, so I am trying to migrate to F#. Annoying thing is I would like to avoid codegen, but still, seems like it's the way to go if I want something developer-friendly when calling the library.. – Denis Commented 2 days ago

1 Answer 1

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.

Option A (not recommended):

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.

Option B:

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...).