Can one of the admins verify this patch?

this is ok to test

#6062

This is an interesting approach. Generally, when we want to run a tool, writing an MSBuild Task for that is the simplest way to go, as there are APIs to run a process, check files and so on. You write code at a higher level in general.

I will be really happy to contribute and/or guide @ananthonline on that (we adopted gRPC from early alpha straight into production). But it seems to me that a very if not the most important problem here is still not satisfactory solved, namely: If I compile x.proto, y.proto and z.proto, what .cs files will be generated? If I guess wrong, I either cause the project to be recompiled because of missing outputs, or have stale outputs added to compile There is a lot of corner cases, e. g., what happens if I remove the rpc declaration from x,proto and recompile? That's the main thing here to get the build correct, or at the very least as correct as practical for most cases.

@kkm000 thanks for great input! Again, this seems to become more complicated than it originally seemed to be.
Because there seems to be lots of problems to solve, I don't think it is likely that we will be able to address everything in a single PR. Can we instead come up with some minimalist set of features that could be checked-in soon and would provide gRPC users some extra comfort when working with .proto files?

Btw, I am not sure if it makes sense to invest a lot of effort into writing a custom msbuild task in times where DNX-style project.json projects are becoming the standard for new projects quickly.

Also, has anyone thought of looking at the problem from a different perspective and coming up with a VS extension that would provide some nice integration for working with .proto files?

@jtattermusch: I was thinking about an extension. There is one (https://visualstudiogallery.msdn.microsoft.com/4bc0f38c-b058-4e05-ae38-155e053c19c5, https://github.com/mreu/ProtobufLanguageService). I did not want it at the time because it looked like it did too much. I certainly want syntax highlighting and other support from the editor, and it promises to be really amazing, look at the sample screenshot! It appears, however, that it also generates C# code, and I certainly did not want another compiler in the picture when everything was still in alpha and unraveling... Anyhow, the page now says "C# code generation will follow in Version 2.0" -- I do not remember if the promise was there, but I think I am not the only one complaining! :)

Generally, a VS extension is a greater hurdle to maintain for users and I believe gRPC or protobuf should [edit] not rely on an extension for the whole rig to work. MSBuild is more than enough to have everything built properly. This seems to be true for mono/Xamarin too, but I am not so well versed in DNX project.json builds, however. An extension, on the other hand, would add all the bells and whistles to user experience, including syntax highlighting, syntactic features in editing, creating and adding proto files to projects, but should not go beyond that, IMO. Visual Studio did include some code-behind code generators, but my feeling is this is not where they are going now.

I'll try to wrap my head around the project.json thing. Long overdue, it's been out for a while and I do not even know much beyond the fact it exists!

As for writing and debugging an MSBuild task, this is not hard technically, but needs logistics coordination between protoc and gRPC packages.

On Sun, Apr 10, 2016 at 8:44 PM, Kirill Katsnelson <[email protected]

wrote:

@jtattermusch https://github.com/jtattermusch: I was thinking about an
extension. There is one (https://visualstudiogallery.
msdn.microsoft.com/4bc0f38c-b058-4e05-ae38-155e053c19c5,
https://github.com/mreu/ProtobufLanguageService). I did not want it at
the time because it looked like it did too much. I certainly want syntax
highlighting and other support from the editor, and it promises to be
really amazing, look at the sample screenshot! It appears, however, that it
also generates C# code, and I certainly did not want another compiler in
the picture when everything was still in alpha and unraveling... Anyhow,
the page now says "C# code generation will follow in Version 2.0" -- I do
not remember if the promise was there, but I think I am not the only one
complaining! :)

Interesting, the problem I see with the extension for now is that the
protoc and grpc plugins are changing relatively rapidly and with that
frequency of releases, it definitely makes more sense to ship nuget
packages rather than new releases of an VS extension.

Also, some users will be using different versions of protobuf and grpc in
different projects at the same time, which again talks in favor of
per-project nugets.

Generally, a VS extension is a greater hurdle to maintain for users and I
believe gRPC or protobuf should rely on an extension for the whole rig to
work. MSBuild is more than enough to have everything built properly. This
seems to be true for mono/Xamarin too, but I am not so well versed in DNX
project.json builds, however. An extension, on the other hand, would add
all the bells and whistles to user experience, including syntax
highlighting, syntactic features in editing, creating and adding proto
files to projects, but should not go beyond that, IMO. Visual Studio did
include some code-behind code generators, but my feeling is this is not
where they are going now.

I'll try to wrap my head around the project.json thing. Long overdue, it's
been out for a while and I do not even know much beyond the fact it exists!

Two problems with project.json
-- it's way less customizable than MSBuild (no things like custom msbuild
tasks etc).
-- it's been a moving target (things change with deprecation of DNX and
introduction of dotnet CLI)

On the other hand, project.json definitely seems to be the future, so any
solution that doesn't involve it doesn't make much sense in the long run.

As for writing and debugging an MSBuild task, this is not hard
technically, but needs logistics coordination between protoc and gRPC
packages.

We certainly have the power to make changes to both protobuf C# and gRPC C#
(I have commit access to both repos for example). We just need to figure
out what it is that we want to do. I prefer making smaller steps because
because we are unlikely to come up with a grand solution for everything at
once).

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#6085 (comment)

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok to test.

Ok, I think I've addressed all of the problems that @jtattermusch and @kkm000 pointed out.

It's actually possible to ask protoc to give us the list of dependencies and generated files using the --dependency_out option. The C# wrapper parses the output of this file (for each input proto) and recursively generates C# down to the leaves of the dependency tree. I've verified that this list does indeed work for both XXYYGrpc.cs and XXYYcs files, along with included proto files that are not even included in the project.

See build output from an example here: http://pastebin.com/ruvwM8Df

I've also added a proper clean target that cleans up all generated and temporary files.

Might I suggest we support MSBuild + C# projects and then add support for JSON projects as customizability is added?

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok to test.

@jtattermusch @kkm000 , any comments on the latest changes? I believe they address everything we've discussed so far.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok to test.

What's the status of that PR ? If we still want to proceed with it, it needs some updates.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok to test.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

This PR is almost an year old. Closing.