Proper use of submodules in .NET solutions

I have a library I wrote with a structure like this:

SolutionA\
--Source\
  --Core\
  --Tests\
--Tools\
  --TestFramework\
  --MockTool\
SolutionA.sln

I want to include this as a submodule for SolutionB. If I use this entire structure as a submodule, it would get a bunch of stuff that SolutionB doesn't care about; it doesn't care about SolutionA.sln; it doesn't care about Tests\; it doesn't care about Tools\. Really, SolutionB only cares about Core\.

It looks like I need a separate repository for Core\. So is it usu开发者_开发百科al practice to have two repositories for .NET solutions whose source is used by other solutions? One for only the (non-test) code itself (plus needed libraries), and one for the test tools and solution file?

Solutions are simply containers for one or more projects; which may fall under the same "solution" folder or somewhere externally.

If you have a project, in this case "Core" then you can reference that project source directly from one or more solutions. In this case, SolutionA and SolutionB.

The extraneous stuff like Tests\, TestFramework\, MockTool\, etc, unless required by Core, don't have to be included in your other solution.

Make sense?

You COULD solve this with git-submodules (your tag leads me top believe that you use git). I don't know what the "usual practice" for stuff like this is.

As reply to my question about how to deal with submodules, dirk proposed to use nuget (the package manager for the .NET Framework. see http://nuget.org) to solve a related problem. Seems to be a good fit for you, as you would get controlled updates for the dll, dependency management if you need it and (at least at the client side) good tool support.

Scott Hanselmann has a good article how to integrate nuget into Continous Integration.