locked
Referencing a .dll in a location different from .exe RRS feed

  • Question

  • I am currently running the .exe that has been created using a Windows .bat file.  In my C# program, I am referencing a .dll.  I need to perform testing in a different location, and the program refuses to run if that .dll is not in the same folder as the .exe (FileNotFoundException).  I have already set the path in properties, and the .dll is sitting in the folder I have specified.

    My question is, can I reference a .dll even if it is in another directory, or does it have to be in the same directory as the .exe?  Please let me know what steps to take in order to reference the .dll successfully, thanks.

    Tuesday, October 26, 2010 1:49 PM

Answers

  • For .NET assemblies the loader limits assemblies (for security reasons) to the same directory or a set of subdirectories that are configured via probing paths in the config file or the GAC.  If you dynamically load an assembly (not recommended) then you can load from anywhere.  The current working directory is not relevant for assemblies.  There have been some articles on how to reference assemblies outside the probe path but most people do not consider it worth the effort.

    For native DLLs then the search path is documented by LoadLibrary.  You can programmatically alter the path to include other directories.

    I would recommend that you modify your batch file to copy the dependencies to the same directory as the EXE.  That's how most build processes work anyway.

    Michael Taylor - 10/26/2010
    http://msmvps.com/blogs/p3net

    • Marked as answer by V-Nar Tuesday, October 26, 2010 2:22 PM
    Tuesday, October 26, 2010 1:56 PM

All replies

  • For .NET assemblies the loader limits assemblies (for security reasons) to the same directory or a set of subdirectories that are configured via probing paths in the config file or the GAC.  If you dynamically load an assembly (not recommended) then you can load from anywhere.  The current working directory is not relevant for assemblies.  There have been some articles on how to reference assemblies outside the probe path but most people do not consider it worth the effort.

    For native DLLs then the search path is documented by LoadLibrary.  You can programmatically alter the path to include other directories.

    I would recommend that you modify your batch file to copy the dependencies to the same directory as the EXE.  That's how most build processes work anyway.

    Michael Taylor - 10/26/2010
    http://msmvps.com/blogs/p3net

    • Marked as answer by V-Nar Tuesday, October 26, 2010 2:22 PM
    Tuesday, October 26, 2010 1:56 PM
  • If you dynamically load an assembly (not recommended) then you can load from anywhere.  The current working directory is not relevant for assemblies.  There have been some articles on how to reference assemblies outside the probe path but most people do not consider it worth the effort.

    For native DLLs then the search path is documented by LoadLibrary.  You can programmatically alter the path to include other directories.

    I would recommend that you modify your batch file to copy the dependencies to the same directory as the EXE.  That's how most build processes work anyway.

    Michael Taylor - 10/26/2010
    http://msmvps.com/blogs/p3net

    Thanks for your answer.  I think I can see why it is not recommended.  But for the sake of learning, how would I dynamically load an assembly?  I have already changed the path to include other directories, but it refuses to work.
    Tuesday, October 26, 2010 2:21 PM
  • No it doesn't have to be in the same directory as the exe however you should consider the convenience of a relative path instead of full path unless you can guarantee that the dll will be there.

    When you add to a dll there is an option to create a local copy in the solution folder, if that is not what is desired you can unmark the option.

    Regards

    Tuesday, October 26, 2010 2:30 PM
  • Again, path has no meaning for loading assemblies.  It is strictly native mode. 

    If you are dynamically loading assemblies then you can use the Assembly.LoadFile method to specify a path.  However read the documentation carefully because this method can cause lots of issues.  It also increases the code required because you can't directly reference the assembly (as a project reference) in your code anymore.

    If you want the loader to find the assemblies then refer to this article: http://msdn.microsoft.com/en-us/magazine/dd727509.aspx.  It will help clarify how the loader works.  This article - http://msdn.microsoft.com/en-us/library/dd153782.aspx - references the programmatic methods for changing the search order.

    Finally the activation context might also help you.  I've never worked with it and it appears designed more for hosts but I've seen ACs used in normal apps once before to solve a different problem.

    Michael Taylor - 10/26/2010
    http://msmvps.com/blogs/p3net

    Tuesday, October 26, 2010 2:32 PM
  • To load an assembly by Reflection, see my blog entry on the subject:

    http://geek-goddess-bonnie.blogspot.com/2009/09/reflection-in-net.html

    The post shows an example of a class you can write to easily use Reflection for this purpose.


    ~~Bonnie Berent [C# MVP]

    geek-goddess-bonnie.blogspot.com
    Tuesday, October 26, 2010 2:34 PM
  • Thanks for the replies, I think I will steer clear of this method, since I will be scrambling to find the .DLL in another directory.  I guess it's best to keep the .DLL in the same dir as the EXE.
    Tuesday, October 26, 2010 2:42 PM
  • When you add to a dll there is an option to create a local copy in the solution folder, if that is not what is desired you can unmark the option.


    If you unmark it and the assembly is not in the GAC, you'll get a FileNotFoundException.

    Unless you have an AssemblyResolve event handler.

    Tuesday, October 26, 2010 4:06 PM