我们有很多内部库,我们希望在公司内部的项目之间共享。这些是一些要求:
- 库资源存储在与最终项目分开的存储库中
- 最终项目包括通过NuGet提供的库
- 在进行最终项目时,必须有可能轻松检查任何给定库的源代码
设置我们的私有NuGet存储库不是问题,但是管理源代码是有问题的。我们试图通过暴露源服务器的来源和它还挺作品,但并不完全:VS下载源在调试外部代码,而不是当你尝试导航到定义/实施。基本上,您只能在调试时使用源代码,这不是我们所需要的。
因此,问题是:
- 有哪些方法可以提供对内部库源代码的访问权限,而无需将代码放在同一存储库/解决方案中
- 有没有办法设置Symbol服务器/ NuGet feed组合,以便VS使用符号进行导航,而不仅仅是调试?
选择使用ReSharper /其他加载项。
2
我们发现使用Nuget来管理内部项目不是很理想;我们最终将其删除以支持项目和DLL引用。我很想听到能够完成这项工作的人的来信。
—
罗伯特·哈维
您是否还为与NuGet软件包中包含的dll对应的pdb文件设置了符号服务器?
—
RubberDuck
我们目前的工作场所中的设置完全相同。NuGet服务器(包含不带 PDB的DLL )和符号服务器(包含DLL,PDB和源)。我们也有同样的问题(仅在调试时才检索源和PDB)。@RobertHarvey:NuGet软件包管理器是可怜的NuGet客户。它不能区分直接依赖性和瞬时依赖性,并且需要愚蠢的“合并”动作。我们切换到Paket,此后再也没有回头。它使包裹管理理智而可忍受,令人愉悦。
—
Allon Guralnek '16
我不得不问-尽管我认为这不是一个不合理的要求-为什么您需要能够查看共享/通用软件包?从理论上讲,至少这些应该记录在案的黑匣子,而查看内部的需求应该是例外而不是规范。无论如何,它们都可以在您的源代码库中使用,因此,下载解决方案进行检查应该是不容易的。我可以看到许多原因,为什么这种情况或部分情况可能并非完全如此,但仍然值得提出。
—
Murph
@Murph-我不是OP,但是根据我的经验,文档从未捕获我想要的细节。我需要清理此状态还是被呼叫者?这到底是什么转义?这些过载有何不同?这些实体是否支持平等?如果是,则基于什么?这个通话的大概复杂度是多少?唯一值得拥有的详细文档是(干净的)资源,因为总有和通常将是文档编制者从未考虑过但对您而言很重要的事情。更糟糕的是,复杂的文档不可避免地包含错误并变得过时。
—
伊蒙·纳邦