Retrieving DLL path


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 5 of 5

Thread: Retrieving DLL path

  1. #1
    Darrin Dyson Guest

    Retrieving DLL path


    Sorry for the long post, but I am sure someone has an answer to this, I just
    can't find it

    I am trying to get around a problem that existed in VB6 that I thought was
    fixed in the .NET Framework. I use a configuration file for some of my
    components that get read when it's loaded by the application. The XML file
    "should" be located in the same path as the EXE file when it's deployed (ok)
    , but when debugging it's in a different path from the executable. What
    I
    find is that I have the same problem in .NET that I had in VB6 although
    somewhat different. In VB6 I used App.Path and the XML file had to be in
    the directory where the component was. In .NET using either:

    System.IO.Path.GetDirectoryName(Me.GetType.Assembly.Location)
    System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssem
    bly().Location)

    I get the path of the calling program returned, not the path of the
    referenced DLL that the code is actually running from. If anyone knows of
    away to get the path from the actual component, could they please let me
    know. Also, if this is an issue with debugging the referenced DLL in the
    same solution, I would like to know that also.

    Thanks again

    dpd


  2. #2
    Anthony Glenwright Guest

    Re: Retrieving DLL path


    Not sure if this will help, but you can try AppDomain.CurrentDomain.BaseDirectory
    instead of reflection. This will give you the application domain's base
    path, rather than the DLL location.

    You wrote that System.Reflection.Assembly.GetExecutingAssembly().Location
    gives you the path of the calling assembly - I think you may be mistaken
    - I've used System.Reflection.Assembly.GetExecutingAssembly().Location plenty
    of times, and it gives you the location of the currently executing code.
    You can use GetEntryAssembly or GetCallingAssembly to get the first assembly
    run or the assembly that called "this" assembly.

    If you are running a web service or ASP.NET application, the system.reflection
    calls can give you unexpected results, because the assemblies will be running
    from a shadow copy. Generally, I find that AppDomain.CurrentDomain.BaseDirectory
    gives the most consistent results across the board.

    "Darrin Dyson" <ddyson@edeploy.com> wrote:
    >
    >Sorry for the long post, but I am sure someone has an answer to this, I

    just
    >can't find it
    >
    >I am trying to get around a problem that existed in VB6 that I thought was
    >fixed in the .NET Framework. I use a configuration file for some of my
    >components that get read when it's loaded by the application. The XML file
    >"should" be located in the same path as the EXE file when it's deployed

    (ok)
    >, but when debugging it's in a different path from the executable. What
    >I
    >find is that I have the same problem in .NET that I had in VB6 although
    >somewhat different. In VB6 I used App.Path and the XML file had to be in
    >the directory where the component was. In .NET using either:
    >
    >System.IO.Path.GetDirectoryName(Me.GetType.Assembly.Location)
    >System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssem
    >bly().Location)
    >
    >I get the path of the calling program returned, not the path of the
    >referenced DLL that the code is actually running from. If anyone knows

    of
    >away to get the path from the actual component, could they please let me
    >know. Also, if this is an issue with debugging the referenced DLL in the
    >same solution, I would like to know that also.
    >
    >Thanks again
    >
    >dpd
    >



  3. #3
    Patrik Löwendahl Guest

    Re: Retrieving DLL path


    this.GetType().Assembly.Location

    --
    Patrik Löwendahl
    cshrp.net - "Elegant code by witty programmers"

  4. #4
    Join Date
    May 2010
    Posts
    1
    Quote Originally Posted by Patrik Löwendahl View Post
    this.GetType().Assembly.Location

    --
    Patrik Löwendahl
    cshrp.net - "Elegant code by witty programmers"
    This isn't working for me. I get the path where the assembly was BUILT. I need the path where the assembly RESIDES. I built the dll under %my documents%\projects\myclass, but if i move the dll to a network share under \\mydomain\dlls\myclass.dll, the command this.GetType().Assembly.Location still returns "%my documents%\projects\myclass\bin\release\myclass.dll" even though the dll being referred to is actually located at "\\mydomain\dlls\myclass.dll"

    I even deleted the project folder and ran the app again. It still refers to the non-existant path where it was built.

  5. #5
    Join Date
    Feb 2004
    Location
    Longueuil, Québec
    Posts
    577
    if this is an issue with debugging the referenced DLL in the
    same solution, I would like to know that also
    This is probably were your problem comes from. When you reference a dll in the same solution, the reference is made to the source code, not to the dll.

    This is good during debugging, but before deploying your application, remove the reference to the dll in the project and make a "standard" reference to the compiled dll.

    -----

    Another possible problem is that if the code resides in the application, this returns a reference to the application, not to the dll.

    If this is the case, create an object on one of the classes in your dll and use Reflection on that variable instead of this. The following code works very well for me (JBException is one of my classes):

    Code:
    JBFI.JBException test = new JBFI.JBException ( );
    Debug.WriteLine ( test.GetType ( ).Assembly.Location );
    Last edited by JBourgeois; 05-04-2010 at 05:38 PM. Reason: Formatting
    Jacques Bourgeois
    JBFI
    http://www3.sympatico.ca/jbfi/homeus.htm

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center