我有一个大的c#解决方案文件(~100个项目),我正在努力改善构建时间.我认为"复制本地"在很多情况下对我们来说都是浪费,但我想知道最佳做法.
在我们的.sln中,我们有应用程序A取决于程序集B,它取决于程序集C.在我们的例子中,有几十个"B"和一些"C".由于这些都包含在.sln中,我们正在使用项目引用.所有程序集当前都构建为$(SolutionDir)/ Debug(或Release).
默认情况下,Visual Studio将这些项目引用标记为"复制本地",这会导致每个"C"被复制到$(SolutionDir)/ Debug中,对于构建的每个"B".这似乎很浪费.如果我只关闭"复制本地",会出现什么问题？大型系统的其他人做什么？
跟进:
很多响应建议将构建分解为较小的.sln文件......在上面的示例中,我将首先构建基础类"C",然后是大量模块"B",然后是一些应用程序,"一个".在这个模型中,我需要对来自B的C进行非项目引用.我遇到的问题是"Debug"或"Release"被添加到提示路径中,我最终构建了我的Release版本的"B"反对"C"的调试版本.
对于那些将构建拆分为多个.sln文件的人,如何管理这个问题？
我找到了有关Microsoft Visual Studio"额外"文件的以下信息:
我的问题是,有没有办法让我无法生成.pdb,.manifest和vshost.exe文件？或者他们绝对必要吗？
我刚刚注意到,在调试之后,它仍然在我的机器中显示为一个正在运行的进程,因为我已经关闭它所以让我担心.
假设我们有一个由一个可执行文件和5个库组成的应用程序.通常所有这些都将包含在一个目录中,并且将从那里加载库.
是否有可能这样做,例如我可以在一个名为Lib的目录中拥有一些库,其余的名为Lib2？这样应用程序目录只包含可执行文件本身,其他程序集将包含在各种逻辑目录中.
我怎样才能做到这一点？我想知道如何加载程序集,以及如何使应用程序的构建将程序集放在正确的目录中.