2

I have a visual studio project with is running absolutely fine. But a new client requirement comes up for deployment for placing the different dlls in different folders.

We have a framework dll which can be used in a different project. There are some third-party dlls on which this framework dll depends upon. So when I use this dll from my project every dependent dll is copied to my local on the build as CopyLocal property is true.

But now with new requirement we can not have CopyLocal property set as True. The client wants no local copy of any dll, rather he wants framework related dll in some location. When I am doing this the dependent DLL's are not getting loded.

I know I have two options:

  1. I can put them in GAC, but I don't want to do this as I want them to support xcopy.
  2. Using reflection(But I am not sure of this that is this the right approach)

Can we do anything using configurations??

Ofir Lana
  • 383
  • 5
  • 13
Mudit Singh
  • 117
  • 2
  • 9

1 Answers1

0

You can configure assembly probing paths using the <probing> configuration element:

Specifies application base subdirectories for the common language runtime to search when loading assemblies.

Example from MSDN:

<configuration>  
   <runtime>  
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">  
         <probing privatePath="bin;bin2\subbin;bin3"/>  
      </assemblyBinding>  
   </runtime>  
</configuration>  

However, if the assemblies in question reside outside the application base ("which is the root location where the application is being executed"), you have the <codeBase> configuration element:

Specifies where the common language runtime can find an assembly.

Example from MSDN:

<configuration>  
   <runtime>  
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">  
         <dependentAssembly>  
            <assemblyIdentity name="myAssembly"  
                              publicKeyToken="32ab4ba45e0a69a1"  
                              culture="neutral" />  
            <codeBase version="2.0.0.0"  
                      href="http://www.litwareinc.com/myAssembly.dll"/>  
         </dependentAssembly>  
      </assemblyBinding>  
   </runtime>  
</configuration>  

For the exact details of how the runtime locates assemblies you can refer to this MSDN article.

As OP pointed out, unfortunately codeBase element is a usable option for strong named assemblies only. For private assemblies you need a workaround. Some viable ideas can be found in this discussion such as:

I've tested the latter and can confirm it works:

AppDomain.CurrentDomain.AssemblyResolve += (s, e) =>
    Assembly.LoadFile(Path.Combine(Settings.Default.AssemblyPath, Path.ChangeExtension(e.Name.Substring(0, e.Name.IndexOf(',')), ".dll")));
Adam Simon
  • 2,762
  • 16
  • 22
  • I think probing works within same application directory. But I will definitly try this. Thanks – Mudit Singh Aug 24 '18 at 12:50
  • This again will not work as I think I can not strong name third party dll's. Without giving them strong name we probably can not use this. If I know correctly. – Mudit Singh Aug 24 '18 at 12:59