2

I have a app that I have been working on for weeks. Monday it started having issues with this error - seemingly out of the blue.

I have tried:

  • uninstalling and reinstalling the dll using the install provided by the author.
  • I have tried fiddling with the x64/x86, framework target, etc.
  • My last attempt was to create a brand new app that only has this reference and I get the same error.
  • Deleting the references to the installed dll's and referencing the dlls that are in the provided demo app.

I can open the demo app that uses this dll in VS that app runs fine.

System.IO.FileNotFoundException: 'Could not load file or assembly 'FLIRCommunicationsAdapter.dll' or one of its dependencies. The specified module could not be found.'

The error happens on the following line in Program.cs:

Application.Run(new Form1());

The dll is not referenced directly but is a dependent of another dll. I have compared references between the demo app and my recent, simplified test app and they are the same.

The dll does exist at the location called out in the reference properties.

I have tried fuslogvw and it reports that all dll's loaded successfully.

Any help would be appreciated.

EDIT This is the default Windows form app with two references added to the Flir libraries and one line that tries to create a Discovery object.

I have references to the following:

Analyzers
Flir.Atlas.Image
Flir.Atlas.Live
Microsoft.CSharp
System
System.Core
System.Data
System.Data.DataSetExtensions
System.Deployment
System.Drawing
System.Windows.Forms
System.Xml
System.Xml.Linq

My code:

using Flir.Atlas.Live.Discovery;
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;

namespace WindowsFormsApp2
{
    public partial class Form1 : Form
    {
        public Form1()
        {
        InitializeComponent();
        }

        private void Form1_Load(object sender, EventArgs e)
        {
        Discovery discovery;

        }
    }
}

If I remove "Discovery discovery;" the code runs fine.

NOT a duplicate of this post. As stated in the problem description I tried fuslogvw with no results. This is also not a ASP project. I do not have a C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files directory.

Eric Snyder
  • 1,816
  • 3
  • 22
  • 46
  • Possible duplicate of [Could not load file or assembly or one of its dependencies](https://stackoverflow.com/questions/4469929/could-not-load-file-or-assembly-or-one-of-its-dependencies) – Andrei Dragotoniu Feb 27 '19 at 13:53
  • It is a mixed-mode assembly that contains C++ code, built with VS2013. Lots and lots of unmanaged DLL dependencies beyond msvcr120.dll and msvcp120.dll, typical for code that started life on Unix. Stuff like swscale-3.dll, avcodec-56.dll, etc easily gets lost by accident when uninstalling another unixy app that ab/uses PATH. Use Dumpbin.exe /imports to see them. – Hans Passant Feb 27 '19 at 14:06
  • @Prasad Telkikar - This is not a duplicate of https://stackoverflow.com/q/4469929/6299857. As stated in the post I tried fuslogvw and did not find any issues. – Eric Snyder Feb 27 '19 at 14:16
  • @Hans Passant - running "dumpbin.exe /imports" from cmd prompt in admin mode returns one line that says "Summary" with nothing else. – Eric Snyder Feb 27 '19 at 14:23
  • @Hans Passant - by the way...those two files referenced (swscale-3.dll, avcodec-56.dll) ARE a part of what gets installed by the FLIR library. I tried adding those two to the references and I get: "A reference to 'path spec' could not be added. Please make sure the file is accessable, that it is a valid assembly or COM component." – Eric Snyder Feb 27 '19 at 14:31
  • You are at the bottom of a steep learning curve. This is endlessly easier when you tell us what DLLs you deploy, somebody can say "hey, you forgot *that* one". – Hans Passant Feb 27 '19 at 14:36
  • 1
    You can try to run ProcMon https://learn.microsoft.com/en-us/sysinternals/downloads/procmon which monitor system events, like disk access, and look for any request for files that are not found. Your issue may be with unmanaged dlls that are missing or put in the wrong path. If you figure out which are missing and are able to find them, put them in the same folder as your entry .exe of your application and they will be found. – mortb Feb 27 '19 at 15:12
  • @mortb - Looks like the app is looking for FLIRCommunications.dll in a whole bunch of different places and can't find it. I did copy it to the location of the exe file and it now runs. The dll that the app is not able to find is not referenced directly but is (I am assuming) a requirement of another dll. Windows never looks in the right place. I guess that this is solved with a work around but what would the root cause be? Is there a way to resolve the root cause of the lost dll? – Eric Snyder Feb 27 '19 at 18:54
  • I downloaded the FLIRCommunications.dll from here: https://github.com/ryanbales/FLIRImageProcessor/blob/master/src/lib/FLIR/x86/FLIRCommunications.dll I checked it and It is not a managed (.NET) dll. That means that the dll is written in unmanaged code (e.g. C or C++) .NET may reference unmanaged code using `DLLImport` https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.dllimportattribute?view=netframework-4.7.2 but it is only found in the right locations. See https://bytes.com/topic/c-sharp/answers/440208-dllimport-attribute-where-default-dll-location#td_post_1674137 – mortb Feb 28 '19 at 08:30
  • I'm not sure how you reference this library, my guess is that you are referencing a .NET library that contains `DLLImport` to the FLIRCommunications.dll. So maybe it is a "packaging" problem for the library that you have referenced? If you had imported the library as a nuget it would probably have put all its references in the right folders. If you had run an .msi installer for the library it probably also would have put its references in the right place – mortb Feb 28 '19 at 08:49
  • Unmangaged code interop takes some time getting used to – mortb Feb 28 '19 at 08:50

0 Answers0