Best practice for including external .proto files in container build images

I am kind of uncertain what to do when referencing *.proto from outside the project. Example:

<Protobuf Include="..\..\protos\example.proto" GrpcServices="Client" />

My Dockerfile is included in the project directory src\example-client\Dockerfile, and the docker build context is src\example-client. I’m trying to avoid changing the docker context to the root of the mono repo. The build will fail because docker cannot reference files outside of the build context (aka, COPY ../../protos .). I tried searching around and came accross issue #183, but that seems like it would result in the same issue just with a nuget reference.

Some examples show manually copying/pasting the ..\..\protos\example.proto to src\example-client\Protos\example.proto and updating the include to:

<Protobuf Include="Protos\example.proto" GrpcServices="Client" />

In order to avoid copy/pasting manually I updated my build to include:

<Target BeforeTargets="PreBuildEvent" Condition="'$(Configuration)' != 'Release'" Name="CopyProtos">
  <Copy SourceFiles="..\..\protos\example.proto" DestinationFolder="Protos" ContinueOnError="true" />
</Target>

It worked, but not ideal. I looked at how gRPC clients are handled with Go, and it looks like the generated *.pb.go and *_grpc.pb.go files are generally just checked into source control. So I modified my build to do this:

<ItemGroup Condition="'$(Configuration)' != 'Release'">
  <Protobuf Include="..\..\protos\example.proto" OutputDir="proto"
            GrpcServices="Client" CompileOutputs="false" />
</ItemGroup>

This worked and felt like the right approach, until I read it might be an anti-pattern.

The tooling package Grpc.Tools is required to generate the C# assets from *.proto files. The generated assets (files):

• Are generated on an as-needed basis each time the project is built.
• Aren’t added to the project or checked into source control.
• Are a build artifact contained in the obj directory.

– <cite>C# Tooling support for .proto files</cite>

So is this actually an anti-pattern in this instance, or are other teams doing similar approaches? Are there better solutions?

[JunTaoLuo]

The reason we recommend generating the classes is recommended is that it is kept in sync with the proto files. Checking in the generated files is fine if you regenerate those files each time the proto files are changed. This could be accidentally missed or become a burden which is why we recommend against it. However, if you need it in your scenario, that approach is acceptable too.

[chwarr]

You’ll also want to regenerate the .cs files if protoc changes (e.g., a different version is used), not just on changes to the .proto files. That’s a dependency that often gets missed when writing build system rules, and I’ve fixed this bug a number of times myself. 😀

Also, keep in mind that protoc and the ProtoBuf library need to be kept in sync with each other. New code gen may rely on newer APIs in the library and vice-versa. (This may not be strictly necessary in all cases, but mismatches have caused problems in the past.)