目前尚不清楚它们的用途。但我确信有一个假设的概念。
我认为像客户端 - 服务器系统这样的东西会存在于一个解决方案中。
项目是否总是可执行的，或者是为程序集构建的项目？
我假设有多个具有共享代码的可执行文件应该转到代码的一个位置。那会是哪里？一个单独的项目？
初始化时，项目似乎是应该是应该更加独立的实体。所以我认为很多人最终将相对随机的程序归结为一个解决方案。
使用git进行分支时，通常在单个解决方案中有多个独立的分支方案（专注于特定项目）？
我要求的是一些一般性指导原则。
答案 0 :(得分：1)
在我看来，一个解决方案应该被视为构成你的最终应用程序的东西＆＃34;。 在解决方案中，项目可以是此应用程序的任何部分，例如可执行文件，程序集等
如果多个可执行文件共享相同的代码，您只需要在每个需要它的项目中引用包含代码的程序集。
有关Microsoft如何看待它的详细信息，请查看此页：http://msdn.microsoft.com/en-us/library/b142f8e7.aspx
答案 1 :(得分：1)
来自MSDN library：
解决方案包含您创建自己需要的项目 应用。解决方案包括一个或多个项目，以及文件和 有助于将解决方案定义为整体的元数据。
[...]
项目用于逻辑管理，构建和调试的解决方案中 组成您的应用程序的项目。项目的输出是 通常是可执行程序（.exe），动态链接库（.dll） 文件或模块等。
例如，我正在使用一个结构良好的计算机图形开发框架。它作为包含十几个项目的单个解决方案实施，例如Core，OpenGL和Direct3D。每个项目都被编译为自己的.dll，因此只使用一些框架代码的应用程序不需要随完整框架一起提供，如果整个项目驻留在单个项目中的话。
并非所有项目都会产生.dll个文件，例如其中一个只是一个自定义＆＃34;新项目＆＃34; Visual Studio向导（该向导，一旦安装，可用于轻松创建可自定义的＆＃34;空白＆＃34;模板应用程序，该应用程序已预先配置为能够使用框架并包含一些框架代码）。
将解决方案用作这些密切相关的组件的容器，这些组件甚至可能以复杂的方式相互依赖，或以其他方式共享一些代码，资产或文档，有助于保持组织良好并确保正确的构建顺序。对不同部分使用不同的项目有助于将更大图像（解决方案）的逻辑组件彼此隔离。
回答你的问题：
我假设客户端 - 服务器系统之类的东西会存在于其中 溶液
我会说＆＃34;是＆＃34;但是不要接受我的话。
项目是否总是可执行的，或者是为程序集构建的项目？
没有。除了可执行文件和库之外，我还给出了一个项目生成Visual Studio向导的示例。此外，解决方案中的不同项目可能使用不同的编程语言。
我假设有多个具有共享代码的可执行文件应该转到代码的一个位置。那会是哪里？一个单独的项目？
是的，共享代码将是一个生成库的单独项目。如果该库非常通用，它可以放在它自己的，完全独立的解决方案中，并与使用它的应用程序隔离开发/维护/分发。
如果可执行文件密切相关并且已经共享相同的解决方案，并且共享代码对于该解决方案解决的问题非常具体，则库项目也可以包含在同一解决方案中，而不是拥有自己的
初始化时，项目似乎是应该是应该更加独立的实体。所以我认为很多人最终将相对随机的程序归结为一个解决方案。
是的，nothings阻止您将完全独立的项目集中在一个解决方案中。但你这样做会获得什么吗？这真的是你在逻辑上组织工作的好坏（或者很糟糕）。
使用git进行分支时，通常会有多个独立的分支 单一解决方案中的分支方案（专注于特定方案） 项目）？
我没有足够的经验知道它是否典型，但这听起来确实合理。