Impact of adding dll reference vs project referenc

问题:

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.

回答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.

回答2:

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.