views:

952

answers:

9

I have a C# project that uses a dll. I added the dll to project references and I set the property Copy Local to False (I do not want to have local copies of that dll).

The compilation looks fine, but when I try to run the C# application, it cannot find the dll.

Where can I tell the project where to look for the library during runtime?

Thanks

A: 

If you set CopyToLocal to false, you to install that assembly in the GAC.

leppie
Global Assembly Cache, can be found on c:\<windows dir>\assembly.
Zaagmans
Search Google for how to install assemblies to the GAC. It is not a simple copy operation. But I assume you want to set CopyLocal to true instead, if you don't know about the GAC.
0xA3
A: 

Use the Fusion Log Viewer to track down problems with resolving assemblies.

If you don't want to have a local copy of the DLL you must put it in the Global Assembly Cache (GAC) or add Assembly Redirection instructions to your app.config or machine.config.

Gerrie Schenck
A: 

To reference this dll it either needs to be copied locally or in the GAC (Global Assembly Cache). Having a local copy is the preferred way to do it, so I would recommend switching copy local to true.

Grzenio
+3  A: 

Take a look at this MSDN article. It's about the <probing> element.

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

This allows you to tell the application where it can look for assemblies other than the default /bin folder.
Please note that it looks for 'subdirectories', so it cannot be a totally different folder. It has to reside in your application base folder.

Zaagmans
A: 

The application will look for the .dll in the same path as the executable and in the path-env. But as BtBh said: only use the off-switch if you put this assembly in the GAC.

CKoenig
+1  A: 

Why are you setting copylocal to false for project references? It is not recommended to do that.

Watch the difference between:

  1. Compile time assembly resolving
  2. Run time assembly resolving

GAC assemblies are always runtime resolved. GAC assemblies are shared assemblies by default (with reuse in mind).

Compile time resolvement is used to get the build done. Use project references as much as possible (with assemblies in your solution). Use file references when you are not in charge of the build of those assemblies you want to use and those assemblies are not in your solution.

Patrick Peters
A: 

Thanks for the answers, but I wanted to know a slightly different thing. In case I needed to distribute some classes to customers and these classes need to use the dll, how should I do this? (I find it awkward to copy the class together with the dll, also to copy it to GAC). Isn't there any other way?

A: 

Why is it ackward to copy all the external assemblies with the ones you made?

You can use XCOPY deployment so that all assemblies reside in 1 location.

An other way to deploy your assmblies is to package them all in 1 setup package (MSI).

Patrick Peters
A: 

If you don't want to distribute third party dll's with your own, you can either:

1) State the requirements and assume the dll will be installed in the GAC. It won't work most of the time, and having assemblies locally serves a purpose: your application is not supposed to break if some system wide update messes with your dependencies.

2) Bite the bullet and distribute the third party dll's with your own.

3) Providing it's legal to do so (watch for the licensing provisions of your third party dll's) use IL Merge to statically link your assemblies (your own and any third party). With ILMerge you can end up with having a single assembly containing all your references. You only merge when packaging for deployment (there are custom msbuild/NAnt tasks that do so for you), when developping in VS you just keep doing as you used to (referencing assemblies). ILMerge is used in quite a few projects to have a self-contained, compact executable (LinqPad comes to mind).

Yann Schwartz