Type Provider support .NET Core. Parser supports import statements.

Issues fixed:
https://github.com/ctaggart/froto/milestones?state=closed

fix Enum in message body error

Issues

• #93 Enum in message body error

Pull Requests

• #96 fix Enum in message body error

[Bugfix] Parsing `oneof` statements

Fixes parsing of oneof fields when using proto3 syntax (issue #88)

0.6.0: Add proto3 specific deserialization that requires fewer SRTP constrai…

…nts (#85)

* Add proto3 specific deserialization that requires fewer SRTP constraints
* Refactor to share as much as possible between proto2/3 deserialization
* Fix tests to refere to proto2 on deserialize
* Removed UnknownFields from the xmldoc
* A property named UnknownFields is not required by SRTP constraints
* Use the 0 field mapping for unknown fields if present, no action if this is missing.
    - This gives the code generator the choice of generating the 0 field maping to a property, therefore adhering to the proto3.5 chanages to make implementation preserve unknown fields on deserialisation.
* Add unit tests for proto3
* Remove unecessary RequiredFields
* Add some documentation about proto3 definitions
* preserve any previous unknown fields on re-serialization

Froto.Parser & Froto.Serialization target netstandard2.0

https://github.com/ctaggart/froto/milestone/6?closed=1

gRPC parsing & Froto.TypeProvider

Parser now supports gRPC.
New Froto.TypeProvider package with support for proto2.
See 0.4.0 milestone for details.

Thanks to @jhugard, @takemyoxygen, & @bhandfast.

Make Parser functions more accessible

Fixes issue #41 by making the Parser functions more accessible.

This release moves the primary parsing functions into a more accessible module Parse, which contains only those top-level parsing functions, and moves the actual parsers away from those functions into a separate module, Parse.Parsers (both presuming you have opened Froto.Parser). This should help make the main functions far more discoverable.

• User code should now open Froto.Parser and call Parse.fromFile fileName, Parse.fromStream stream and Parse.fromString str.
• No longer a need to specify the Proto.pProto parser as a parameter.
• Parsers moved into Parse.Parsers
• Parse functions that take a parser are still available, mainly for testing. E.g., Parse.fromStringWithParser Parse.Parsers.pProto str
• Class model types, used to access parsing functionality from C#/VB, were moved into ClassModel from Model, to help emphasize that F# users should use the Parse functions and returned Ast.PStatement list rather than class model.

F# Immutable Record Serialization Support

This release adds support for serializing and deserializing immutable F# Record types, as well as all other types including Class types. The changes for Record serialization also provide a significant performance boost, not only fixing an O(n^2) problem in repeated fields, but simply much faster overall for all operations.

Refer to the example record and example class serialization files for examples, as well as the other unit test files.

The serialization namespaces, modules, and function names were all changed to, hopefully, provide more intuitive and simplified access to serialization functionality.

The project organization also has significant changes, the most notable of which is Froto.Core.dll has been renamed Froto.Serialization.dll.

Detailed list of changes:

• #37 Fix bug: O(n^2) Performance Problem on repeated fields
• #38 Record Serialization
• Reimplement Class serialization using the new Record Serialization structure
• Project reorganization for accessibility, readability and consistency
  • Rename base namespace from Froto.Core to Froto.Serialization and assembly from Froto.Core.dll to Froto.Serialization.dll
  • At the WireFormat level, rename encodeXXX/decodeXXX functions to Pack.toXXX/Unpack.fromXXX
  • At the RawField level, and rename dehydrateXXX/hydrateXXX functions to Encode.fromXXX and Decode.toXXX
  • At the Serialization level, created functions for serializing to/from ZeroCopyBuffer and ArraySegment
  • Rename "Exe" solution to "Froto.Compiler"
  • Rename several folders; e.g., "ProtoParser" to "Parser" and "Exe" to "Compiler"

0.2.1 release details

Updating from Froto 0.1.0

Core

• Froto.Core was reworked to provide serialization and deserialization of
  all supported wire types and to minimize buffer copying.
  • Code depending on Froto.Core.IO will need to be rewritten to use the
    following modules and types:
    • Froto.Core.WireFormat
    • Froto.Core.Encoding.RawField
    • Froto.Core.ZeroCopyBuffer and subclasses
  • Alternatively, the functions in the Froto.Core.Encoding.Serializer
    module can provide a slightly higher level of abstraction.
  • Or, see next.
• Added a framework for easily constructing serializable class types.
  • See Froto.Core.Encoding.MessageBase for an abstract base class which
    provides the serialization framework, and see
    Froto.Core.Test/ExampleProtoClass.fs for example usage.

Parser

• The parser now generates an AST based on Discriminated Unions, rather than
  objects. Froto.Parser.Ast (and the underlying parser) now support the full proto2
  and proto3 languages.

• The old primary class, Froto.Parser.ProtoAst.ProtoFile has been renamed to
  Froto.Parser.Model.ProtoFile and given static factory methods to simplify
  access from C#, VB.net, etc.

  Note that this model curently only supports a subset of the proto2 language.
  This will be expanded in later releases to fully support proto2 & proto3.

  • ProtoFile.ParseString(s:string)
  • ProtoFile.ParseStream(streamName:string, stream:System.IO.Stream)
  • ProtoFile.ParseFile(fileName:string)

Preliminary look at the new parser

This is a preliminary release of the new parser, featuring proto3 and full proto2 syntax support.

• #6 Add support for proto3 language
• #8 Strict/complete proto2 compliance
• #9 updated build & dependencies
  • switched from Apache 2 to MIT license

The most significant change is a switch to a new core AST, based on discriminated unions.

The class model is being retargeted as a C# accessibility layer. However, this is currently incomplete as it handles only a subset of the proto2 language.