* Added <autogenerated> in cs generator file header comment
#4287
* CS: Added xml-correct file header comment including "<auto-generated>...</auto-generated>"
code_generators.cpp: FlatBuffersGeneratedWarning() function replaced by compile time constant "GeneratedWarning"
also removed extra newlines at end of GeneratedWarning to be able to generate a xml well formed file comment for cs files
#4291
* code_generators: Changed static string GeneratedWarning back to function FlatBuffersGeneratedWarning()
#4291
* Added modified Unit-Test files
#4291
* idl_gen_general: Add autogenerated only in C# code
#4291
* C#: Fixed possible conflicts between usings and user-supplied namespace
C#: Added the global qualifier to using directives to prevent possible conflicts with the user-supplied namespace. Also prevents unintentional type hiding. Resolves issue #4242.
* Updated C# generated code files
I updated idl_gen_general.cpp to add support for generating a Get Bytes
method for a vector to the generated C# source code. Given a byte vector
field named Foo, a method named GetFooBytes() will be generated in the
C# source code that will return an ArraySegment<byte> value referencing
the vector data in the underlying ByteBuffer.
I added a method to Table.cs named __vector_as_arraysegment that is used
by the code generated by the change to the C# generator.
__vector_as_arraysegment will take the offset of the vector and will
return the ArraySegment<byte> value corresponding to the bytes that
store the vector data.
I updated FlatBuffersExampleTests.cs to add tests to validate my
implementation of Table.__vector_as_arraysegment. I added tests to
demonstrate that the bytes for the monster's name can be extracted from
the underlying byte array. I also added tests to show that
Table.__vector_as_arraysegment returns a null value if the vector is not
present in the FlatBuffer.
I used the updated flatc.exe program to regenerate the C# source files
for the MyGame example. The new Monster class includes the GetXXXBytes
methods to return the byte arrays containing data for vectors.
Fixes a bug where the logic to determine when to use a C# enum flags
both enums and vectors of enums. This causes the C# generator to
generate code that doesn't compile for tables that contain vectors of
enums.
The fix also consolidates type generation functions a bit and adds
some additional casting functions for clarity.
In C#, plain field accessors should not be nonparametric methods
but should be standard property getters.
The accessor methods with parameters were renamed to `GetXxx`
because a method cannot be named identically to a property.
Also, `ByteBuffer.Position`, `FlatBufferBuilder.Offset` and
`FlatBufferBuilder.DataBuffer` are now properties instead
of nonparametric accessor methods, for more idiomatic C# style.
This is a breaking change, all client C# code accessing these
fields needs to be changed (i.e. remove those `()` or add the
`Get` prefix).
Issue: #77
Change-Id: Iaabe9ada076e5ea2c69911cf6170fdda2df3487e
Enums should not be (badly) emulated with classes in C# but should
use native C# enums instead. Java implementation made an explicit
choice not to use the (more complex) Java enums, but C# enums are
just light-weight syntactic coating over integral types.
Fixes issue #171.
Change-Id: I9f4d6ba5324400a1e52982e49b58603cb7d7cca7
Also made the C# implementation support unsigned types, and
made it more like the Java version.
Bug: 17359988
Change-Id: If5305c08cd5c97f35426639516ce05e53bbec36c
Tested: on Linux and Windows.
Include C# codegen in flatc and .NET FlatBuffer access via the
FlatBufferBuilder class
Tested: on Windows.
Change-Id: If5228a8df60a10e0751b245c6c64530264ea2d8a
schoetbi