I have a single solution full of projects that are to be shared amongst my organization as general nuget packages. The solution is encompassed by one git repository and we have TeamCity running our builds for us, although we are not overly advanced in that we manually kick off the Teamcity builds when we are ready to generate/publish a new Nuget package for a given project in the solution, every project has its own TeamCity build configuration.
When built, the projects generate nuget packages via the .csproj <project/> tag: GeneratePackageOnBuild we also control the versioning via version tags that are populated through build properties from TeamCity. This works great. Where we run into problems is managing the project references/dependencies that the projects have on themselves. I can't seem to understand how to do this correctly. For example:
-- Solution
----- Project A v1.0.6
----- Project B v1.0.1
Project A (v1.0.6) has a dependency on Project B (v1.0.1). Let's say I change Project A (v1.0.7) and Project B (v1.0.2) at the same time. I can't have Project A reference the nuget package of Project B since it isn't built yet so I use Project References. However, that causes the nuget package of Package A (v1.0.7) to assume it has the same build number as Project B (v1.0.2) - which it doesn't. Thus, when someone consumes Project A they are told to look for a version of the dependency Project B that doesn't exist (v1.0.7 in the example). To resolve this, I added the following in Project A .csproj:
<ProjectReference Include="..\Company.ProjectB\Company.ProjectB.csproj" ExcludeAssets="All" />
However, now the consumer doesn't know of the Project B dependency (as it no longer shows up in the Nuget package dependency) and when they figure out they need it, they'll get a runtime error when using Project A stating that it is still looking for Project B v1.0.7 which obviously doesn't exist.
How does one intelligently handle project referencing when generating nuget packages without a nuspec? I'd like as little manual intervention as possible.
My one other solution is to use Nuget package references but that means Project B has to build and deploy before a developer can get to work on Project A.
By design, when you pack a project that has project references, those dependent projects are added as NuGet dependencies, with the minimum version being each project's current version at the time of pack. To understand why, imagine you made a breaking change to ProjectB, and fixed ProjectA to work with it. If you publish ProjectA, but with a NuGet dependency of an old version of ProjectB, then NuGet users of ProjectA will crash at runtime because the version of ProjectB they're using is incompatible. There's no way for NuGet to know this.
Therefore, if you want to increment ProjectA's version without incrementing the dependency version of ProjectB, make them in separate commits. Otherwise, publish new versions of both ProjectA and ProjectB at the same time.
来源：https://stackoverflow.com/questions/52881585/a-solution-needed-for-referencing-nuget-packages-from-projects-in-the-same-solut