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.