...

• #Status
• #Architecture
• #Target Platforms
  • #Runtime Location
  • #Supported build tools
• #Performance
• #Usage
  • #Generating C# code from a grammar
  • #Specifying the namespace for your recognizer
  • #Syntactic differences from the Java target
  • #Debugging with ANTLRWorks

Status

In general, development progress on the C# target is likely to be sporadic.

Version 3.0.x

As of September 2007, the C# code generator and runtime are NOT in sync with the latest release and development versions of the ANTLR tool and Java language target. The last latest release of the v3.0.x C# code generator and runtime were sync'ed to was developed for the ANTLR v3.0 release from July 2007. Nevertheless, no major problems have been reported by those using the C# codegen and runtime with ANTLR v3.0.1 since it's release that version was released in August 2007.

Version 3.1.x

As of October 2007, the ANTLR source depot contains an early pre-beta release of the C# codegen and runtime for the upcoming ANTLR v3.1 release. Starting from the end of October, ANTLR daily builds of v3.1 have been available for those wishing to test the C# support with the new features of ANTLR v3.1. As before, development progress going forwards is likely to be sporadic.

As of May 2008, the C# target is in sync with the Java target of the upcoming ANTLR v3.1 beta release. The This new version of the C# target breaks source compatibility with the old versionprevious versions (including previous v3.1 builds). To a certain extent, regeneration of grammars does help, but certain fields have been renamed to follow .NET conventions, which means that the first is capitalized (example: .tree is now .Tree). The exception is .st, which is now .ST. Additionally, the a new target named CSharp2 has been introduced. The reason for this is three-fold:

1. Firstly, the old target

...

1. named {{CSharp)) can retain it's compatibility with the .NET v1.1 platform. As such, it can't take advantage of C#

...

1. v2 features in the code generation templates

...

1. . The runtime will require twice the number of files, effectively doubling the amount of maintenance.
2. Secondly, a certain bug fix requires a C#

...

1. v2 feature or, a change to the

...

1. templates for each

...

1. occurence of the bug - and this has to be done by the user. The details of doing so are found in #Known Issues below.
2. Thirdly, because maintaining the backwards compatibility sucks majorly,

...

1. creating the new CSharp2 target allows the existing CSharp target to be deprecated without forcing people

...

1. by abandoning .NET

...

1. v1.1 compatibility immediately.

...

Introducing the new target which allows me to change even the code generation templates. As working on further enhancements will at least break binary compatibility, most of the changes will be done for ANTLR v3.2. During the life-time of ANTLR v3.1, the public API of the C# target(s) will be frozen. If you wish to future-proof your grammar, change them to use the new CSharp2 target. It is planned to remove the original CSharp target for the ANTLR v3.3 release.

The C# code generation templates and the CLR runtime library are feature complete for both targets. The C# targets leverage the existing C# StringTemplate implementations to support the broadest range of the features that ANTLR provides. The long open issue of unit tests has finally been tackled with the adoption of MbUnit and the inclusion (in the v3.1 version) of a wide range of tests for the runtime library. As before, basic sanity checks will done by ensuring that the sample grammars in the examples-v3 archive work as designed. This is currently a work-in-progess for the full v3.1 release.

Architecture

...