1

Is there any build time impact ? We have around 30 projects in our .Net solution and they shared projects are added by project reference. I am thinking to change to dll reference instead to see if there is any build performance gain. Did anyone have experience on similar lines ? Please share your thoughts.

user2837167
  • 221
  • 1
  • 5
  • 15
  • 1
    I would avoid it, the time gained is minimal compared to the extra debugging complexity. – Ron Beyer Apr 30 '15 at 22:57
  • Fully agree. You'll regret it the first time you spend three hours trying to resolve an issue that you thought you solved already, only to find it's because of an old DLL. – Donnelle Apr 30 '15 at 23:02
  • For performance gains, don't Copy Local. – SLaks Apr 30 '15 at 23:04
  • Only worth doing if you aren't messing with many of them at once, i.e. you have well defined api's etc. Even then as they guys say you can soend a lot of time consuming an old version of a dll. – Tony Hopkinson Apr 30 '15 at 23:05

2 Answers2

1

I don't know why DLL references would save you time, the only added expense of project references is solving the dependency tree, which is something you definitely want it to do.

Otherwise if you aren't careful you will end up with a project that breaks every time you rebuild and requires a couple normal builds to start functioning again.

Guvante
  • 18,775
  • 1
  • 33
  • 64
1

Yes, there is potentially a huge impact depending on how you have your CI set up.

The solution to this is to group logical sections of your application (data access, presentation, whatever else) into separate solutions and turn them into NuGet packages. I've had a lot of success combining TFS build, Release Management, and NuGet to automate the continuous delivery of NuGet packages from "prerelease" to "stable".

You can have it package up PDB files as well for debugging purposes, and using NuGet also helps with sharing code between different disparate projects. If Project A is using version 1.2.3 of Package X, but you've updated Package X to version 2.0.0 for Project B, Project A can happily keep consuming version 1.2.3.

One thing to keep in mind when doing a split like this:

const variables are replaced at compile time across all assemblies with the literal value. If you change a const value in Assembly A, and Assembly B references the const value, the value will not change in Assembly B if you don't recompile it. You can avoid that by using readonly fields instead of const.

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
  • Thanks for the response. Well, our solution is already grouped as Business logic, shared components, entity etc. Within a sln, we have like 5 projects that refer the above projects, which are referenced by project only for now. I am thinking to just change the build path of these projects to a common folder and the consumers refer this folder to do the dll reference instead of project reference. Will this improve any performance of build time ? Is NuGet packaging helpful in this regard ? CI setup, not sure..As far as I can guess, it takes all projects in the sln and builds them in sequence. – user2837167 May 01 '15 at 07:38
  • Don't do binary references without using NuGet. The concerns everyone else raised about binary references are 100% valid. – Daniel Mann May 01 '15 at 15:36