ProtoFile as collection about falanx HOT 8 CLOSED

Just realized generating the files separately, instead of automagically as part of the build might work (and would be preferable) too, but it has another problem: I'd like to include the CLI tool in the same project, but building such a project currently fails unless there are are ProtoFile entries.

EDIT: found DesignTimeBuild prop that can be set to false to avoid codegen kicking in.

from falanx.

One one file is supported as input to Falanx, the import statement should be used for this purpose. Froto does not yet support import although there is beta support for recursing generation on imports

from falanx.

Yes, atm multiple proto in fsproj are not support yet.

Will be nice to support it, so the following works

    <ProtoFile Include="a.proto" />
    <ProtoFile Include="b.proto" />

These are expected to be completly indipendent, and generator will run two times, generating two .fs files, so no types are shared

from falanx.

Just realized generating the files separately, instead of automagically as part of the build might work (and would be preferable) too, but it has another problem: I'd like to include the CLI tool in the same project, but building such a project currently fails unless there are are ProtoFile entries.

EDIT: found DesignTimeBuild prop that can be set to false to avoid codegen kicking in.

@et1975 the DesignTimeBuild cannot be set in projects, otherwise other .net msbuild sdk behaviour are disabled. If not needed (you dont want to use the integration), do not include Falanx.Sdk, but for this original issue, is easier to fix supporting multiple ProtoFiles

from falanx.

multiple files adds some unforeseen issues like, if both are importing a type thats used in both messages. A better solution would probably be a composite proto files that imports both etc

from falanx.

if DesignTimeBuild is not an option, maybe the easy fix would be to treat the empty ProtoFile as no-op for codegen instead of failing?

from falanx.

multiple files adds some unforeseen issues like, if both are importing a type thats used in both messages. A better solution would probably be a composite proto files that imports both etc

@7sharp9 i think these are different scenario. often the proto have nothing in common, so we can for example create these in nested namespace, like

   <ProtoFile Include="a.proto" Namespace="ServiceA" />
   <ProtoFile Include="b.proto" Namespace="ServiceB" />

also if these use common types will be duplicated in different namespaces
It's the user who need to choose if create a new proto and import boths, to use shared types.

if DesignTimeBuild is not an option, maybe the easy fix would be to treat the empty ProtoFile as no-op for codegen instead of failing?

@et1975 yes, without <ProtoFile shouldnt run the generator, not fail the build. I'll check that too

from falanx.

fixed by #98 now multiple <ProtoFile are supported.

each one is independent from the others

from falanx.