C# Nuget package is not up-to-date

[RegiSV2]

Hello!

I am not shure, if this is an official Nuget package of Flatbuffers:
https://www.nuget.org/packages/DevZH.FlatBuffers/

If it is, are there any plans on updating it? There is still no 1.5.0 version.
If it is not, is it possible that an official one eventually comes out?

[aardappel]

Not sure who created that, but it isn't maintained by us. Maybe contact DevZH?

Should we have an official one? Is there a way Nuget can pull from our official repo automatically?

[ZacLiveEarth]

If there were an official Nuget package, I'd like to see some way to handle the existing #define symbols. Right now the C# compiler can define BYTEBUFFER_NO_BOUNDS_CHECK or UNSAFE_BYTEBUFFER as performance optimizations. The official Nuget package should have a way to enable these optimizations as well.

I'm not familiar enough with Nuget to know what the idiomatic way to approach this would be. I just want to raise it as a concern that I'm interested in.

[SimonCropp]

+1 for having an official nuget package

[petertiedemann]

Libraries that are not on www.nuget.org, basically do not exist from the point of view of your typical C# developer. Having to copy code from a subfolder of a repository in order to get the necessary dependencies to compile the auto-generated code is really weird.

The natural way to handle this with is first of to include a csproj file with the C# code in this repo (targeting netstandard preferably). As part of your normal CI ( i can see that you are using appveyor?), you then need to do dotnet build+pack to get a nuget you can then publish to nuget.org. Normally that would be done as part of normal CI on a release build. It would of course also be nice to include flatc.exe in the nuget.

Doesn't google already have a nuget.org account that can be used to publish?

[petertiedemann]

As an example of what i mean, i updated the csproj here:

https://github.com/petertiedemann/flatbuffers/pull/1/files

I am not familiar with your build system however. Would you be doing the building and publishing on AppVeyor? And how do you normally handle incrementing versions? It looks like its manually updated in for example pom.xml and package.json?

[aardappel]

@petertiedemann thanks for the help, because I am definitely not familiar with nuget.

So far, we use AppVeyor for CI only.. it does not build any distribution files. Even if it did, wouldn't we want to to only update the nuget package for major version releases as opposed to every commit?

Currently, when I release a new tagged version, I do an npm publish manually for JS. Other languages do not get an automatic package currently, I have yet to set this up for Maven (if anyone wants to help, that be welcome).

We may have a nuget account, but Google has a lot of teams.. will have to see who owns this.

As for your change, we can't move to the VS2017 image, since it drops support for VS2010, which we're still testing against.

Help making our project files "nuget ready" would be appreciated indeed.

@evolutional who has worked the most on C# and may have an opinion.

[evolutional]

I think an official NuGet package would be a great idea. I'm a C#/C++ dev by trade and consume 99% of my dependencies as binaries from NuGet.

If we were to publish an official NuGet package, I'd suggest we create a solution with various .NET projects in it. These projects would be set up with the various defines & safe/unsafe code builds - we'd likely publish these as separate packages, allowing people to select & consume the one they need.

I would publish the NuGet packages at the point of creating an official FlatBuffers release - @aardappel I'm not sure how you prepare the releases or what steps you go through, but it'd be a good place to publish NuGet packages.

[evolutional]

@aardappel you might wanna check with the Protobuf team on how they handle their NuGet packages on there.

[aardappel]

@evolutional thanks! Do either of you want to set up these projects such that at release time all I have to do is run some kind of command? I'll go dig up our account.

[kwaclaw]

FYI - I just forked FlatBuffers and converted the C# project to the new .NET core format, adding support for netstandard 1.1. This is published as a Nuget package: https://www.nuget.org/packages/KdSoft.FlatBuffers/

Note: I changed the C# namespace from FlatBuffers to Google.FlatBuffers (similar to how it is with protocol buffers). This means you have to use the modified flatc.exe code generator included in the package.

[stale]

This issue has been automatically marked as stale because it has not had activity for 1 year. It will be automatically closed if no further activity occurs. To keep it open, simply post a new comment. Maintainers will re-open on new activity. Thank you for your contributions.

[barreyra]

Ping

[abbotware]

@aardappel - Still no official nuget?

Its gotten a lot easier to create and publish nuget packages these days:
https://docs.microsoft.com/en-us/nuget/quickstart/create-and-publish-a-package-using-visual-studio
https://docs.microsoft.com/en-us/nuget/quickstart/create-and-publish-a-package-using-the-dotnet-cli

[aardappel]

Like I said in my last comment, if someone is willing to set it all up such that all I have to do is run a script, that be welcome. Looking at the second link it still requires accounts and keys and stuff.. so I presume that means its hard to avoid me doing the work myself :(

I just added a note at the end of https://github.com/google/flatbuffers/wiki/FlatBuffers-release-process to attempt a C# release whenever I end up doing 1.12 anyway.. but no promises :)

[nathansoz]

@aardappel I'm considering using flatbuffers for a project at Microsoft and am probably going to end up creating a tool package for this. This would allow for idiomatic distribution and invocation of flatc as part of the C# (msbuild) build process. Would you be interested in taking a contribution upstream for this? Would you want the CMake build for windows to produce the package or would you prefer for it to be an separate process that is just driven by a script?

[aardappel]

@nathansoz yes, I'd welcome upstream contributions to improve this, thanks :)

As for running it from the standard CMake build, that depends on what tools it would require, since if requires Windows users to install additional tools they otherwise don't need, a separate script would be better.

[nathansoz]

I'm also realizing that a separate script would be good for other reasons. A good nuget package should include flatc binaries for Linux, Windows, and macOS so that cross platform builds work.

The ideal script will probably be run on Linux or macOS and point at compiled outputs for all three platforms. I'll have to look at what the linux binary links to in order to see how portable a binary compiled on one distribution is with another. Generally if the binary is mostly self contained (only links to c/c++ libraries) you can get away with compiling on an older distro and it will run on newer distros.

The script I end up writing for our internal build of the package will probably look similar to the above, so when we have something working I'll submit a PR.

[aardappel]

Yup, binary is very self-contained and does not require a very recent compiler. Don't you potentially run into issues if you dynamically link glibc though?

[nathansoz]

Generally glibc maintains a stable ABI that allows you to link against an older version and still run on a newer version. A good example of software taking advantage of this is the go compiler (grabbed from their generic linux download here). It looks like they require a minimum of glibc 2.3.2 (see below). My distribution of Ubuntu 18.04 ships with glibc 2.27 and the executable works fine.

I'd also think that any of the msbuild targets that the package provides would need to allow a flatc compiler override in case someone wanted to drop in their own binary for whatever reason (maybe they are running linux on arm64).

nsosnov@nsosnov0:~/go/go$ objdump -T bin/go

bin/go:     file format elf64-x86-64

DYNAMIC SYMBOL TABLE:
0000000000633f00 g    DF .text  000000000000005a  Base        crosscall2
0000000000633eb0 g    DF .text  0000000000000050  Base        _cgo_panic
000000000045c6f0 g    DF .text  0000000000000019  Base        _cgo_topofstack
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 __errno_location
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 getnameinfo
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 getaddrinfo
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 freeaddrinfo
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 gai_strerror
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 stderr
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 fwrite
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 vfprintf
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 fputc
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 abort
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 pthread_mutex_lock
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.3.2 pthread_cond_wait
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 pthread_mutex_unlock
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.3.2 pthread_cond_broadcast
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 pthread_create
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 nanosleep
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 pthread_detach
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 strerror
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 fprintf
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 free
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 malloc
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 pthread_attr_init
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 pthread_attr_getstacksize
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 pthread_attr_destroy
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 sigfillset
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 pthread_sigmask
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 mmap
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 munmap
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 setenv
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 unsetenv
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 sigemptyset
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 sigaddset
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 sigaction
0000000000000000      DO *UND*  0000000000000000  GLIBC_2.2.5 sigismember

[aardappel]

FlatBuffers was just updated to 1.12.. does anyone here want to "own" the C# package release process?

See also 1.12 release thread: #5795
Release process (item for C# at bottom): https://github.com/google/flatbuffers/wiki/FlatBuffers-release-process

[evolutional]

Reading the thread here, there seems to be a few things - mostly due to the use of the defines used for various performance optimisations.

Do you see these being separate packages?

@aardappel are you using github actions at all? I think there's a few actions available now that would do the publishing side of it.

It looks like @nathansoz was looking at making a tool package which included the flatc compiler too - are we waiting for that, or do you want to move on looking at package publishing of just the flatbuffers net components?

[aardappel]

@evolutional no, haven't used them at all yet, but it be fine to use them for this purpose. Does that simplify all the account/signing stuff required? I'd really like all this package management to depend less on me :)

[github-actions]

This issue is stale because it has been open 6 months with no activity. Please comment or this will be closed in 14 days.

[barreyra]

Ping

[kwaclaw]

I updated my fork to v1.12 and published the C# project as a Nuget package, supporting netstandard 1.1 and 2.0: https://www.nuget.org/packages/KdSoft.FlatBuffers/

Note: I changed the C# namespace from FlatBuffers to Google.FlatBuffers (similar to how it is with protocol buffers). This means you have to use the modified flatc.exe code generator included in the package.

[evolutional]

I think changing it to Google.FlatBuffers is a good change to make in the main branch. When I did the original port I considered it, but decided to keep parity with Java.

…

________________________________ From: Karl Waclawek <notifications@github.com> Sent: 20 September 2020 10:55 PM To: google/flatbuffers <flatbuffers@noreply.github.com> Cc: Oli Wilkinson <oli@evolutional.co.uk>; Mention <mention@noreply.github.com> Subject: Re: [google/flatbuffers] C# Nuget package is not up-to-date (#4162) I updated my fork to v1.12 and published the C# project as a Nuget package, supporting netstandard 1.1 and 2.0: https://www.nuget.org/packages/KdSoft.FlatBuffers/ Note: I changed the C# namespace from FlatBuffers to Google.FlatBuffers (similar to how it is with protocol buffers). This means you have to use the modified flatc.exe code generator included in the package. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#4162 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAREX3VLBI2YRK62LHUE3B3SGZ23LANCNFSM4C6WB44A>.

[kwaclaw]

Should be in the package under Tools.

…

On Sun., Mar. 14, 2021, 11:57 a.m. Kyle Tse, ***@***.***> wrote: I updated my fork to v1.12 and published the C# project as a Nuget package, supporting netstandard 1.1 and 2.0: https://www.nuget.org/packages/KdSoft.FlatBuffers/ Note: I changed the C# namespace from FlatBuffers to Google.FlatBuffers (similar to how it is with protocol buffers). This means you have to use the modified flatc.exe code generator included in the package. Where can I find the modified flatc.exe to generate Google.FlatBuffers namespace .cs files? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4162 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFABKX5MZLTKHYPN7WNUCLTDTMFXANCNFSM4C6WB44A> .

[github-actions]

This issue is stale because it has been open 6 months with no activity. Please comment or this will be closed in 14 days.

[goaaats]

Still something that would be nice to have

[zamazan4ik]

Any chance to update https://www.nuget.org/packages/FlatBuffers.Core/ to the latest Flatbuffer 2.0.0?

[aardappel]

As I've said before, making this more automatic would require someone to set up some kind of publishing, or do it manually. I myself have zero familiarity with nuget.

[dbaileychess]

Good news, this is progressing internally. We will have an official NuGet package at some point!

[dbaileychess]

It's here! https://www.nuget.org/packages/Google.FlatBuffers/2.0.8-beta.1

Huge shout out to https://github.com/jskeet for helping with this effort internally at Google.

[dbaileychess]

I will be bumping to a non-prerelease version after I get some field testing that everything is working.