Set “Copy Local” to False by default?

Question

Can I set the default-option of \"Copy Local\" in Visual Studio to False? In most times, when I add a dll as dependency of a project, I want the Copy Local property set to F

Answer 1

Regarding the solution posted by @herzbube, if you want to turn off "Copy Local" for all (or most) of the references in your .csproj file, you don't need to set False individually on each Reference, you can just put the following directly in the .csproj:

  
    False
  

This doesn't affect projects referenced with , but you can do the same thing--either instead or as well--for those:

  
    False
  

If you want both of these, you can merge them into a single group:

  
    False
  
  
    False
  

Make sure you put these overrides prior to the first actual or you want to affect because these blocks will only apply to those references that appear below them. Then, if there are a few that you do actually want to be locally copied, you can just override those back individually (i.e., within the individual tag itself), this time using True.

For more advanced cases you can switch the overriding value back and forth between True and False multiple times in the same .csproj file. Another advanced technique would be to strategically place some of your references below these blocks, and others above, so the latter won't be affected.

All of this should make the XML in your .csproj much cleaner and easier to read. But there's even more good news, so read on...

---

As for selecting which projects should be be marked False this will usually depend on the specific situation, but there is something fundamental everyone can and should do for starters. It's a step so basic, simple and effective and it delivers such huge MSBuild reliability improvements^1. and build-time speedup--and with little downside--that every large solution that uses the default (i.e. local per-project) C# output locations should almost always make this adjustment:

In any and every Visual Studio solution which builds multiple C# class libraries with any non-trivial number of inter-dependencies, and which culminates in building one more applications (i.e. executables):

1. Near the top the .csproj for every class library, insert the block shown above.
   REASON: There is no need for any .dll to gather any of the libraries it references into a sub-directory of its own, since no executable is ever run from that location. Such rampant copying is useless busywork and may be unnecessarily slowing down your build, possibly quite dramatically.

2. On the other hand, do not modify the .csproj for any of your solution's applications.
   REASON: Executables need to have all the privately-built libraries they need in their respective sub-directories, but the build for each app alone should be responsible for individually gathering each dependency, directly from its respective sub-directory, into the app's sub-directory.

This works perfectly because the .csproj for a class library may reference multiple other class libraries, but the .csproj for an executable usually never references another executable. Thus, for every locally-built library, the only .dll in its bin folder will be itself, whereas every locally-built application will contain the full set of locally-built libraries it references.

Conveniently, nothing changes for the referenced libraries that are not built by your solution, since these usually use instead of , and we didn't modify the former tag at all. But do note the assumption just mentioned; if it is violated by some of your projects, you may need to make some adjustments.

_{[1.] Reliability improvements could be related to file collisions that may occur when gathering the same library from multiple disjoint paths in a dependency graph, especially in concurrent builds.}