How to reference .net DLL present in other folder
-
KASR1 wrote:
For some
reason i need to move a dll to program
files folderNo there is no reason you need to do that. Just as many other programs do not. What they do is create a sub folder and that is where the application goes.
I am not sure whether i have confused. Lets put that again, during deployment of my application i need install a particular dll to program files sub directory (eg. C:\program files\test). But my application will be in different directory. Since the dll Installed away from application directory and it uses/references many dlls present in application directory. How do i make that dll to pick dependent dlls from application directory. I dont want to move to GAC. Hope its clear.
-
I am not sure whether i have confused. Lets put that again, during deployment of my application i need install a particular dll to program files sub directory (eg. C:\program files\test). But my application will be in different directory. Since the dll Installed away from application directory and it uses/references many dlls present in application directory. How do i make that dll to pick dependent dlls from application directory. I dont want to move to GAC. Hope its clear.
-
Your application, let us call in it MyApp.exe will live in the following directly. C:\program files\MyCompany The dependent dlls will live in the same directory.
Lets us take an eg., I have MyApp.exe, Test1.dll,Test2.dll,Test3.dll. MyApp.exe depends/uses Test1.dll Test1.dll depends/uses Test2.dll, Test3.dll If i am installing all binaries to same directory say D:\TestAppln\ then my application will work perfectly. But due to some issues i need to move Test1.dll to programfiles sub-directory always(e.g, C:\program files\MyCompany) irrespective of installation. My application may reside in any directory. Since Test1.dll depends on Test2.dll and Test3.dll, i need to copy them from application folder to Test1.dll's folder i'e (e.g, C:\program files\MyCompany). Otherwise Test1.dll will not load. So my question is how to make Test1.dll to refer its dependant dll from application folder. I am looking for options other than GAC.
-
I am developing an c# application and it uses many .net assemblies. For some reason i need to move a dll to program files folder and that dll depends on many other assembly present in the application folder and this makes me to copy all dependent dlls to programfiles folder. This will cause duplication of dll in both application and programfiles directory. I know that moving dependent assembly to GAC will resolve this issue but i shound not put many assembly in GAC. So please suggest a way to make .Net dll to reference its dependent dlls.
Yes this is possible, for strongly named assemblies, with an addition to the
configuration sectionof the application's configuration file ( appname.exe.config ). In this example we have an assemblyStealthLib.dllwhich has been moved out of the applications's base directory tov:\Temp. Information about this new location is given in thedependentAssemblyelement where we must specify theassemblyIdentityand thecodeBase.Be really careful when editing the configuration file as errors are silently ignored. For example the assembly will not be found if the casing of publicKeyToken is changed to PublicKeyToken. The Assembly Binding Log Viewer (FUSLOGVW.exe) which comes with the .NET SDK is very useful for resolving assembly loading problems as it will log all the locations that have been searched for dependent assemblies.
LOG: Appbase = file:///E:/VC/Projects/CP/AssemblyProbing/MainProg/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = MainProg.exe
Calling assembly : MainProg, Version=1.0.4743.26012, Culture=neutral, PublicKeyToken=null.LOG: This bind starts in default load context.
LOG: Using application configuration file: E:\VC\Projects\CP\AssemblyProbing\MainProg\bin\Debug\MainProg.exe.config
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: StealthLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e0505f3b3553d5af
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///v:/Temp/StealthLib.dll.
LOG: Assembly download was successful. Attempting setup of file: v:\Temp\StealthLib.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: StealthLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e0505f3b3553d5af
LOG: Binding succeeds. Returns assembly from v:\Temp\StealthLib.dll.
LOG: Assembly is loaded in default load context.Good luck Alan.
-
Yes this is possible, for strongly named assemblies, with an addition to the
configuration sectionof the application's configuration file ( appname.exe.config ). In this example we have an assemblyStealthLib.dllwhich has been moved out of the applications's base directory tov:\Temp. Information about this new location is given in thedependentAssemblyelement where we must specify theassemblyIdentityand thecodeBase.Be really careful when editing the configuration file as errors are silently ignored. For example the assembly will not be found if the casing of publicKeyToken is changed to PublicKeyToken. The Assembly Binding Log Viewer (FUSLOGVW.exe) which comes with the .NET SDK is very useful for resolving assembly loading problems as it will log all the locations that have been searched for dependent assemblies.
LOG: Appbase = file:///E:/VC/Projects/CP/AssemblyProbing/MainProg/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = MainProg.exe
Calling assembly : MainProg, Version=1.0.4743.26012, Culture=neutral, PublicKeyToken=null.LOG: This bind starts in default load context.
LOG: Using application configuration file: E:\VC\Projects\CP\AssemblyProbing\MainProg\bin\Debug\MainProg.exe.config
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: StealthLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e0505f3b3553d5af
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///v:/Temp/StealthLib.dll.
LOG: Assembly download was successful. Attempting setup of file: v:\Temp\StealthLib.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: StealthLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e0505f3b3553d5af
LOG: Binding succeeds. Returns assembly from v:\Temp\StealthLib.dll.
LOG: Assembly is loaded in default load context.Good luck Alan.
-
Oh really great!. your input much appreciated. I have another question, Can we use the configfile for a dll to locate its dependent assembly? Or its only applicable for exe?
-
Lets us take an eg., I have MyApp.exe, Test1.dll,Test2.dll,Test3.dll. MyApp.exe depends/uses Test1.dll Test1.dll depends/uses Test2.dll, Test3.dll If i am installing all binaries to same directory say D:\TestAppln\ then my application will work perfectly. But due to some issues i need to move Test1.dll to programfiles sub-directory always(e.g, C:\program files\MyCompany) irrespective of installation. My application may reside in any directory. Since Test1.dll depends on Test2.dll and Test3.dll, i need to copy them from application folder to Test1.dll's folder i'e (e.g, C:\program files\MyCompany). Otherwise Test1.dll will not load. So my question is how to make Test1.dll to refer its dependant dll from application folder. I am looking for options other than GAC.
You can load the dlls dynamically. Also the AppDomain has an option that allows you to specify a search path. Creating an AppDomain yourself is one option. However I believe it is also possible to set that in the application itself perhaps via one of the properties.
-
I am developing an c# application and it uses many .net assemblies. For some reason i need to move a dll to program files folder and that dll depends on many other assembly present in the application folder and this makes me to copy all dependent dlls to programfiles folder. This will cause duplication of dll in both application and programfiles directory. I know that moving dependent assembly to GAC will resolve this issue but i shound not put many assembly in GAC. So please suggest a way to make .Net dll to reference its dependent dlls.
KASR1 wrote:
i shound not put many assembly in GAC
Why not?
-
KASR1 wrote:
i shound not put many assembly in GAC
Why not?
-
That's an interesting question that I don't know the answer to. Why not try it out? I may look at it tomorrow and if I do I'll post another reply. Alan.
-
If you have say App.exe -> DllA -> DllB, i.e. DllA uses DllB and App does not directly reference DllB. If DllA and DllB have been moved out of the application base directory then App.exe.config must be edited to provide separate location information for both DllA and DllB and there is no assumption that DllB now resides in the same place as DllA. Think of it like this: There is one process and the code in DllA executes in the context of that process. When code in DllA needs to call code residing in DllB then that assembly is loaded by 'the process' whose default locations are the GAC and the application base directory. Overrides to this default behaviour are on a per assembly basis. Any information contained within *.dll.config is not read automatically and will be ignored. Alan.
-
If you have say App.exe -> DllA -> DllB, i.e. DllA uses DllB and App does not directly reference DllB. If DllA and DllB have been moved out of the application base directory then App.exe.config must be edited to provide separate location information for both DllA and DllB and there is no assumption that DllB now resides in the same place as DllA. Think of it like this: There is one process and the code in DllA executes in the context of that process. When code in DllA needs to call code residing in DllB then that assembly is loaded by 'the process' whose default locations are the GAC and the application base directory. Overrides to this default behaviour are on a per assembly basis. Any information contained within *.dll.config is not read automatically and will be ignored. Alan.