在多个VS 2017解决方案中引用项目的工作流程

Question

在调试和发布模式下，在多个解决方案中引用C＃项目时，我正在寻找有关最佳实践的信息。 nuget和Symbol服务器（我使用myget，并且非常喜欢它）解决了发行包的问题。

但是我对调试时该做什么感到困惑。 如果我尝试使用nuget方法，则必须在发现并解决问题时使用新的调试版本的辅助软件包myget，然后清除nuget缓存并重建主项目。 那行得通，但是很快就变得乏味。

是否可以标记nuget软件包，以便将其标记为“仅用于调试”？

我的另一个想法是在VS 2017中使用新的csproj文件格式的功能，如下所示：

  <ItemGroup Condition="'$(Configuration)' == 'Release'">
    <PackageReference Include="Olbert.JumpForJoy.UI" Version="0.5.0" />
    <PackageReference Include="Olbert.JumpForJoy.Wpf.Converters" Version="0.5.0" />
  </ItemGroup>

  <ItemGroup Condition="'$(Configuration)' == 'Debug'">
    <ProjectReference Include="..\..\WPFUtilities\J4JUI\J4JUI.csproj" />
    <ProjectReference Include="..\..\WPFUtilities\WpfConverters\WpfConverters.csproj" />
  </ItemGroup>

第一个块使用nuget包，但仅用于发行版。 第二个将主项目指向本地文件系统中的子项目。 这似乎让我从主项目中逐步完成了子项目。 但是要构建主要项目，我必须在解决方案中包括所有子项目。 没什么大不了的，但它使解决方案工作区变得混乱。

如果有人使用他们使用的其他方法，或者对我正在做的事情有反馈（特别是陷阱！），那么我无所适从。

Answer 1

因为我的所有项目都可以在开发系统的文件系统中找到，所以我意识到，无需发布调试版本的软件包。 基本上，我应该只在本地修改所有源代码，并且只发布发行包。

通过创建单个解决方案文件夹并将所有必要的子项目添加到其中，我能够解决VS解决方案中引用许多子项目的“混乱”问题。

当然，这可能会使其他尝试使用我的开源软件的人的生活复杂化-他们必须克隆所有辅助软件包以及他们感兴趣的任何主要软件包-但这确实是可行的。