My favorite way to develop applications is microservices, or at least smaller services that can separate concerns a little bit. In our current application, there is an API we've created with an OAS document and an auto-generated .NET SDK based on the document. We then have a web console that makes calls to the backend API using the SDK and, ideally, customers would also use the SDK.

So my question to everyone is: what is the best "flow" to develop a NuGet package?

Currently, we have pipelines which publish the NuGet package of the SDK to our internal NuGet repository on every commit within a merge request. We have a manually incrementing semver with an additional build number tacked on (for example 1.2.3+abc123).

Now this works pretty well, but we often run into problems where a tester's NuGet doesn't pull down the latest version based on the build number if it detects it has the proper semver number. For example, if we create 1.2.3+abc456 NuGet won't pull down this version as long as it has the original 1.2.3+abc123 in its .nuget/packages directory. Testers and developers have to manually delete the version from the packages directory and do a fresh restore.

So, is there a better way to do build numbers? Or should I be deleting the NuGet package from the private repository every time (doesn't sound ideal...)?

The other part of this question is what is the best way to develop and test NuGet packages locally?

My current flow is a PowerShell script which will create the new .nupkg file, publish it to a local/filesystem NuGet directory with some random semver number (i.e., 9.9.9), update the .csproj with the version (temporarily), and then do a fresh dotnet restore on the target project. However, this can be cumbersome and feels like something that should be built into the dotnet command. Am I missing something, or is this really the best way to develop locally?

top 5 comments

sorted by: hot top controversial new old

[–] Lmaydev@programming.dev 5 points 7 months ago* (last edited 7 months ago)

I would use a dash which would make those builds pre-releases and omit the build number on the main branch

You can use SourceLink to track the commit. Or you could tag the main branch on a build.

is not supported by nuget.

[–] Rogue@feddit.uk 2 points 7 months ago* (last edited 7 months ago) (1 children)

I can answer part of your question. You're misusing build metadata according to the semver 2 spec.

Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence.

https://semver.org/spec/v2.0.0.html

So 1.2.3+abc456 and 1.2.3+abc123 are the same version, hence why it's not updating.

If you replace + with - then they would be evaluated differently: 1.2.3-abc456 > 1.2.3-abc123

[–] notnotmike@programming.dev 1 points 7 months ago

I don't think misusing is the correct term, just expecting too much out of it. We're attaching it properly as the build metadata, just wishing it were able to be used when determining package versions.

I will likely start using the - format for prerelease versions, but I may not choose the commit SHA as the identifier. I think I'd prefer an incrementing ID that's a little more descriptive of what order builds occurred in. I think something like the GitLab IID may suffice, but I'll have to dive deeper and see my best options

Thanks

[–] RonSijm@programming.dev 1 points 7 months ago (1 children)

I suppose this is a bit of an StackOverflow answer "Opinions needed: Best way to develop NuGet packages" - Answer: "Don't. Do something else instead"

But seriously, why do you need internal NuGet packages? To distribute libraries, I guess, but then as you mention distribution is already going poorly, and local dev and testing is as well.

I switched from putting everything into NuGet to putting everything into Git Submodules - and just Submodule all the libraries that I need in a project, instead of using internal NuGets

[–] notnotmike@programming.dev 2 points 7 months ago

I mention in the post, but we do make the Nuget package publicly available, so it's got to be used.

I also feel that if a streamlined process were in place it would be a very popular way to develop mocroservices