Diference between referencing a existing project and the compiled dll

From http://social.msdn.microsoft.com/Forums/en-US/csharpide/thread/c642db00-4ae2-4567-94c0-9a83ebcad294

原文：

Project references are preferable to binary references (the DLL) in almost all cases.  At runtime there is no difference but for the IDE the differences are enormous. 
Project references allow you to reference an existing project (in the same solution), get full Intellisense support, automatic recompilation of dependencies and relative path support.  With project references the underlying assembly (A) will get copied to the output of the dependent project (B) during the build (by default).  If assembly A changes it'll get picked up during the next build of B.  Furthermore you don't need to enable document generation to get full Intellisense support including the doc comments.  You also get access to the types/members you define even before you recompile the assembly.  That's because all the data is already stored in the IDE somewhere.
With binary references the assembly (A) gets copied into the dependent assembly (B) when you set up the reference.  The initial directory you got A from might be relative or absolute depending upon how it relates to B's directory.  If A and B don't share a common parent then it'll be absolute which makes moving solutions between machines more difficult.  You also lose the doc comment support unless you auto-generate the comments (an option in the project's build settings).  You must also recompile A in order to see any changes.  In my experience the IDE can sometimes get itself confused with binary references such that the XML (doc comment) and/or PDB (debug info) files can get misplaced when updating A so B doesn't pick off the changes.
In general prefer project references.  Use binary references if you are targeting an assembly that you don't have the source code for or will never build on its own (such as a corporate shared library).  In this case place the dependencies in a dedicate directory (I call mine Assemblies) off the solution directory.  This allows for relative paths in the IDE.  You are responsible for keeping this directory up to date when the binaries change.  VS should handle things from there (by default). 
Binary references are also useful for when you break up a large solution across multiple sub-solutions.  In this case you would use a separate solution for each logical area of your app.  Any related projects would be in the solution but all other projects would use binary referencing.  This simply cuts down on the solution size and build times.  The full solution would use project references.
Michael Taylor - 6/1/09
http://p3net.mvps.org

• Proposed As Answer byDavid M MortonModeratorMonday, June 01, 2009 3:40 PM
• Marked As Answer byrgcaldas Wednesday, June 03, 2009 2:17 PM

翻译理解：

大多数情况下，要首选项目引用而不是DLL引用。在运行时这两者之间没有任何区别，但是对于IDE来说两者的区别是十分巨大的。

项目引用允许你引用同一个Soulution中的项目，能够得到完全的Intellisense support, 自动的编译关系依赖和相对路径支持（automatic recompliation of dependencies and relative path support).  在项目引用中，被引用的程序集A在编译的时候默认的输出到引用程序集B的目录下。加入程序集A发生了变化，在程序集B的下次Build的过程中，程序A会被打包编译（picked up,  编译程序集B也会自动编译程序集A)。 另外，不需要通过激活document generation 来得到完全的完整的包含文档注释的intellisense support。 你也可以在编译程序集A之前得到定义的type/members。这些信息都被IDE存储在某个地方。

在程序集引用的情况下，当你的程序集B引用一个程序集A的时候，程序集A在你设置引用关系的时候被Copy到了相应的目录。根据程序集A和程序集B的目录关系，你最初得到A的目录可能是一个相对的或者绝对的路径。加入程序集A和程序集B没有一个共同的父目录，那么将采用绝对路径，这使得soulution在机器间迁移很困难。你也会失去doc comment support 除非你设置了自动生成comments(在project build setting）。 为了看到变化，你必须重新编译程序集A。以我的经验来看，IDE有时候对于二进制的引用也会出错，比如说当更新程序集A的时候，XML(doc comment)和PDB（debug info）文件会不匹配，此时B不会认为A发生了变化。

一般来说要采用project references.  采用binary reference的情况是，当你使用的程序集没有源代码，或者永远不会自己的编译（比如说公司的共享类库), 在这些情况下，将这些程序集放到专有的目录中而不是solution的目录。这样能够使IDE采用相对路径。 你应该负责程序集的更新。

binary reference 在你将一个大的Solution分成几个小Solution的时候十分有用。在这种情况下，你会给你的App设置单独的solution, 任何相关的项目都会在solution中，但是其他的projects会采用binary referencing. 这种方式很好的减少了solution的大小和编译时间。 完整的solution应该采用project references.

下面的这段话没有看明白：

Configuration settings are not shared when using references.  In general you'll store your connection strings in your configuration file.  Everybody else will either get the connection string as a parameter or query for the connection string.  A poor man's solution is to fetch the strings directly from ConfigurationManager.  This class is accessible in your class library.  It does limit the flexibility of your library though.  A one-time init call that user's must make before using your DAL is another approach that adds a little more flexibility at the cost of remembering to make the call.  A full blown solution is to use IoC (such as Unity) to access configuration information but that is overkill in most projects.

当引用程序集的时候配置文件并没有共享。