Protobuf: Investigate new .NET monikers / support .NET Core
Before release, we should check
https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/standard-platform.md
It may affect how we target this.
jskeet
All 18 comments
I have experience with porting C# code to coreclr (see https://github.com/dotnet/orleans/issues/368) and can potentially help with that.
gabikliot
on 13 Nov 2015
@gabikliot That's great - thanks very much. First question nice and early - we're currently using the "traditional" csproj approach, and targeting profile259. Am I right in saying that so long as we put everything in the right places in the Nuget package, that will still work as an approach? If we need to move to project.json, I will start that part now...
jskeet
on 13 Nov 2015
Yes, that is my understanding as well: that we can keep using .csproj and just distribute the nugets.
As far as I understood, one needs project.json if the development of the project itself will be done not via Visual studio and not on Windows.
As long as one builds this project (protobuf project) on Windows with Visual Studio, we can keep using .csproj for that and publish nugets. The projects that will use protobuf nugets, if they are targeting corefx or what ever other profile and build their project on Linux, they will need to use project.json.
Of course, if this indeed happens (people start using C# protobufs on Linux), those people will most likely ask to be able to also build the protobuf project themselves on Linux (just since people in OSS want the ability to be in full control and be able to change/build the dependent libraries themselves). So in this case we would also need to give them the ability to build protobufs on Linux and then we would indeed need to provide project.json.
That is my current understanding of the situation. I am not 100% sure (since we haven't finished Orleans's port to coreclr so I haven't actually done the full process till the end yet), but that is how I understand it.
My advice would be to focus first on being code compatible with coreclr. One can use the .NET Portability Analyzer to find the gaps. We did that extensively with Project Orleans here: https://github.com/dotnet/orleans/issues/368.
That part is the hardest part, as they removed a lot of APIs.
Once this is done and indeed fully works on Linux, adding project.json should be easy.
Another thing to consider is that the whole .NET core is still work in progress (as they also say in https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/standard-platform.md) and some things can change.
gabikliot
on 13 Nov 2015
OK, just saw that the code if 100% .NET Core 5.0 portable. Great!
gabikliot
on 15 Nov 2015
Guys just give my 2cents on this issue...
project.json is not only for Linux. UWP and coreCLR project will use it regardless of where it will be built.
project.json is used on Nuget v3 which right now, is the only version of Nuget with support to the new Families (UWP) and Generations (all non-UWP platforms that run coreCLR).
The project diff is that on coreCLR they are .xproj instead of .csproj. The only exception is for Portable Class Libraries, which now has a new profile that target CoreCLR as well and still uses .csproj.
Anyway, nice to see that you guys are already 100% portable! Good work!
galvesribeiro
on 17 Nov 2015
Thanks @galvesribeiro .
I plan to eventually bring protobufs into Orleans, as one of the optional serialization formats (like done with MS Bond here https://github.com/dotnet/orleans/pull/953). A major advantage of protobufs is support for multiple versions, which is especially important for Orleans, and currently is a major pain point, as can be seen in: https://github.com/dotnet/orleans/issues/713, https://github.com/dotnet/orleans/issues/320.
gabikliot
on 17 Nov 2015
With 1.0 RTM and tools preview 2 around the corner, I'm going to look at this again. It's not clear to me which version of netstandard we'll be able to target, but something should work - will look at this later this week (once the RTM bits are out).
jskeet
on 27 Jun 2016
@jskeet it seemed to me that the right strategy is to start with netstandard1.5 and try lowering until things don't work. I expect to be able to go as low as netstandard1.0 because we are already targetting Profile259.
We'll also need to upgrade NUnit to 3.2+, but that should be reasonably easy (with gRPC I've actually had good experience with NUnitLite that allows the test assemblies to become standalone .exe files).
jtattermusch
on 27 Jun 2016
@jtattermusch I'm not expecting to hit netstandard1.0 - I wasn't able to for Noda Time. But I'll give it a try. Obviously that would be ideal.
jskeet
on 27 Jun 2016
Just tried this within Visual Studio, and targeting .NET Standard 1.0 works, but removes the PCL targeting. I don't think this would actually change anything though - we're targeting profile 259, which is _effectively_ netstandard1.0.
I'm going to try creating a netstandard1.0 library which then depends on and uses Google.Protobuf from Linux... I suspect it'll work, in which case I don't _think_ there's any benefit in changing to different tooling at the moment when we know it'll be changing more (and back to csproj) in the long term anyway.
// cc @onovotny who may be able to give more guidance :)
jskeet
on 28 Jun 2016
Couple of things -- netstandard effectively supersedes use of the portable- TFM's for Profile 259 PCL's and narrower/higher, etc. NuGet 2.12 enables VS 2012/2013 to consume netstandard1.0 TFM's and install them into compatible project types.
I have blog about this here: https://oren.codes/2016/06/23/portable-is-dead-long-live-netstandard/
The move to netstandard1.0 is completely separate from moving from project.json to MSBuild. You can create netstandard libraries using csproj today.
If there's additional features you could light-up, you could release multiple netstandard versions in the same package. You'd just need to manage assembly versions based on externally available api surface area between them.
clairernovotny
on 28 Jun 2016
@onovotny: Thanks for that - I hadn't actually checked the project.json file that had been created; had forgotten that can live side-by-side with csproj. Have cc'd you on PR #1721 - if you have time to give it a very quick look, that would be much appreciated :)
jskeet
on 28 Jun 2016
What is the status on targeting netstandard @jskeet? Being able to use google's protobuf in netstandard projects would be great!
Trolldemorted
on 16 Jan 2017
@Trolldemorted: I'm not sure why I hadn't closed this before - we target net45 and netstandard1.0.
jskeet
on 16 Jan 2017
Ah, I see it was already closed, actually - as per June 28th 2016.
jskeet
on 16 Jan 2017
@jskeet thanks for the quick response!
Is there a solution for protobuf2 messages? I have a library i'd like to migrate to netstandard that uses https://github.com/jskeet/protobuf-csharp-port, but unfortunately that is not fit for netstandard, and this project does not support protobuf2 for c# :|
Trolldemorted
on 16 Jan 2017
It's possible that protobuf.net (https://github.com/mgravell/protobuf-net) will support it - the project page says that "CoreClr/DNX" is "under investigation". I don't know any other alternatives, I'm afraid.
jskeet
on 16 Jan 2017
https://www.nuget.org/packages/protobuf-net/ -> Support netstandard1.3 and 1.5
galvesribeiro
on 17 Jan 2017
Related issues
kolea2
路
40Comments
xenji
路
27Comments
laszloagardi
路
40Comments
mitar
路
37Comments
blowmage
路
26Comments
Most helpful comment
With 1.0 RTM and tools preview 2 around the corner, I'm going to look at this again. It's not clear to me which version of netstandard we'll be able to target, but something should work - will look at this later this week (once the RTM bits are out).