8

I have a .Net application which uses a couple of .Net dll's, these dll's are located in a folder which is included in the PATH environment variable, but when I start my .Net App if fails with the error:

Could not load file or assembly 'FxDoc.dll, Version=1.2.10.0, Culture=neutral, PublicKeyToken=1b44e1d4261664821' or one of its dependencies. The system cannot find the file specified.

I already have read these MSDN entries Search Path Used by Windows to Locate a DLL and Dynamic-Link Library Search Order

Which states:

Windows then searches for the DLLs in the following sequence:

The directory where the executable module for the current process is located.

The current directory.

The Windows system directory. The GetSystemDirectory function retrieves the path of this directory.

The Windows directory. The GetWindowsDirectory function retrieves the path of this directory.

The directories listed in the PATH environment variable.

My questions are:

  1. What factors could be causing this error?
  2. Is the above information valid for .Net?
Ry-
  • 218,210
  • 55
  • 464
  • 476
Salvador
  • 16,132
  • 33
  • 143
  • 245
  • Does this have a strong name? Is there a possibility that the problem is perhaps due to a different DLL on which FxDoc.dll is dependent upon? – Arun Sep 08 '11 at 01:06
  • @Arun the dll's does not have any string name, and exist only one copy in the system (100% sure). – Salvador Sep 08 '11 at 01:08

3 Answers3

20

The rules for .NET assemblies and plain-old DLLs are not the same. The rules you listed are for plain-old DLLs.

Assembly loading is surprisingly complicated, but the basic search order is like this:

  1. Global Assembly Cache (GAC)
  2. A long list of other locations (including the application base directory, and various subdirectories depending on culture, etc...)

The environment variable PATH isn't used for .NET assemblies. For all the gruesome details, you'll probably want to look at the official documentation:

http://msdn.microsoft.com/en-us/library/aa720133.aspx

Most places I've worked, people stick to the basics -- either the assembly goes into the GAC, or it's placed in the same directory as the application.

You might also be interested in this tool (fuslogvw.exe) which helps you figure out why the loader isn't finding your assembly:

http://msdn.microsoft.com/en-us/library/e74a18c4.aspx

JohnD
  • 14,327
  • 4
  • 40
  • 53
  • Is possible add an specific path to the list of locations (not GAC) used by -NET to search the assemblies? – Salvador Sep 08 '11 at 01:42
  • No, not really. I would recommend either simply copying the FxDoc.dll to your application's folder, or using gacutil.exe to install the file into the GAC. – JohnD Sep 08 '11 at 01:46
  • 3
    +1 never knew a .Net DLL did not have the same rules as a Win32 DLL. Thank you! – Arun Sep 08 '11 at 16:56
  • 2
    Are Microsoft deliberately trying to confuse people? So now a dll is no longer a dll anymore. Why did they not use a different extension for .net dll files. Like maybe .netdll. Anyway good to know, thanks JohnD. – Paul McCarthy May 04 '17 at 11:05
2

There are several factors that could be at play, including the (relatively new) registry parameter "SafeDllSearchMode". You can get full details here:

http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%29.aspx

I would check this link and check for things like your environment's GetAssembly().Location, and CurrentDomain.BaseDirectory:

How do I get the path of the assembly the code is in?

This is also a very good link:

http://blogs.msdn.com/b/aymans/archive/2006/04/04/568466.aspx

Finally, it's possible that maybe the root cause of the error isn't your .dll itself, but some OTHER .dll it depends on. It couldn't hurt to look at your .exe's and .dll's with MS Dependency Walker

Community
  • 1
  • 1
paulsm4
  • 114,292
  • 17
  • 138
  • 190
  • Apparently not: http://stackoverflow.com/questions/227886/how-do-i-determine-the-dependencies-of-a-net-application. The link recommends Net Reflector ... but I became disgusted with RedGate when they started charging ... and DELETED any older, working (free!) versions of Reflector it found installed on your hard drive. Nevertheless, I believe the links I gave you should point you in the right direction. – paulsm4 Sep 08 '11 at 01:22
  • This tool, MS "Assembly Binding Log Viewer", might also help: http://msdn.microsoft.com/en-us/library/e74a18c4%28VS.71%29.aspx – paulsm4 Sep 08 '11 at 01:25
2

For troubleshoouting assembly load failures - http://blogs.msdn.com/b/suzcook/archive/2003/05/29/57120.aspx

CLR does not use PATH to search for assemblies - your links are for native images loading. Check out this one: http://msdn.microsoft.com/en-us/library/yx7xezcf(v=VS.100).aspx

Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179