>>>>>HI
>>>>>
>>>>>I'm looking at a .NET project which contains references to several external dlls.
>>>>>
>>>>>I want to move the project but when I do it cabn't find the dlls any more as the refernces to the dlls have changed and are pointing to an invalid location.
>>>>>
>>>>>What am I doing wrong.
>>>>>
>>>>>Thanks
>>>>>
>>>>>Nick
>>>>
>>>>I see Viv answered. I've fixed quite a few of these same situations. If you can't find a specific DLL, check the bin folder of the production site. I usually create a "Library" folder in the root of my app that contain all the external DLL's and those get checked into source control with the app. This makes the source code portable. IMO, you should be able to pull down the source from source control and build it immediately without having to tinker around with it.
>>>
>>>Hi,
>>>I alway dither about this issue. But, in the approach you suggest above, do you really need the 'Library' folder. I think it would work if you put the DLLs directly into the /bin folder, turned off 'Copy Local' and referenced them there ? Of course whilst the upside of this approach is that you know you will always get the same DLL version the downside is that you will not neccessarily get the latest version :-}
>>
>Hi,
>
>>Where :
>In the Properties page of the relevant DLL (within Project/References).
>> and why would you turn off copy local
>The example above is one case where I suppose you might want to. But, in general, best leave well alone. 'Copy Local' defaults to false for native .NET framework DLLs (and, I think, for any DLLs that are loaded in the GAC). Others are flagged true which means you pick up the latest version of those DLLs every time you build.

Thanks Viv

My view would be that knowing you will always get a specific dll and not a possibly unplanned "newer" one would be a good thing.