Nuget and Dotnet have become friendlier over the years, but in the past, they were sort of at odds and trying to compete with eachother.
In a csproj file, you can define dependencies of your project, and that is great :+1:
in a nuspec file, you can define dependencies of your package, and that is also great! :+1:
But technically, those dependencies (of the project vs the package) can be different, and oh boy, here we go. There is a semi common issue in large dotnet solutions where you want to publish a package that depends on projects that don't have published packages. That is our problem. We want to publish Beamable.Microservice.Runtime, but our internal code organization dictates we need the beamable.tooling.common dll or whatever (that is just one example of many), but we don't publishbeamable.tooling.common as a nuget package on its own, because at the moment, it doesn't make sense as a customer product on its own.
Even if we did publish it, like we publish beamable.common, our build pipeline would need large changes to be able to handle the publication of the packages in sequence with the correct interdepenencies.
So, our Beamable.Microservice.Runtime release package tries to sneak in extra .dll files into its manifest than just the BeamableBase dll. That used to happen by overriding the nuspec file.
But that stunk, because it meant we also needed to copy/paste all the nuget references from the .csproj file into the .nuspec file. There doesn't seem to be a good way to merge the deps defined in one file with the other file; its all or nothing on the nuspec file.
it stinks, and leads to bugs... In fact, there was a bug! The Mongo.Driver dependency was being referenced by a sub project, (beamable.server.common), but was only getting into the Beamable.Microservice.Runtime package because of the nuspec configuration, not through proper project references, which I'm sure is part of the culprit for why mongo references always seem broken...
our build process has this strange extra detail for ONLY the Beamable.Microservice.Runtime, where it needs to track this stupid nuspec file
our handling of multi-framework was crummy, because the nuspec was only copying in the net6.0 build artifacts, which meant we couldn't support multiple dotnet environments. I also wonder if this is responsible for some of the recent net8.0 pain.
SO!
I deleted the nuspec file and figured out how to reproduce everything we want in the csproj file.
the common project now references the beamable.common library in order to get access to the build-target, but we need to make sure it has the latest version of the reference...
test more stuff,
research if we can inject properties BEFORE the build stuff...
Nuget and Dotnet have become friendlier over the years, but in the past, they were sort of at odds and trying to compete with eachother.
In a csproj file, you can define dependencies of your project, and that is great :+1: in a nuspec file, you can define dependencies of your package, and that is also great! :+1:
But technically, those dependencies (of the project vs the package) can be different, and oh boy, here we go. There is a semi common issue in large dotnet solutions where you want to publish a package that depends on projects that don't have published packages. That is our problem. We want to publish
Beamable.Microservice.Runtime
, but our internal code organization dictates we need thebeamable.tooling.common
dll or whatever (that is just one example of many), but we don't publishbeamable.tooling.common
as a nuget package on its own, because at the moment, it doesn't make sense as a customer product on its own.Even if we did publish it, like we publish
beamable.common
, our build pipeline would need large changes to be able to handle the publication of the packages in sequence with the correct interdepenencies.So, our
Beamable.Microservice.Runtime
release package tries to sneak in extra.dll
files into its manifest than just theBeamableBase
dll. That used to happen by overriding thenuspec
file. But that stunk, because it meant we also needed to copy/paste all the nuget references from the.csproj
file into the.nuspec
file. There doesn't seem to be a good way to merge the deps defined in one file with the other file; its all or nothing on thenuspec
file.Mongo.Driver
dependency was being referenced by a sub project,(beamable.server.common)
, but was only getting into theBeamable.Microservice.Runtime
package because of the nuspec configuration, not through proper project references, which I'm sure is part of the culprit for why mongo references always seem broken...Beamable.Microservice.Runtime
, where it needs to track this stupid nuspec filenet6.0
build artifacts, which meant we couldn't support multiple dotnet environments. I also wonder if this is responsible for some of the recent net8.0 pain.SO!
I deleted the nuspec file and figured out how to reproduce everything we want in the csproj file.