3

When we create a new C# project and reference a dll, the dll is copied to the project's output directory when compiling the project.

Is there a way of referencing dll files and not copying them to the project's output directory, and have the executable work with them when it is being run (something like Assemblies if I'm not mistaken)?

I tried accessing the reference dll's properties, and changed the Copy Local to False but it didn't help (probably because that dll is depending on other dlls located in the dll's directory).

Is there any way of doing that?

Idanis
  • 1,918
  • 6
  • 38
  • 69
  • Why you don't want the dll to be there in output directory? – Sriram Sakthivel Aug 05 '15 at 10:10
  • Please clarify. Did you mean that changing Copy local didn't change anything and the assemblies still gets copied to the output folder or did you mean that the assembly can't be found if not copied local. If the later there is no magic to find assemblies anywhere you need to have them in the path, GAC or configured in the app.config. – Ralf Aug 05 '15 at 10:13

1 Answers1

2

Actually you can have you assemblies copied to GAC but this is not always an ideal solution.

You have to remember that each assembly copied to the GAC has to be strong named. If your projects uses some NuGet packages it would be a problem to install all those packages into GAC. I believe it is not a purpose of using NuGet either.

Another option would be loading your DLLs from different directory that default bin folder using <codeBase> tag in you configuration:

<configuration>
<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
     <dependentAssembly>
        <assemblyIdentity name="MyAssembly2"  culture="neutral" publicKeyToken="307041694a995978"/>
        <codeBase version="1.0.1524.23149" href="FILE://C:/Myassemblies/MyAssembly2.dll"/>
     </dependentAssembly>
  </assemblyBinding>
</runtime>
</configuration>

but as I remember it is possible during runtime.

EDIT: Since your problem is that you have to refer SDK, which is under development, I think neither GAC nor codeBase will work. One thing is versioning problem(you have to refer to the specific SDK version), the other is that you should always recompile your tool after new SDK release because some metadata are stored in your assembly, which can be outdated with the new SDK version.

Community
  • 1
  • 1
kamil-mrzyglod
  • 4,948
  • 1
  • 20
  • 29
  • The thing is that we have SDK installation under development, and I'm developing tools which use the SDK. If the dlls are copied to the tool's output directory, then each time I install a new SDK version, I need to recompile the tool. Based on that, is using GAC still not recommended? – Idanis Aug 05 '15 at 10:17
  • @Idanis - take into consideration that using GAC has some drawbacks that you have to be aware of. If you are using SDK, which is under development, I believe you will have to always recompile your tool - each SDK should have new assembly version assigned so using GAC or `codeBase` won't work because it requires referring to the specific version. – kamil-mrzyglod Aug 05 '15 at 10:22
  • Thanks for your reply. One last question - what if the SDK is in mature stage, in which the parts I'm using are rarely changed? – Idanis Aug 05 '15 at 10:32
  • @Idanis - then storing it in GAC or using `codeBase` could be a viable solution. The con of using GAC is that you have to install desired assemblies on each client's computer(if you have a server-side application it won't be the case). You have to remember though, that you should still reference specific version and recheck your tool after new SDK version is released(and recompile it when necessary). – kamil-mrzyglod Aug 05 '15 at 11:07
  • Thanks a lot for your assistance! – Idanis Aug 05 '15 at 11:26