I suggest you ...

Make it easier to work with CopyLocal=False on references

If you have a large solution (ours has 30 projects) where some or all of the projects reference multiple assemblies that aren't in the GAC then by default Visual Studio ends up copying all of those referenced assemblies around a LOT during a build. Setting CopyLocal to False on all the references stops them getting copied around, but then you need to come up with another way of getting them all into the output folder so that you can debug, run unit tests, etc.

It would be nice to have an easy to select build option that worked back along the chain of assembly and project references and copied all the necessary files into the output folder. That way you could set all the references to CopyLocal=False and then enable the new option ("CopyDependenciesToOutputDir"?) only on executable and unit test projects.

41 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    swythanswythan shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    6 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • DaverDaver commented  ·   ·  Flag as inappropriate

        I really love Visual Sutdio when I'm coding. But when it comes to Solution, Project Structure and References there is more to be desired. When you think about it, shouldn't there be some sort of reference management at the solution level? You can end up having a lot of redundant references of different versions in different projects.When the projects are built or deployed, then the references should be automatically placed where they are needed. Visual Studio forces me to spend a significant amount of developement time managing files! Not writing code, elegant algorithms, **** GUIs, etc.! We are all so bogged down with basic stuff that should be automated that we will never get to build amazing software.

      • ian.ringroseian.ringrose commented  ·   ·  Flag as inappropriate

        Another thought: Why can’t “copy on modified” files system “soft links” be used to reduce the number of physical file copes that are created?

      • ian.ringroseian.ringrose commented  ·   ·  Flag as inappropriate

        A “out of the box” config that set Copy Local too false on all projects, and put all output in a single folder would be great. Is must work the same way with MSBUILD on a build server that does have Visual Studio installed.

      • swythanswythan commented  ·   ·  Flag as inappropriate

        As an example, one of our solutions has 29 projects, of which 4 are executables and 1 is unit tests. (One reason there are so many projects is that it is using Prism, so there are a lot of "interfaces" projects). Each of those projects have quite a few references of their own.

        A standard VS build (CopyLocal=True) does 2GB of disk reads and 1.6GB of disk writes, mostly dlls. Changing all the references to CopyLocal=False, configuring all the projects to build to the same output directory and then adding a build action to copy everything out of our lib folder to the output folder reduces that to <200MB each (I haven't got the exact figures to hand).

        It also reduces the rebuild time by 40sec on an SSD (1:47 => 1:07) and 1min on a standard HDD (2:40 => 1:40).

        Unfortunately my method for copying the references introduces problems (e.g. file locking issues and not supporting Clean properly) so I've not rolled it out.

      Feedback and Knowledge Base