Workflow for Referencing Projects in Multiple VS 2017 Solutions

Question

I am looking for information on best practices when referencing C# projects in multiple solutions, in both debug and release modes. nuget and symbol servers (I use myget, and really like it) solves that for release packages.

But I'm confused about what to do when debugging. If I try to stick with the nuget approach, I have to a new debug version of subsidiary packages to myget as I find & fix problems, and then clear the nuget cache and rebuild the main project. That works, but it quickly gets tedious.

Is there a way to tag a nuget package so that it's marked as "for debug use only"?

Another idea I had was to use the capabilities of the new csproj file format in VS 2017, like this:

  <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>

The first block uses the nuget packages, but only for release builds. The second points the main project at the subsidiary projects in my local filesystem. This would seem to let me step through the subsidiary projects from within the main project. But to get the main project to build, I have to include all the subsidiary projects within the solution. That's not a big deal, but it clutters up the solution workspace.

If anyone has other approaches they use, or feedback on what I'm doing (particularly gotchas!), I'm all ears.

Do you want to handle the C# projects with nuget in both debug and release modes? AFAIK, NuGet package is normally store just a single set of assemblies for a particular target framework. It is not really designed to ship a debug and release version. That seems to be no better way here except that you have already tried, have to a new debug version of subsidiary packages to myget, although it makes you feel tedious. For detail info, you can refer to: https://stackoverflow.com/questions/13488280/best-practices-with-nuget-debug-or-release — Leo Liu, Jun 12 '17 at 08:15

score 0 · Accepted Answer · answered Jun 12 '17 at 16:42

Because all of my projects are available within my development system's file system, I realized that it was unnecessary for me to publish packages for debug versions. Basically, I should just modify all the source code locally, and only publish release packages.

I was able to solve the "clutter" problem of having a lot of subsidiary projects referenced in a VS solution by creating a single solution folder, and adding all the necessary subsidiary projects to it.

Granted, this may complicate the life of anyone else trying to use my open source software -- they'd have to clone all the subsidiary packages as well as whatever primary one they're interested in -- but that's certainly doable.

Workflow for Referencing Projects in Multiple VS 2017 Solutions

1 Answers1