Grpc.Tools doesn't support same filename in different folders #17672
Description
What version of gRPC and what language are you using?
Grpc.Tools 1.17.1
What operating system (Linux, Windows, …) and version?
Windows 10
What runtime / compiler are you using (e.g. python version or version of gcc)
C# MSBuild
What did you do?
One project with two protos having the same filename but in different folders.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<Protobuf_StandardImportsPath>$(Protobuf_StandardImportsPath);..\protos</Protobuf_StandardImportsPath>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Grpc.Tools" Version="1.17.1" PrivateAssets="All" />
<Protobuf Include="..\protos\foo.proto" Link="protos\foo.proto" />
<Protobuf Include="..\protos\dir1\bar.proto" Link="protos\dir1\bar.proto" />
<Protobuf Include="..\protos\dir2\bar.proto" Link="protos\dir2\bar.proto" />
</ItemGroup>
</Project>
What did you expect to see?
The code should compile, generating 3 cs files.
What did you see instead?
MSB3105: The item "obj\Debug\netstandard2.0\Bar.cs" was specified more than once in the "Sources" parameter. Duplicate items are not supported by the "Sources" parameter.
Anything else we should know about your project / environment?
We have an extensive library of protos that get reused by different projects that also share some protos. Therefore a common root path is necessary. The name config.proto for example is used in a couple of directories.
Until now, I used the following command to generate the files:
%protoc_path%\protoc.exe --proto_path=%protoc_path%\..;..\protos --csharp_out=%output_path% --csharp_opt=base_namespace --grpc_out=%output_path% --plugin=protoc-gen-grpc=%protoc-grpc_path%\grpc_csharp_plugin.exe ..\protos\foo.proto ..\protos\dir1\bar.proto ..\protos\dir2\bar.proto
The option base_namespace placed the generated files in sub-directories and avoided the problem. This problem will still remains for grpc service files, since there is no option like this for grpc_opt. But that problem can't be circumvented so easy right now.
/cc @kkm000