imports from other .proto files do not generate using statements when generated with protogen.

[GoogleCodeExporter]

If you import message types from other .proto file the generation with 
protogen passes without problem. When you try to build though you notice 
that the imported .proto file namespace has not been imported properly in 
the generated .cs file. As workaround you can add this manually.

Original issue reported on code.google.com by tommi.s.e.laukkanen on 8 Mar 2009 at 9:54

[GoogleCodeExporter]

The problem was that I run the command on windows environment with different 
cases 
than the actual file so the case sensitive namespace point to different place. 
I 
noticed that also the imported messages get imported to the same file. Can you 
somehow avoid regenerating those classes as I have multiple proto files which 
share 
a common proto file and I would need these common classes be generated only 
once? So 
I would rather generate the classes just once by running protogen against the 
common 
proto file.

Original comment by tommi.s.e.laukkanen on 8 Mar 2009 at 10:03

[GoogleCodeExporter]

I will investigate and see what can be done. Out of interest, do you have any 
sample 
files that reproduce this?

Original comment by marc.gravell on 8 Mar 2009 at 1:30

[GoogleCodeExporter]

Here is the common file and example of file which references to the common file.

Original comment by tommi.s.e.laukkanen on 8 Mar 2009 at 4:26

Attachments:

• MXP.Common.proto
• MXP.Extentions.OpenMetaverseFragments.proto

[GoogleCodeExporter]

I've had a chance to look at this (note: still in progress); firstly, the issue 
with 
all imported typed being generated was resolved a while ago, and now doesn't 
happen 
unless you request it ("-d").

I'm trying to bottom out all the edge-cases with namespaces, because at the 
moment 
when you don't specify a "package" it is bug ugly; I've added support for a 
default 
namespace, but I want to have a look at what happens with imports.

Out of interest - do you use those files with other implementations? (java 
etc)? I'd 
be interested in how it handles it there, since from the descriptor alone it 
looks 
impossible to robustly find the *package* of the imports (I can get the 
filename, but 
if a package is specified it fails).

Of course; another approach would be to declare a "package" in each proto; this 
gives 
you fine-grained control over the generation (and is supported without any 
changes).

Original comment by marc.gravell on 19 May 2009 at 6:56

• Changed state: Started

[GoogleCodeExporter]

I think it would be good stay within the default .proto specification. For me 
it 
would be enough if I could define the namespace as argument to the exe which 
generates the code. Then I could generate all related things to same namespace.

Original comment by tommi.s.e.laukkanen on 19 May 2009 at 12:03

[GoogleCodeExporter]

Then you'll be happy ;-p In my local copy I have added "-ns:blah" option to 
allow you 
to define the default namespace (where no package is specified). I'm also 
investigating 
what java etc do with that file re namespaces to bring them all into line. I 
can commit 
the "-ns:blah" change if you want it "as is" (from source), else I will do a 
"proper" 
build when I am happy that the behaviour (without "-ns:") is consistent with 
the other 
implementations.

Let me know if you want me to do a commit...

Original comment by marc.gravell on 19 May 2009 at 12:30

[GoogleCodeExporter]

Now available in r253; by default the "package" is used, but you can also use 
-ns: and 
-t:import to get more control over namespaces

Original comment by marc.gravell on 27 May 2009 at 12:24

• Changed state: Fixed

[GoogleCodeExporter]

Very nice. Are you going to make a release soon?

Original comment by tommi.s.e.laukkanen on 27 May 2009 at 2:48

[GoogleCodeExporter]

Done; see downloads... any problems, give me a shout.
http://code.google.com/p/protobuf-net/downloads/list

Original comment by marc.gravell on 27 May 2009 at 2:52