fixes 3331 - removes nuspec from microservice runtime #3368
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ct a happy nuget package
|
Lightbeam link |
|
Lightbeam link |
|
okay, need to do a few more things on this,
|
|
Lightbeam link |
|
Lightbeam link |
|
Lightbeam link |
|
Lightbeam link |
|
reviewed by Gabriel |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 👍
in a nuspec file, you can define dependencies of your package, and that is also great! 👍
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.commondll or whatever (that is just one example of many), but we don't publishbeamable.tooling.commonas 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.Runtimerelease package tries to sneak in extra.dllfiles into its manifest than just theBeamableBasedll. That used to happen by overriding thenuspecfile.But that stunk, because it meant we also needed to copy/paste all the nuget references from the
.csprojfile into the.nuspecfile. 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 thenuspecfile.Mongo.Driverdependency was being referenced by a sub project,(beamable.server.common), but was only getting into theBeamable.Microservice.Runtimepackage 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.0build 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.